On 14.05.2014 16:09, Bogdan Iosif wrote:
My opinion is that Redhat/CentOS or Ubuntu LTS (based on Debian, I know)
are more likely to have the best performing drivers and the most tested
and stable configurations, compared with other distros. Thus, I wouldn't
stray from those for prod systems. The
My opinion is that Redhat/CentOS or Ubuntu LTS (based on Debian, I know)
are more likely to have the best performing drivers and the most tested and
stable configurations, compared with other distros. Thus, I wouldn't stray
from those for prod systems. Then again, I'm no Linux expert and I don't
wa
On 14.05.2014 12:22, Bogdan Iosif wrote:
Try using a more common Linux distro and try both 32 and 64 bit Apache +
mod_perl.
More common linux distributive? Isn't Debian a common linux
distributive? Why use x32 bit and not allowing to spread mysql's or
apache's files in more RAM? x32 can addre
I don't have any other ideas then. Try using a more common Linux distro and
try both 32 and 64 bit Apache + mod_perl.
Your hardware seems slow as far as MySQL is concerned and the CPU is
probably also slow. Based on what I've seen on my system, the CPU is indeed
the bottleneck for OTRS but I thoug
On 13.05.2014 17:30, Bogdan Iosif wrote:
You need to install a private MySQL instance for OTRS, on the same
machine where the rest of OTRS components are installed (server 2: otrs,
apache+modperl). I'm quite sure this will solve your performance problems.
I did some test on this:
There's your problem right there. MySQL performs badly. I'm getting max 3s
for these operations where you get ~7-8s and that's in a VM, on Windows.
You need to install a private MySQL instance for OTRS, on the same machine
where the rest of OTRS components are installed (server 2: otrs,
apache+mod
SQL Benchmar results:
Result: SQL
KEY VALUE TIMECOMMENT
Insert Time: 1 8 s :-( Should not take more than 5's on an average
system.
Update Time:17 s Ok
Select Time: 1 7 s :-( Should not take more than 6's on an average
system.
Delete Time:14 s
There's a package named Support that you should install from Package
Manager. After it's installed you'll have a new link in the ADMIN page,
named Support Assessment. Follow the link to a page presenting a report
about the environment OTRS is running on. The report may load VERY slowly
and return t
On 13.05.2014 16:05, Bogdan Iosif wrote:
I also noticed on my systems that opening SysConfig, and especially
opening Package Manager, is an operation that is much slower than most
others.
Especially when submitting changes.
The Support Package has a builtin benchmarking tool for the database
I missed the point about you having this issue on a physical machine.
I also noticed on my systems that opening SysConfig, and especially opening
Package Manager, is an operation that is much slower than most others.
The Support Package has a builtin benchmarking tool for the database. Did
you ru
I did say that I don't run otrs in VM. Its a dedicated physical server
on Debian Wheezy x86-64 4 logical CPU 5GB RAM. Its Xeon 2.8GHz 5 years
old. And only apache and otrs is on this server.
I did read the chapter 6. There are no more than 100 tickets now and no
more than 200 articles. Also, I
There's probably a bottleneck in your config. Either at the hypervisor
level or inside the VM.
On my instance, I have 150 tickets/day, up to ~40 agents and up to ~140
customers simultaneously connected. I'm running Apache 32-bit/MySQL
32-bit/Strawberry Perl 32-bit/Windows 2008 R2 64-bit in a VM wi
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
generation on
Hi Mimiko. Did you manage to solve the performance issue?
On Tue, Apr 1, 2014 at 9:19 AM, Mimiko wrote:
> 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 installat
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 -
Are you using mod_perl or perl via cgi? The latter tends to be slower.
-
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
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 unsubscribe: ht
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.
---
To my knowledge, this should be a one time thing each time you do an upgrade.
-Original Message-
From: Mimiko [mailto:vbv...@gmail.com]
Sent: Monday, March 31, 2014 12:48 PM
To: User questions and discussions about OTRS.
Subject: Re: [otrs] otrs speed consideration
On 31.03.2014 20:37
On 31.03.2014 20:37, Marty Hillman wrote:
shell> bin/otrs.RebuildConfig.pl
shell> bin/otrs.DeleteCache.pl
This helped me when I upgraded to 3.3.4 from a prior version.
Thank you. This helped me too. Although I didn't do any upgrade. I just
clean installed otrs 3.3.6.
How often I must do thi
3.0/en/html/x907.html
-Original Message-
From: Mimiko [mailto:vbv...@gmail.com]
Sent: Monday, March 31, 2014 11:35 AM
To: User questions and discussions about OTRS.
Subject: Re: [otrs] otrs speed consideration
On 31.03.2014 15:02, Mark Dissington wrote:
> Are you using virtu
On 31.03.2014 15:02, Mark Dissington wrote:
Are you using virtualisation, specifically hyper-v with linux based hosts
running MySQL, and if so, what chips do your NICs run?
If they're Broadcom and all of the above boxes are ticked turn off VMQ on the
chips. There is a bug in the Broadcom drive
>>> On 30/03/2014 at 16:53, Mimiko wrote:
> Hello.
>
> Finally I managed to install and set-up a working OTRS v.3.3.6 to work
> without any memory leaks. It's working now stable. But the speed is very
> poor. For a customer to view any ticket, it must wait more than 10 sec.
> This is very much
Hello.
Finally I managed to install and set-up a working OTRS v.3.3.6 to work
without any memory leaks. It's working now stable. But the speed is very
poor. For a customer to view any ticket, it must wait more than 10 sec.
This is very much time. I verified that perl and modperl are used. DB i
24 matches
Mail list logo
