I use what we have.
Then its just CPU a bottleneck now, not which distro and how much bits.
First - when boss will ask for performance, let him buy new hardware
first. :)
Thanks for guiding. I could find that options in apache to tweak, so
performance in other appli
d 100 customers with 2-3 tickets per day?
--
Mimiko desu.
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
22 sOk
Multiplier: * 5 s
In all cases despite of different SQL Benchmark results, accessing
tickets, dashboard, sysconfig remained same speed.
--
Mimiko desu.
-
OTRS mailing list: otrs - Webpage: http://otr
ll it websrv-machine). In this case, an additional
thing to check would be if the Apache instance running OTRS is starved
for resources (memory, etc.).
--
Mimiko desu.
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
n Windows where it became borderline unusable. You may want to
try mod_fastcgi instead.
I've read in manual that fastcgi is slower than modperl that's why I
didn't try it. May be I will try fastcgi.
--
Mimiko desu.
---
dmin manual for performance
improvements but really for 2-3 customers and 2-3 agents you shouldn't
need to do make any special performance performance tweaks for OTRS to
runs decently fast.
--
Mimiko desu.
-
OTRS mailing list:
On 13.05.2014 11:56, Bogdan Iosif wrote:
Hi Mimiko. Did you manage to solve the performance issue?
Hello.
Somehow. I did what mhillman sugested - ran
shell> bin/otrs.RebuildConfig.pl
shell> bin/otrs.DeleteCache.pl
but in long terms, still it is visible slow for agents. Dashboard
gene
gt;
relating to this.
I'm on otrs 3.3.6 from git.
Interesting, just tried to set customer group support to No and
customers have access to queues, and also they see theirs old tickets.
I am sure that a while ago it didn't work so. M
On 01.04.2014 09:07, Sander Goudswaard wrote:
Are you using mod_perl or perl via cgi? The latter tends to be slower.
I am using mod_perl. I installed following guide on installation.
--
Mimiko desu.
-
OTRS mailing list: otrs
Oh, and during package's install, all other access to otrs, like
costumers pages, a slow too.
--
Mimiko desu.
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubs
On 31.03.2014 20:50, Marty Hillman wrote:
To my knowledge, this should be a one time thing each time you do an upgrade.
Thank you.
But still opening Package Manager takes long time. Installing packages
also takes long time.
--
Mimiko desu
n I must do this? Do I have to create a cron job for this?
--
Mimiko desu.
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
adcom drivers that causes some major slowdowns.
Have a look at these.
The mysql DB is on physical separate server with intel chipsets at base
and NIC.
OTRS is installed in Debian Wheezy x86_64 in a vertial server based on
Hyper-V 2008 R2 host on intel chipset for NIC.
--
Mimiko
mance?
Thanks
--
Mimiko desu.
-
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
On 20.02.2014 23:28, Mimiko wrote:
Hello.
The scheduler can not start on system start-up, or using
/etc/init.d/otrs-scheduler-linux start. The problem is in this:
bin/otrs.Scheduler.pl -a status
Not Running!
*** glibc detected *** /usr/bin/perl: double free or corruption (!prev
USE_64_BIT_ALL USE_64_BIT_INT
USE_ITHREADS USE_LARGE_FILES USE_PERLIO
USE_PERL_ATOF
USE_REENTRANT_API
Built under linux
Compiled at Sep 30 2013 03:45:34
@INC:
/etc/perl
/usr/local/lib
use Control+C to stop it.
I didn't find out why is this error.
My system is:
Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux
Thank you for help.
--
Mimiko desu.
-
OTRS mailing list: otrs - Webpage: http://otr
17 matches
Mail list logo
