Performance OTRS und Benchmark

[larf]

Hi,

Ich bin gerade dabei, OTRS auf einem niegelnagelneuen Server (2 QuadCore mit 1.86GHz, 4 GB RAM) einzurichten. Bisher bestand das aus der Grundinstallation Centos 5, zusätzlich die von OTRS 2.2.3 benötigten Pakete (MySQL-DB und "Perl-Zubehör") und das rpm von OTRS.

Da wir mit dem alten Server enorme Performance-Probleme (ätzend lange Datenbankabfragen) hatten, liegt mein Augenmerk ganz klar darauf.
Jetzt habe ich mal das Benchmark laufen lassen (auf dem System mit 2-3 Tickets):

Der Test mit der Oberfläche war ok, da kann man nicht meckern:

Code: Select all

Ergebnis: Oberfläche
Schlüssel	Wert	Zeit
Request:	1	0 s
Request:	2	1 s
Request:	3	1 s
Request:	4	0 s
Request:	5	1 s
Request:	6	0 s
Request:	7	1 s
Request:	8	0 s
Request:	9	1 s
Request:	10	0 s
Module:	AgentTicketQueue	5 s :-)

Weniger zufrieden bin ich aber mit dem SQL-Benchmark:

Code: Select all

Ergebnis: SQL
Schlüssel	Wert	Zeit
Insert Time:	10000	1 s :-)
Update Time:	10000	5 s :-(
Select Time:	10000	6 s :-(
Delete Time:	1	0 s :-)
Multiplier:	* 1

Gut, das ist immerhin bei manchen Werten 10 Sekunden besser als das alte Produktiv-System, aber wirklich überzeugend ist das nicht.

Daher:
1. irgendwelche zielstrebigen Ideen, wie ich die Datenbank optimieren kann?
Ich habe mich kürzlich zwar ein wenig eingelesen, aber auf meinem Testsystem konnte ich so auch nur 1-2 Sekunden im Benchmark herausholen.
2. hat jemand, insbesondere bei den Werten für Update und Select überhaupt mal mit einer MySQL-Datenbank bessere Werte herausgeholt?

[Andre Bauer]

Wann genau hast Du denn überhaupt Performanceprobleme im Produktivsystem?

Bei unserer Installation ist eigentlich nur die Suchfunktion der Flaschenhals, was sich aber mit einem separaten Suchserver per Mysql Replikation gut kompensieren lässt.

Siehe auch: http://www.otrs-forum.de/viewtopic.php?f=18&t=333

[larf]

Wann genau hast Du denn überhaupt Performanceprobleme im Produktivsystem?

Bei unserer Installation ist eigentlich nur die Suchfunktion der Flaschenhals, was sich aber mit einem separaten Suchserver per Mysql Replikation gut kompensieren lässt.

Problem war/ist besonders, dass der Server in Hochzeiten einfach ausgelastet war, die Load ging hoch, wodurch quasi alles blockiert wurde - das dürfte mit dem neuen Server definitiv besser aussehen.
Die Suchanfragen sind natürlich auch hier der Flaschenhals - insbesondere hatten wir den Fehler gemacht, zunächst bestimmten Usern den StatusView zu verwehren ($Chef: "Dann gucken die nur da rein und achten nicht auf die Eskalationen, das geht nicht!"). Das hat die allerdings wenig interessiert und sie haben sich einfach mit den Suchanfragen ihren eigenen StatusView gebaut - wenn dann 2-3 Leute im Minutentakt diese Suchanfragen auf die Datenbank loslassen ist das Unheil vorprogrammiert.

Der alte Server war aber auch schlicht und einfach nicht ausreichend ausgestattet, das ist 100% klar. Deshalb bin ich auch ganz einfach etwas enttäuscht, dass mir das Benchmark nun keine superdupertollen Ergebnisse anzeigt.

Siehe auch: http://www.otrs-forum.de/viewtopic.php?f=18&t=333

Jupp, hab ich schon mal gesehen und wäre für mich noch eine nette Option, falls der Umzug auf Dauer nichts bringt.

[Andre Bauer]

Wir haben hier die Erfahrung gemacht, dass das Aulagern der Suchanfragen vollkommen ausreicht.

Load Probleme gibt es seit dem nicht mehr.

Ist halt auch noch abhängig davon, wie viele User auf dem System gleichzeitig arbeiten.

[larf]

Wir haben hier die Erfahrung gemacht, dass das Aulagern der Suchanfragen vollkommen ausreicht.

Load Probleme gibt es seit dem nicht mehr.

Ist halt auch noch abhängig davon, wie viele User auf dem System gleichzeitig arbeiten.

Und natürlich auch davon, was diese User machen.

Ich hatte bis vor kurzem auch noch die Attachments in der Datenbank liegen, was laut OTRS-Consultant auch bei Anhängen bis 16 MB kein Problem ist - Problem wurde dann aber die Tatsache, dass wir Queues haben, in denen in jedem Ticket 5 Word-Dateien angehängt sind. Die Umstellung auf StorageFS (dank dem guten Script hier im Forum ) hat da schon enorm viel bewirkt.

[Andre Bauer]

Was auch noch helfen würde wäre, wenn man die Suche Standardmäßig auf einen einstellbaren Zeitraum (z.B. 3 Monate) beschränken könnte.

Dann wären die Volltextsuchen im MySQL weit weniger Lastintensiv.

Steht auch schon ne Weile auf meiner Wunschliste: http://bugs.otrs.org/show_bug.cgi?id=1639

[fluxkompensator]

Hallo ,

leider ein wenig Offtopic aber ist das ein fertiger Benchmark ? Wo kann man den starten ?

[jojo]

Über den Paketmanager installierbar....

[fluxkompensator]

ach das ist der Benchmark, na dann weiß ich bescheid, danke