OrderSprinter-Forum

Moin,

bei jeder Tageserfassung wird das Log wieder zurückgestutzt (allerdings absichtlich nicht ganz gelöscht, denn evtl. möchte mir ein Anwender ja gerade zeigen, dass ein Drucken des Tageserfassungsbons nicht funktioniert..)

Man kann das Log in der Konfiguration (in der Verwaltungsansicht) komplett abschalten.

Gruß,

Stefan

Servus,
und zwar habe ich gemerkt, dass "ordersprinter_log" immer größer und größer wird. Hier nun die Frage, ob und wie ich diese wieder entsprechend verkleinere, bzw. ob das überhaupt möglich ist?

Durch das "Datenbank optimieren" in Ordersprinter als auch in phpmyAdmin bekomme ich keine Erfolge.

Ich möchte meine Datenbank schließlich so klein und "schnell" wie möglich halten?


Grüße

Hallo Lutz,

danke für das Feedback. Das ist doch ein toller Erfolg!

Gruß,

Stefan

Soooo. Der Kunde hat den Montag "überlebt". In der Spitze waren 20 Kellner aktiv und 85 Tische offen. Keine Funktion hatte nach dem letzten Update eine längere Wartezeit als 4 Sekunden. Top!

Jetzt können wir mit weiteren Plugins weiter machen.

Gruß Lutz

Hallo Lutz,

MPM ist natürlich eine Option, die die Geschwindigkeit mit Sicherheit verbessert. Aber wäre nicht auch nginx eine Alternative, weil es das gleiche Thread-Konzept schon nativ fährt und noch ein paar andere nette Features enthält? Man kann dann noch ein wenig mit der http-Komprimierung spielen und auch dadurch noch etwas herausholen. Gut, das rate ich natürlich nicht jedem, weil es sehr viel Arbeit und Wissen voraussetzt. Aber du bist der Experte.

Schönes Osterfest,

Stefan

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

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

Brinko hat geschrieben: ↑Do 22. Mär 2018, 21:31 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

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

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