Wie begründet sich dann der massive Performanceverlust wenn das refactoring noch nicht fertig ist? Verdreifachung der Ladezeiten ist hier im Forum immer mit den vielen neuen Features begründet worden.
Ich finde Tickets manchmal für euch wohl unzumutbar wenn es um Kleinigkeiten geht wie Optik oder so. Weil ich sehe wie viel mehr Aufwand ein Ticket ist für euch: Frau Wigger liest es, stellt zurück und verteilt, noch wer liest es, wortreiches formalisiertes Feedback, Rückfragen, ... Da habe ich bei 149 eur Hemmungen euch mit Tickets zu überschwemmen
Gerade weil das Refactoring noch nicht abgeschlossen ist, ist es ja so langsam. Die neue Oberfläche im Admin ist nur mit einigen Kniffen auf viele Seiten aufgesetzt worden und das kostet leider Ladezeit.
Beim Begriff Performance ohne nähere Eingrenzung hab ich etwas Bauchweh. Von welcher Performance reden wir denn hier gerade? Die Frontend Performance ist aktuell schon gar nicht übel, da sehen wir keine grossen Baustellen. Das Backend hat gerade in 3.1 auch wieder ein Stück Geschwindigkeit dazugewonnen. Worum geht es also genau, wenn du sagst etwas ist zu langsam?
Um die Backend-Performance (ist doch allgemein bekannt und vielfach moniert, oder?) start.php (Umsatzstatistik-Grafik): Mittlere Ladezeit 4-7 Sekunden orders.php bei Anzeige von 50 Bestellungen: Mittlere Ladezeit 4-5 Sekunden orders.php bei Anzeige von 100 Bestellungen: Mittlere Ladezeit 6-8 Sekunden Ladezeit für eine Einzelbestellung 3 Sekunden Wenn man dann auf Touch-Bildschirmen den Status nicht auf der Übersichtsseite umstellen kann, sinds dann 4 Sekunden zum Aufruf der Übersicht, 3 Sekunden für das Aufrufen der Bestellung, 1 Sek für den Status und 4 Sekunden zur Rückkehr auf die Bestellübersicht. Macht zusammen nur für das Umstellen eines Status 12 Sekunden. Nervig auch: Bestellungen telefonisch aufnehmen. Die ganzen Ladezeiten für Anlegen von Kunden, erstellen von Bestellungen, Hinzufügen von Positionen etc - da weiß ich schon immer gar nicht mehr was ich noch am Tel smalltalken soll, während ich die Bestellung erfasse. Aber wenn es dann nach dem Refactoring besser wird - ok, dann störe ich euch mit meinen Foren-Beiträgen nicht mehr bei der Arbeit und warte ab und hoffe, dass der JTL Connector auch laufend angepasst wird an die neuen Master Updates... PS: In wie weit unsere fehlende Komplett-SSL-Verschlüsselung und unsere Breitbandverbindung (DSL 16.000) mit den Ladezeiten was zu tun haben bleibt dahingestellt. PPS: Ladezeiten gerade nochmal anhand von je 10 Ladevorgängen nachgemessen, allerdings mit 3.0.2.0 und nicht mit 3.1
start.php (Umsatzstatistik-Grafik): Mittlere Ladezeit 4-7 Sekunden orders.php bei Anzeige von 50 Bestellungen: Mittlere Ladezeit 4-5 Sekunden orders.php bei Anzeige von 100 Bestellungen: Mittlere Ladezeit 6-8 Sekunden Dem stimmt ich so zu. Es liegt auch nicht an der Breitbandleitung. (Hier getestet mit Glasfaser mit 200 MBit im Down- und Upload und einmal mit 100MBit in beide Richtungen (anderes Haus)).
Vor einer Weile vielfach und pauschal moniert heisst nicht, dass das alles heute noch seine Gültigkeit hat... allgemein würde ich sagen ist es um das Thema vergleichsweise ruhig geworden. Jeder will immer schneller, aber sehen wir doch mal wo wir stehen. Ihr habt Beispiele, wir messen: Ich war gerade mal im Shop von nito und habe empirisch mit dem Firefox gemessen. Aus der Riege der grossen Browser ist der tendenziell der etwas langsamere. Ich bekomme dort für die Admin-Startseite Zeiten zwischen 3-3,5 Sekunden. Das ist noch nicht grossartig, die Seite ist aber auch noch im Kern alt. Mit 3.1.3.0 kriegt die auch schon wieder einen kleinen Boost, weil wir jetzt nochmal etwas Altlasten entsorgen konnten. Dann habt ihr die orders.php genannt, vereinfachen wir das mal auf den Begriff Bestellübersicht, denn die orders.php ist ab 3.1 aufwärts Schnee von gestern und wird normal nicht mehr benutzt. In Nitos Shop messe ich nun 6 Sekunden für die neue Bestellübersicht mit 100 Bestellungen, 3 Sekunden zum Wechsel zu den nächsten 100 Bestellungen (Seite2). Wenn ich die alte Bestellübersicht vergleiche (kann man in 3.1 noch optional zusätzlich sichtbar machen...), bekomme ich dort 8 Sekunden für die ersten 100 Bestellungen, weitere 8 Sekunden für den Wechsel auf die nächste Seite. Ich bin also beim Laden der neuen Seite beim ersten Aufruf 25% schneller, für Folgeseiten 62,5% schneller. Dazu habe ich in der neuen Bestellübersicht recht flinke Filter und mehr Informationen zur Bestellung gleich im Blick. Die stecken im mehr an Spalten und in den Tooltips, deren Informationen auch direkt geladen werden, damit die Tooltips nicht ewig dauern. Das finde ich einen guten Fortschritt, wir sind da aus unserer Sicht am Ziel. Touchgeräte sind aktuell nicht unser Fokus im Backend. Wir gehen im Backend von üblichen PC-Eingabegeräten aus, anders als im Frontend, das mit Touchgeräten laufen muss. Die Bestelldetailseite ist noch alt, die muss auch noch neu. Einen oder mehrere Bestellungen schnell im Status zu verändern, geht aber in der neuen Bestellübersicht mit PC-Eingabegeräten recht fix und ohne übermässige Mauswege von der Hand. Ja, das kann ich mir grob vorstellen. Wollen wir gern verbessern, dazu müssen wir nur weiter an den Grundfesten des Shops herumreissen dürfen, wir sehen das Mandat dazu aber auch als gegeben an. Die Bestellerfassung kann zum Beispiel nicht neu werden bevor die Preisberechnung und der Checkout neu gebaut sind, das macht einfach 0 Sinn. Es hat anders einfach keine Chance richtig gut zu werden und Halbwertszeit zu bekommen. Auch hier sehen wir damit das Mandat als gegeben an. JTL macht wie viele ERP Anbieter aus unserer Sicht etwas blödes: Direkt in der Datenbank rumhämmern. Das kann nicht pflegeleicht werden, das wird immer und immer wieder scheppern, da haben wir Jahre an praktischen Erfahrungen vorzuweisen. Wir wollen die nie ärgern, aber jeder kleine Bugfix am Shop hat Crashpotenzial. Das muss aufhören. Darum bauen wir am Fundament. Wir müssen die neue API fertig bekommen und die ERP Leute dann alle daran binden. Es ist schon viel da, aber für die Universalität die benötigt wird fehlen noch ein paar Ecken. ERP Systeme sind dabei die Premierleague, nichts anderes will an mehr verschiedene Informationen geregelt heran. Das fehlende SSL gar nicht, deswegen hast du andere EInbussen (Google,...). Die DSL-Bandbreite ist ok, solange die Leitung nicht hochlatent ist, das wird sie nicht sein. Am Ende sei nochmal gesagt: Der Wunsch nach Stabilität (die grossen Projekte anhalten) und der gleichzeitige Wunsch nach Performance und Usability sind exklusiv. Das eine oder das andere. Wir verheiraten beides ein Stück und balancieren das nach Möglichkeit aus, aber irgendwas bleibt dabei immer zumindest etwas auf der Strecke. Willkommen in unserer Welt
Ich finde die Aussagen zum Teil etwas widersprüchlich, was wiederum verständlich ist, denn weder "wir lassen alles wie es ist und konzentrieren uns nur auf Bugs" noch "wir machen nur noch Refactoring und nichts Anderes" ist richtig. Der goldene Mittelweg ist richtig, den gehen wir. Dass dieser Mittelweg für den einen von euch etwas weiter links und für den nächsten weiter rechts liegen sollte ist logisch, aber damit müssen wir leben. Ja, aber: Die großen Probleme gab es mit den ersten Versionen des neuen Admin. Inzwischen hat sich das schon massiv verbessert und mit jedem SP wird es wieder etwas besser. Zudem finde ich, dass das reine Messen von Ladezeiten wenig Aussagekraft hat. Entscheidend ist, wieviel Zeit du insgesamt benötigst um eine Aufgabe zu erledigen. Wenn wir nun viel mehr auf einer Seite unterbringen und dadurch die Ladezeit steigt, kann das trotzdem dazu führen, dass du deine Aufgabe insgesamt viel schneller erledigst. Auf den Seiten, die inzwischen komplett neu gemacht wurden, ist das aus meiner Sicht bereits der Fall, z.B. die Bestellübersicht. Dieses Beispiel finde ich nicht ganz fair. Wir geben uns Mühe insbesondere die neu entwickleten Seiten im Admin Mobile-fähig zu machen, wir gehen aber ganz klar davon aus, dass in aller Regel die Arbeit im Admin am Desktop stattfindet. All unsere Erkenntnisse bestätigen dies auch. Wenn du nun also Mal von unterwegs einen Status ändern willst, dann soll das funktionieren. Wenn das dann aktuell mal 4 Sekunden länger dauert als im alten Admin finde ich das in Ordnung. Die Optimierung für die Arbeit am Desktop ist aber enorm und das sollte hier dann auch nicht fehlen. Was wir dazu in den letzten Wochen an Feedback bekommen haben ist nämlich ziemlich stark. Durch die Möglichkeiten der neuen Bestellübersicht scheinen viele Händler nämlich tatsächlich massig Zeit zu sparen, weil eben sehr vieles direkt aus der Übersicht heraus funktioniert. Ich würde gern ein Szenario durchspielen. Natürlich arbeitet jeder Shopbetreiber anders, aber dies hier ist ein durchaus realistischer Ablauf eines durchschnittlichen Shopbetreibers: Wieviele Sekunden dauert es folgende Aufgaben zu erledigen: - Rufe die Bestellübersicht auf - Ändere den Bestellstatus von Bestellung 1,2,3 (von oben) auf den Status "In Bearbeitung". - Ändere den Bestellstatus von Bestellung 4 (von oben) auf den Status "Versendet". - Füge Bestellung 4 die Sendungsnummer 0123456789 hinzu. - Lösche die Bestellungen 5,6 - Finde heraus wieviele Bestellungen zwischen 1 und 10 ins Ausland gehen. a.) alter Admin b.) neuer Admin mit alter Bestellübersicht c.) neuer Admin mit neuer Bestellübersicht Lass uns das bitte wirklich mal machen, denn es zeigt aus meiner Sicht ganz konkret woran wir arbeiten und was wir versuchen, nämlich die tägliche Arbeit zu vereinfachen. Die Bestellübersicht die erste Seite die wir umgesetzt haben wegweisend dafür, wo wir nach und nach mit dem ganzen Admin hinwollen. Bitte mal die Gesamtzeit stoppen und hier posten. Ein Abendessen zu zweit aus meiner persönlichen Tasche, für denjenigen der es schafft bei a oder b schneller zu sein als bei c. Kann ich gut verstehen, das ist wirklich schlimm. Die Bestellnachbearbeitung und dazu gehört auch das manuelle Anlegen von Bestellungen begleitet uns seit Jahren. Sie wurde immer mal wieder ein wenig verbessert, so dass man überhaupt einigermaßen damit arbeiten kann, aber dieses Feature ist jenseits von gut und böse. Wir hätten das Teil auch schon längst mal richtig in Angriff genommen, wenn man dafür nicht den halben Shop umbauen müsste. Sobald wir aber mit dem Refactoring der betreffenden Bereiche weiter sind, wird es ein Kinderspiel sein die Bestellnachbearbeitung auf ein sehr gutes Niveau zu bekommen. Es ist mir wichtig zu verstehen, dass "Refactoring" nicht irgendetwas Abstraktes ist, das wir aus Freude am Entwickeln tun. Es ist der Schlüssel dazu, sehr viele euch ganz konkret betreffende Probleme zu lösen, deren Lösung auf herkömmlichen Wege ewig dauern und das System nur noch komplizierter machen würde.
Wenn das eine Antwort an mich ist, bin ich wohl falsch verstanden worden: Ich verstehe den Sinn von Refactoring. Mein Anliegen war nicht, grundsätzlich erstmal ein fehlerfreies System basierend auf altem Code zu basteln, um dann beim Refactoring neue Fehler einzubauen, die gefixt werden müssen. Mein Vorschlag war, erstmal alle Bugs in den Bereichen, die fertig refactorized sind zu fixen um mehr Stabilität reinzubringen und mehr Zufriedenheit. Danach auf dieser neuen stabileren und zweckmäßigeren Basis weiterentwickeln. Bugfixes für Funktionen die ohnehin noch überarbeitet werden sollen machen keinen Sinn, da sind wir uns ja alle einig: Dennis, Wilken, nito, du und ich. Das widerspricht sich mit Dennis' Aussagen. Ist aber auch egal, du bist der Gambio Chef und kennst den aktuellen Entwicklungsstand besser. Dann ist also die Bestellübersicht jetzt so fertig, und da könnte man beispielsweise anfangen, d.h. alle 203 offenen Tickets aus der Liste Features Candidates daraufhin prüfen, ob das nur die Bestellübersicht betrifft und das schonmal fixen? Oder ist das zu einfach gedacht? Ok, geschenkt. Gut, das brauchen wir vermutlich nicht testen / messen. Dann ist das eine deutliche Verbesserung, von der nur wir bisher nicht profitieren können, weil wir anders arbeiten müssen: Jede Bestellung einzeln aufrufen um zu schauen, ob die Artikel zusammenpassen, ob Dropshipping-Artikel dabei sind, ob wieder mal Adresskorrekturen durchgeführt werden müssen, ... Daher kommen wir selten in den Genuss der Multi-Bestellstatusbearbeitung. Will hier auch gar nicht stänkern oder so, grundsätzlich läuft das alles ja ganz gut mit Gambio. Es wurde halt nur nach Ideen zur Verbesserung des Ticket- und Bugfixing-Trackings und der Prioritäten gefragt. Dann kann ich ja Ideen / Wünsche schreiben. Wie auch immer ihr das handhaben wollt und werdet: Ich denke, dass ihr auch Kunden habt, die auf Stabilität, Kontinuität und Robustheit mehr Wert legen als auf brandneue Features. Und das kann für manche ein schlagendes Kaufargument (bzw. Supportverlängerungs- oder Neuabschlussargument) sein. Und bevor jetzt WIEDER jemand mit dem Argument kommt, dass Bugfixes in zu überarbeitendem Code keinen Sinn machen, sage ich es nochmal ausdrücklich: Das ist mir klar und allgemeiner Konsens und braucht nicht mehr angeführt wreden, wenn sich die Diskussion nicht weiter im Kreis drehen soll... Danke jedenfalls für eure ausführlichen Antworten und eure offenen Ohren (bzw. hier eher Augen). VG
Alles ganz gut, nur eine Sache aus unserer Logik fehlt dir noch: Der Unterschied zwischen Feature Candidates und SP-Candidates. SP Candidates erfasst Bugs, die anerkannt sind, und möglichst zeitnah ohne Wartezeit in Ordnung gebracht werden sollen. Feature Candidates enthält Einträge, die irgendwann kommen könnten und auch grössere Dinge umfassen. Das man die Listen hin und wieder mal aufräumen muss ist natürlich wahr, da könnten inzwischen erledigte Tickets drin sein. Das läuft immer beiläufig bei uns, da übersehen wir manchmal Dinge.
Da müsstest Du mit der neuen Bestellübersicht aber auch besser arbeiten können. Man kann schon in der Übersicht die Artikel sehen (in einem PopUp wenn man mit der Maus über die Bestellnummer fährt) Ebenso die Liefer- und Rechnungsadresse. Man muss nicht mehr jede Bestellung öffnen um die Daten prüfen zu können.
War nicht an dich gerichtet, sondern eher allgemein gemeint. Widersprechen tut es sich nicht finde ich, war aber unsauber formuliert. "Fertig" ist ein Status den man so gut wie nie erreicht. Die neue Bestellüberischt ist inzwischen soweit, dass Sie bereit ist für den produktiven Einsatz und mit dem jetzigen Zustand eine deutliche Verbesserung zur Alten Lösung in nahezu allen Anwendungsfällen darstellt. Aber natürlich gibt es auch bei der Bestellübersicht noch genug zu tun. Jetzt jedoch erstmal alle bekannten Bugs der Bestellübersicht zu fixen, wäre aber aus meiner Sicht wirklich zu kurz gedacht. Dann hätten wir zwar eine nahezu bugfreie Bestellübersicht, aber macht es nicht mehr Sinn generell Bugs nach Ihrer Dringlichkeit zu fixen, egal wo im Shop sie sich verstecken? Nach deiner Variante würde ein kleiner, unerheblicher Bug in der Bestellübersicht Vorzug vor einem schweren Bug im Checkout bekommen, das dürfte shwer vermittelbar sein. Eine Priorisierung ist also wichtig und das tun wir ja auch. Wir versuchen natürlich neue Features möglichst schnell, möglichst stabil zu bekommen, aber wägen dabei trotzdem jedes Ticket einzeln ab. WIe Barbara schon schrieb: Wir haben versucht, die allermeisten bestellrelevanten Infos bereits aus der Übersicht zugänglich zu machen. Dazu gehören auch die Artikeldaten. Fehlt dir da noch irgendwas oder habe ich deinen Ablauf nicht ganz richtig verstanden. Das kommt auch gar nicht so rüber und die Diskussion ist sehr bereichernd. Auch wenn es nicht so wirken mag, ich habe schon mehrere Kleinigkeiten mitgenommen, wo ich nun wieder ein wenig besser verstehe, worauf es dir/euch ankommt und die ich ausprobieren will, um den Prozess bei uns noch ein wenig zu verbessern.
@Gambio, kann man denn mit der Behebung des Bugs Artikelnavigator (Zeilenumbruch) für die Finals 3.0.x.x und 3.1.x.x noch rechnen. Das wäre sehr nett.
Pinterest warf einen Fehler über eine ungültige BildURL wenn man einen Pin absetzen wollte. Der Fehler lässt sich hier bei uns aber gerade nicht mehr rekonstruieren, möglicherweise war bei Pinterest etwas kaputt?
Ich hab gerade nochmal den Artikelnavigator nachgeschaut, da ist noch kein Fix im Umlauf. Ich rechne aktuell nicht damit, dass das noch in 3.0.3.0/3.1.3.0 kommt.
Ok, dann sehen nicht nur wir, dass das wieder geht und machen mal einen vorsichtigen Haken an den Punkt. Lasst uns ab jetzt wieder ein wenig drauf achten diesen Thread nicht zum einem Gesprächspunkt über die Hintergründe konkreter kleiner Bugs der verschiedenen Versionen zu machen, und keine weiteren kleinen Bugs technisch hier besprechen, dann ist das Thema bald hinüber. Direkte Ansprache unter uns alten Haudegen: Featurewünsche gehören dann auch in Featurewünsche, es sei denn du möchtest darüber reden wie lange wir dich hier schon ignorieren und wie du dich dabei fühlst