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 this? Do I have to create a cron job for this? -- Mimiko desu.

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.

Are you using mod_perl or perl via cgi? The latter tends to be slower.

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 installation.

-- 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

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 with 4 CPUs on Hyper-V (Windows 2008 R2), on 4 year old hardware. I think my access times are slightly better than yours. Ensure your VM performs optimally. It may be worth to install OTRS in a different VM, on a different hypervisor and see if you get the same performance. Make sure you follow chapter 6 from the admin 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. On Tue, May 13, 2014 at 12:04 PM, Mimiko wrote:

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 server for agents takes 0-6 seconds. Accessing SysConfig or Package Manager takes 5-15 seconds.

In case of customers and agents it seems that if the ticket system is not accessed for some time, then first to access will wait awhile. Then others will access pages quicker. Also, when selecting a queue or service in new ticket page, refreshing other fields takes 1-2 seconds. And this is a starting project, where there are 2-3 customers and 2-3 agents. I think that perl is slow anyway.

-- 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

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 run that benchmark? Are the results ok? If everything checks out then the only possible cause that is left standing is the performance of mod_perl + Apache on your Linux distro. It would be worth to try a different, more common distro (such us CentOS or Ubuntu) and trying to run mod_perl and Apache in 32-bit vs 64-bit modes to see if there are any differences. I'm also tackling some performance issue with my OTRS system as I'm trying to upgrade from 3.2 to 3.3 on Windows and during my investigations I've noticed mod_perl has somewhat fallen out of grace, not just on Windows where it became borderline unusable. You may want to try mod_fastcgi instead. On Tue, May 13, 2014 at 3:27 PM, Mimiko wrote:

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 use preloaded modules and pre-established database connections. Most of the tips in this chapter is for more than 60000 tickets.

How this is related to poor performance when accessing SysConfig or Package Manager?

On 13.05.2014 14:49, Bogdan Iosif wrote:

...

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 with 4 CPUs on Hyper-V (Windows 2008 R2), on 4 year old hardware. I think my access times are slightly better than yours.

Ensure your VM performs optimally. It may be worth to install OTRS in a different VM, on a different hypervisor and see if you get the same performance.

Make sure you follow chapter 6 from the admin 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: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

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 timeouts. Keep retrying. When it finally succeeds, go through it and beware of any anomalies as they may clue you into why you're having problems. Additionally, notice that on the Support Assessment page you have a link in the upper left named SQL benchmark. Follow the link to a page from which you can run a benchmark on the database. This will help evidencing if there are issues for OTRS with the connection between the web server and the db server. If I understood things correctly, you have the db server on a dedicated machine (call it dbsrv-machine) but you run the VoIP server on the same machine as OTRS (call 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.). On Tue, May 13, 2014 at 4:35 PM, Mimiko wrote:

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. Did you run that benchmark? Are the results ok?

I did run Performance Log, from where I've found those seconds. Where is the tool for database?

If everything checks out then the only possible cause that is left

...

standing is the performance of mod_perl + Apache on your Linux distro. It would be worth to try a different, more common distro (such us CentOS or Ubuntu) and trying to run mod_perl and Apache in 32-bit vs 64-bit modes to see if there are any differences.

Trying other distro is not an option. I don't have physical resources for this. Same Debian handles a VoIP server with database and apache together on other server without a problem.

...

I'm also tackling some performance issue with my OTRS system as I'm trying to upgrade from 3.2 to 3.3 on Windows and during my investigations I've noticed mod_perl has somewhat fallen out of grace, not just on 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. --------------------------------------------------------------------- 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

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+modperl). I'm quite sure this will solve your performance problems. On Tue, May 13, 2014 at 5:08 PM, Mimiko wrote:

SQL Benchmar results:

Result: SQL KEY VALUE TIME COMMENT Insert Time: 10000 8 s :-( Should not take more than 5's on an average system. Update Time: 10000 7 s Ok Select Time: 10000 7 s :-( Should not take more than 6's on an average system. Delete Time: 10000 4 s :-) Looks fine! Multiplier: * 1 s

---------------------------------------------------------------- Result: SQL KEY VALUE TIME COMMENT Insert Time: 50000 24 s Ok Update Time: 50000 27 s Ok Select Time: 50000 30 s Ok Delete Time: 50000 24 s Ok Multiplier: * 5 s

The overall report loads fast. Its all green, meaning ok. Except some log warnings.

Well, server 1: Mysql, VoIP, Apache+PHP. server 2: otrs, apache+modperl

On 13.05.2014 16:52, Bogdan Iosif wrote:

...

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 timeouts. Keep retrying. When it finally succeeds, go through it and beware of any anomalies as they may clue you into why you're having problems.

Additionally, notice that on the Support Assessment page you have a link in the upper left named SQL benchmark. Follow the link to a page from which you can run a benchmark on the database. This will help evidencing if there are issues for OTRS with the connection between the web server and the db server.

If I understood things correctly, you have the db server on a dedicated machine (call it dbsrv-machine) but you run the VoIP server on the same machine as OTRS (call 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/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

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 thought my hardware is crap and when I saw it's at least twice as fast as yours, I thought that's the problem. On Wed, May 14, 2014 at 9:00 AM, Mimiko wrote:

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:

-------------------------------------------- Installed mysql on otrs server Mysql host on otrs configuration is 127.0.0.1

Result: SQL KEY VALUE TIME COMMENT Insert Time: 10000 3 s :-) Looks fine! Update Time: 10000 5 s :-) Looks fine! Select Time: 10000 5 s :-) Looks fine!

Delete Time: 10000 4 s :-) Looks fine! Multiplier: * 1 s

KEY VALUE TIME COMMENT Insert Time: 50000 16 s Ok Update Time: 50000 25 s :-) Looks fine! Select Time: 50000 25 s :-) Looks fine! Delete Time: 50000 21 s Ok Multiplier: * 5 s

---------------------------------- mysql is on otrs server Mysql host on otrs configuration is otrshost.com

KEY VALUE TIME COMMENT Insert Time: 10000 4 s Ok Update Time: 10000 5 s :-) Looks fine! Select Time: 10000 4 s :-) Looks fine! Delete Time: 10000 5 s Ok Multiplier: * 1 s

KEY VALUE TIME COMMENT Insert Time: 50000 17 s Ok Update Time: 50000 24 s :-) Looks fine! Select Time: 50000 25 s :-) Looks fine! Delete Time: 50000 21 s Ok Multiplier: * 5 s

----------------------------- mysql is on other server Mysql host on otrs configuration is ip of the mysql server

KEY VALUE TIME COMMENT Insert Time: 10000 5 s Ok Update Time: 10000 5 s :-) Looks fine! Select Time: 10000 6 s Ok Delete Time: 10000 5 s Ok Multiplier: * 1 s

KEY VALUE TIME COMMENT Insert Time: 50000 20 s Ok Update Time: 50000 25 s :-) Looks fine!

Select Time: 50000 30 s Ok Delete Time: 50000 24 s Ok Multiplier: * 5 s

-------------------------- mysql is on other server Mysql host on otrs configuration is mysqlhost.com

KEY VALUE TIME COMMENT Insert Time: 10000 4 s Ok Update Time: 10000 5 s :-) Looks fine! Select Time: 10000 6 s Ok

Delete Time: 10000 4 s :-) Looks fine! Multiplier: * 1 s

KEY VALUE TIME COMMENT Insert Time: 50000 22 s Ok Update Time: 50000 26 s Ok Select Time: 50000 29 s Ok Delete Time: 50000 22 s Ok Multiplier: * 5 s

---------------------------------- mysql is on another server Mysql host on otrs configuration is mysqlhost.com In apache on otrs host following was changed: keepalive on UseCanonicalName off HostnameLookups off

KEY VALUE TIME COMMENT Insert Time: 10000 4 s Ok Update Time: 10000 5 s :-) Looks fine! Select Time: 10000 6 s Ok

Delete Time: 10000 4 s :-) Looks fine! Multiplier: * 1 s

KEY VALUE TIME COMMENT Insert Time: 50000 20 s Ok Update Time: 50000 25 s :-) Looks fine! Select Time: 50000 29 s Ok Delete Time: 50000 22 s Ok 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://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

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 want to start a holly war about which distro is the best. Your choice. I would care about using 64-bit to access more RAM only after the performance is satisfactory. Thus, I would test 32-bit first. Also, running 32-bit Apache + mod_perl on a 64-bit OS would give you at most 4 GB of RAM for Apache. That's way beyond enough as you shouldn't need more than 1-2 GB for this process. Face it, your hardware is very old. I'm not one to not understand a lack of resources (believe me) but we're taking a single core CPU that was launched 8-9 years ago http://en.wikipedia.org/wiki/List_of_Intel_Xeon_microprocessors#.22Irwindale... don't know if you have 2x CPUs but, even then, your CPU power is very very low if I got the CPU model correctly. On Wed, May 14, 2014 at 3:25 PM, Mimiko wrote:

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 address natively only 3 and a half.

...

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 thought my hardware is crap and when I saw it's at least twice as fast as yours, I thought that's the problem.

Well, I don't know what to say about hardware. Mysql is on IBM System x3100 M3 with Xeon X3400 CPU, and otrs is on Fujitsu Siemens Primergy Econel 200 with Intel Xeon 2.8GHz CPU. This isn't enough for normal run for 20 agents and 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

Hi,

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.

RedHat, CentOS, Ubuntu, Debian, (Open-)SuSE as well as all Distributions with good perl integration are performing well. There are/were some issues if you use specific distributions and their online repository, but if you install from source or rpm (and follow the install.md) it should work + perform fine! How many concurrent users do you have, and what is your (virtual) hardware settings? Florian