Langsames System

[irrsinn.de]

Hallo!

Wir haben einen Kunden (Ausflugslokal), der hat bis jetzt knapp 20.000 Belege in 3 Monaten produziert. Wir haben durch "Tuning" des MySQL und Apachen alles im Griff, es gibt aber ein Phänomen. Die Raumliste, die am Anfang unter Bestellungen aufgerufen wird dauert (ja nacht Last) zwischen 8 und 15 Sekunden. Wir haben uns daraufhin den Code angeschaut und uns ist aufgefallen, dass eine Funktion dafür verantwortlich ist, die wir aber dort garnicht brauchen:

In der roomtables.php wird ein Array zusammen gebaut - array of products and Ids of a table - DAS dauert solange und scheint, wenn man NUR mit Orderbons arbeitet garnicht nötig zu sein. Wenn wir diese Zeile auskommentieren, wird die Raumliste innerhalb von 1-2 Sekunden geladen. Die Frage ist, wofür genau wird diese Funktion genutzt oder ist unsere Vermutung richtig, wenn ich nicht mit Küchen-/Bar-Ansichten arbeite, brauchen wir die garnicht?! (Wir haben uns den Datenbestand mal auf unser Testsystem rüber geholt. Gebucht, abgerechnet, Tageslosung erstellt, Reports geprüft - läuft alles wie gewünscht. Bevor wir aber weiter den Code durchgehen, dachten wir uns, fragen ist schneller )

Gruß Lutz F.

[pichel]

Hallo Lutz,

ich werde mir die Funktion demnächst mal genauer anschauen, ist schon länger her, dass ich sie programmiert habe. Aber es ist wohl die Stelle, an der geschaut wird, welche Produkte für einen Tisch zubereitet wurden, um dies in der Bestellansicht darzustellen. Und dort hat der Kellner ja auch die Möglichkeit, die Zustellung per One-Click zu bestätigen.

Jetzt könnte man folgendes überlegen:
- Die Abfrage konfigurierbar abzuschalten
- Mit Indices in der DB beschleunigen
- Asynchron abzufragen und in die Tischanzeige einblenden, sobald die Daten eingetroffen sind.

Muss ich mir demnächst mal anschauen, vielleicht Ostern. Bisher hatte ich noch keinen Anwender, der mir von einer so langen Wartezeit beim Aufruf berichtet hat.

Gruß,

Stefan

[irrsinn.de]

Hallo Stefan,

wieviel OS-Installationen gibt es mit 7 Räumen, 100 Tische auf der Terrasse und unter Vollast 20 Kellner mit parallel bis zu 100 offenen Tischen? Je mehr wir uns der Vollast nähern umso schneller scheint das Tempo zu sinken. Wir nutzen bei diesem Kunden die Bestellansicht garnicht, ein keine Zustellung per One-Click. Dort sind nur Bondrucker für die Bestellungen im Einsatz. Zubereitung und Auslieferung läuft noch "fossil" per Bon. Wenn Du mir jetzt bestätigst, dass diese Funktion nur für die Bestellansicht ist, kommentiere ich sie erst einmal aus. Du kannst es dann in Ruhe überarbeiten aber der Kunde bleibt weiterhin begeistert

Gruß Lutz

[udgesbou]

Gegen Geschwindigkeitsgewinn hat denke ich niemand etwas
Deswegen hänge ich mich aus Interesse hier mal mit rein.

Wir haben durch "Tuning" des MySQL und Apachen alles im Griff, es gibt aber ein Phänomen.

Was hast du denn an “Tuning“ vorgenommen und welche Hardware hast du denn im Einsatz?

Danke schon einmal für die Rückmeldung.


Grüße

[Brinko]

Hallo Lutz,

ich möchte mir gerne mal eine Installation anschauen, die für eine Benutzung mit 20 parallel arbeitenden Kellnern ausgelegt ist. Wenn mich das überzeugt, werde ich gerne Kunde bei dir und lass mir auch eine solche maßgeschneiderte Lösung basteln. Verrätst du uns den Namen des Betriebs?

Brinko

[pichel]

In der 1.5.4, die bald rauskommt, ist das Feature "Zeige Anzahl vorbereiteter Produkte in mobiler Tischansicht an" abschaltbar. Damit wird die Abfrage nicht mehr durchgeführt.

Die Query ist schon seit Ewigkeiten im Code und war noch aus der Zeit, als ich meine ersten Gehversuche mit SQL gemacht habe. Trotzdem frage ich mich, ob ein System, dass bei dieser Abfrage 8-15 Sekunden benötigt, nicht noch ein ganz anderes Problem hat (Festplatte über PIO eingebunden?).

Ich habe mein Testsystem mit einer riesigen Masse an automatisch generierten Testdaten geflutet, konnte aber beim besten Willen nicht mal eine halbe Sekunde Laufzeit der SQL-Query hinbekommen.

Gruß,

Stefan

[irrsinn.de]

Ich habe mein Testsystem mit einer riesigen Masse an automatisch generierten Testdaten geflutet, konnte aber beim besten Willen nicht mal eine halbe Sekunde Laufzeit der SQL-Query hinbekommen.

Lege 5 Räume an mit jeweils 30-100 Tischen an. Buche da parallel mit 10-15 Kellnern entsprechenden Umsatz drauf, habe 50-60% der Tische zu Spitzenzeiten offen ... ach so und "fluten" ist nicht (haben wir am Anfang auch gemacht), dann werden die meisten MySQL-Anfragen gecached. Interessant wird es, wenn die Daten (parallel, wie oben beschrieben) "wachsen".

Gruß Lutz

[irrsinn.de]

Hallo Lutz,

ich möchte mir gerne mal eine Installation anschauen, die für eine Benutzung mit 20 parallel arbeitenden Kellnern ausgelegt ist. Wenn mich das überzeugt, werde ich gerne Kunde bei dir und lass mir auch eine solche maßgeschneiderte Lösung basteln. Verrätst du uns den Namen des Betriebs?

Brinko

Schreib mich mal per Direktnachricht an, Deinen Namen finde ich hier im System nicht.

Gruß Lutz

[pichel]

Hallo Lutz,

na ja, so in etwa sah mein Testszenario aus - die parallel arbeitenden Kellner habe ich allerdings nicht so gut simuliert, hier fehlt mir schlicht die Zeit zum Proggen, zumal die größte Anwendergruppe kleinere Betriebe mit OrderSprinter fährt. Ich nehme an, dass es weniger die schlechte Query ist als die Transaktionen durch den parallelen Zugriff vieler Kellner, die ständig zu Locks führen und dadurch das Gesamtsystem langsam machen. Es gibt dafür spezielle Analysetools, wenn du viel Zeit hast, kannst du in die Auswertung viel Zeit versenken...

Jedenfalls habe ich gerade 1.5.4 veröffentlicht, in der ich einige deiner Wünsche umgesetzt habe.

Aber ich schließe mich Brinko an, auch mich würde der Betrieb interessieren. Keine Sorge, ich habe keine Motivation, mich da einzumischen, ich find's einfach schön zu erfahren, wo meine Software so läuft.

Gruß,

Stefan

[irrsinn.de]

Frohe Ostern!

Ich kläre das mit dem Betrieb, ob wir den als Referent nennen können. Das Update sieht sehr gut aus. Und Du hast Recht, der Apache liefert teilweise nicht. Das sind wir nun so "umgangen", dass wir den auf MPM umgestellt haben und der der mpm_prefork.conf die Werte hochgezogen haben. Sieht alles vielversprechend aus. Mal sehen wie sich das System am Ostermontag schlägt (da wird die Hölle los sein).

Gruß Lutz