nicht angemeldet
Systemverfügbarkeit
Vor kurzem ist unser neuer Webauftritt online gegangen. Das Ganze hat etwa 5 Stunden gedauert, bis ich alle Beteiligten überzeugt hatte, das es besser ist, die alte Konfiguration wieder herzustellen. Das neue System, was eine Agentur für uns ausgearbeitet hat, (mit deren Leistung wir ohnehin nicht zufrieden sind), ist umgehend unter "Last" zusammengebrochen. Meine im Vorfeld an die Agentur gestellte Forderung, Lasttests durchzuführen wurde ignoriert. Die Beratungsresitenz der Agentur ist kaum zu übertreffen, auch in anderen Dingen.
Nun werden laufend Tests gemacht, speicherdumps zum Hersteller des CMS geschickt um das Problem in den Griff zu bekommen und weitere schwachsinnige Maßnahmen, wie das zusammenführen von statischen Inhalten wie CSS und JS in eine globale Datei.
Ich bezweifele dass das Problem in den Griff zu bekommen ist, da ich quasi von zu Hause aus, ohne Botnezt o.ä. im Moment den Server zum "kotzen" bringen kann. Das eigentliche Problem was ich habe, eine vernünftige Argumentation gegenüber meinen Vorgesetzten zu finden, das Projekt nicht mehr dieses Jahr zu Launchen, sondern erst wenn sicher gestellt ist, dass es stabil läuft. Die "Bosse" sind der Meinung, dass es unbedingt noch vor Weihnachten sein muss.
Irgendwelche Anregungen dazu?
Gruß Markus**
-
Das eigentliche Problem was ich habe, eine vernünftige Argumentation gegenüber meinen Vorgesetzten zu finden, das Projekt nicht mehr dieses Jahr zu Launchen, sondern erst wenn sicher gestellt ist, dass es stabil läuft.
Wenn denen das nicht schon Argument genug ist, lass dir bescheinigen dass es so wackelig wie es momentan ist on gehen MUSS, dann bist du raus.
-
Moin!
Du hast ein technisches Problem, und bist offenbar dicht genug an der Aufgabe dran, dass man dir Verantwortlichkeit zuweisen kann - und sei es nur, weil "du dich ja auskennst und es dein Job ist", die Chefs aber nicht.
Trenne Politik von Technik. Die Politik ist, dass jetzt Fingerpointing und Verantwortungszuweisung passiert und irgendwer um eine Kopflänge kürzer gemacht werden könnte. Das ist vermutlich nicht deine Aufgabe.
Deine Aufgabe ist augenscheinlich, zu machen, dass es läuft. Konzentriere dich darauf. Finde Lösungen, mit denen das sichergestellt werden kann. Tools dafür gibts reichlich, nutze sie.
Vor kurzem ist unser neuer Webauftritt online gegangen. Das Ganze hat etwa 5 Stunden gedauert, bis ich alle Beteiligten überzeugt hatte, das es besser ist, die alte Konfiguration wieder herzustellen. Das neue System, was eine Agentur für uns ausgearbeitet hat, (mit deren Leistung wir ohnehin nicht zufrieden sind), ist umgehend unter "Last" zusammengebrochen. Meine im Vorfeld an die Agentur gestellte Forderung, Lasttests durchzuführen wurde ignoriert. Die Beratungsresitenz der Agentur ist kaum zu übertreffen, auch in anderen Dingen.
Das bedeutet, dass ihr als Auftraggeber Abnahmekriterien definieren müsst, die die Agentur zu erfüllen hat. Sowas ist natürlich idealerweise schon ganz zu Beginn geschehen, ohne Frage aber kann nicht vereinbart gewesen sein, dass der neue Webauftritt von der Menge an Usern, die den alten besuchen, nicht verkraftet wird.
Insofern ist ein softes Abnahmekriterium nach meiner Auffassung: Neue Website kann die alte Last aushalten. Unter der unumgehbaren Bedingung, dass dieselbe Hardware genutzt wird.
Jetzt ist das Problem natürlich: Was ist Last? Last ist nicht, ausschließlich die Startseite mit Apache-Benchmark tausendfach abzurufen und zu gucken, wie toll der Cache arbeitet. Realistische Last zu erzeugen ist eine Kunst. Realistische Aussagen eines realistisch konfigurierten Last-Tests lassen sich auch nur mit realistischer (sprich: produktionsidentischer) Hardware treffen.
Ein Lasttest sollte also mindestens mal die Aktivitäten umfassen, die User gewöhnlich auf der Website entfalten - und sofern die alte Website dasselbe geboten hat, ergeben sich daraus auch die Relationen, wieviele User wieviele unterschiedliche Dinge auf der Site tun. Ein Lasttest muss solche Usecases in realistischer Mischung und Menge abbilden.
Nun werden laufend Tests gemacht, speicherdumps zum Hersteller des CMS geschickt um das Problem in den Griff zu bekommen und weitere schwachsinnige Maßnahmen, wie das zusammenführen von statischen Inhalten wie CSS und JS in eine globale Datei.
Ist nicht schwachsinnig, aber es ist Optimierung an einer Stelle, die vermutlich keine entscheidende Auswirkung hat.
Ich bezweifele dass das Problem in den Griff zu bekommen ist, da ich quasi von zu Hause aus, ohne Botnezt o.ä. im Moment den Server zum "kotzen" bringen kann. Das eigentliche Problem was ich habe, eine vernünftige Argumentation gegenüber meinen Vorgesetzten zu finden, das Projekt nicht mehr dieses Jahr zu Launchen, sondern erst wenn sicher gestellt ist, dass es stabil läuft. Die "Bosse" sind der Meinung, dass es unbedingt noch vor Weihnachten sein muss.
Solange keine objektiven Kriterien auf dem Tisch sind, die definieren, was "akzeptables Verhalten" der neuen Website ist, solange ist jede Diskussion darüber unsinnig, weil ausschließlich mit Bauchgefühl argumentiert wird. Dein "Ich glaube nicht, dass die Website der Last standhalten wird" steht ein "Ich glaube DOCH, dass die Website der Last standhält" der Vorgesetzten entgegen. Und der einzige Beweis ist ein erneuter Launch und das Gucken, wer dann Recht behält.
Auf der anderen Seite: Kümmert es dich? Wie tief hängst du da mit drin, wenn es nicht läuft? Es klingt zwar Scheiße, aber je nach Schwere der Verantlichmachung ist "Cover your ass" jetzt vermutlich eine gute Idee, wenngleich es ziemlich negative Auswirkungen aufs Unternehmen hat, wenn die IT ständig im Cover-your-ass-Modus operiert. Das verhindert nämlich sehr effektiv Innovationen, weil niemand mehr bereit ist, ein Risiko einzugehen.
Auch ein unter großem Getöse gegen die Wand gefahrenes Projekt, welches im Nachgang zu den üblichen rollenden Köpfen geführt hat, hat in der Regel solche Auswirkungen. Wenn die Firmenkultur es nicht erlaubt, schon kleine Fehler zu benennen und zu beheben, sondern zum Totschweigen zwingt, bis der Fehler nicht mehr übersehen werden kann, und als Konsequenz dann Köpfe rollen (natürlich nicht die der Chefs), dann ist der Firma eigentlich nur ein baldiges Ableben zu wünschen.
Leider erfüllen sich solche Wünsche zu selten.
Irgendwelche Anregungen dazu?
Hattest du nicht früher schon mal etwas haarsträubende Geschichten gepostet? Falls ja: Hast du über das Suchen einer neuen Stelle schon nachgedacht? Im Moment werden erfahrene Entwickler wie die Nadel im Hauhaufen von allen Plattformen, Headhuntern und IT-Abteilungen gesucht und nicht gefunden.
- Sven Rautenberg
-
Moin!
Moinsen! ;)
Deine Aufgabe ist augenscheinlich, zu machen, dass es läuft. Konzentriere dich darauf. Finde Lösungen, mit denen das sichergestellt werden kann. Tools dafür gibts reichlich, nutze sie.
Naja - ich muss im Grunde nicht "machen dass es Läuft" sondern hier eher versuchen einer, wie schon erwähnt ziemlich beratungsresistenten Agentur, die Aufgabe überlassen.
Natürlich habe ich mir auch die Logfiles nach deren "Lasttests" angesehen. Problem dabei ist das Verhältnis statischer zu dynamischer Inhalte die geladen werden. ca 15statisch:1dynamisch. Werden also pro Seitenaufruf 16 Anforderungen an den Server gestellt. 15 Mal mit < 50ms beantwortet aber ein Mal dauert es knapp 2 Sekunden, wenn's gut läuft. Gibt im Schnitt aktzeptable 170ms. Trotzdem doof, weil unrealistisch. Dauert ja erstmal 2 Sek bis das DOM soweit ist, um dem Browser zu sagen was er an statischen Daten nachladen muss.Das bedeutet, dass ihr als Auftraggeber Abnahmekriterien definieren müsst, die die Agentur zu erfüllen hat. Sowas ist natürlich idealerweise schon ganz zu Beginn geschehen, ohne Frage aber kann nicht vereinbart gewesen sein, dass der neue Webauftritt von der Menge an Usern, die den alten besuchen, nicht verkraftet wird.
Genau - wir prüfen grade ob evtl. im Vertrag ein "Launch" als "Abnahme" gilt um ggf. einen Hinweis auf das Beharren des Website-Starts von Seiten der Agentur zu bekommen. Die sollten selbst wissen, dass das Projekt eigentlich noch nicht online gehen kann.
Insofern ist ein softes Abnahmekriterium nach meiner Auffassung: Neue Website kann die alte Last aushalten. Unter der unumgehbaren Bedingung, dass dieselbe Hardware genutzt wird.
Ein Lasttest sollte also mindestens mal die Aktivitäten umfassen, die User gewöhnlich auf der Website entfalten - und sofern die alte Website dasselbe geboten hat, ergeben sich daraus auch die Relationen, wieviele User wieviele unterschiedliche Dinge auf der Site tun. Ein Lasttest muss solche Usecases in realistischer Mischung und Menge abbilden.
Genau... (siehe auch oben) Probleme gibts im Grunde wenn dynamische Inhalte verarbeitet werden (ASP.Net) dann wird's lahm, was darauf schließen lässt, dass es möglicherweise im Code zu begründen ist.
Nun werden laufend Tests gemacht, speicherdumps zum Hersteller des CMS geschickt um das Problem in den Griff zu bekommen und weitere schwachsinnige Maßnahmen, wie das zusammenführen von statischen Inhalten wie CSS und JS in eine globale Datei.
Ist nicht schwachsinnig, aber es ist Optimierung an einer Stelle, die vermutlich keine entscheidende Auswirkung hat.
Stimmt! ;) Genau das meinte ich auch, habe es aber im Wahn falsch formuliert.
Auf der anderen Seite: Kümmert es dich? Wie tief hängst du da mit drin, wenn es nicht läuft? Es klingt zwar Scheiße, aber je nach Schwere der Verantlichmachung ist "Cover your ass" jetzt vermutlich eine gute Idee, wenngleich es ziemlich negative Auswirkungen aufs Unternehmen hat, wenn die IT ständig im Cover-your-ass-Modus operiert. Das verhindert nämlich sehr effektiv Innovationen, weil niemand mehr bereit ist, ein Risiko einzugehen.
Es ist eher umgekehrt. Bin noch in der Probezeit und denke ich sollte grade in der entscheidenden Situation zeigen, was ich drauf hab und dass ich mein Geld wert bin.
Hattest du nicht früher schon mal etwas haarsträubende Geschichten gepostet? Falls ja: Hast du über das Suchen einer neuen Stelle schon nachgedacht? Im Moment werden erfahrene Entwickler wie die Nadel im Hauhaufen von allen Plattformen, Headhuntern und IT-Abteilungen gesucht und nicht gefunden.
Ja, schon öfter mal! ;) Liegt vielleicht daran, dass ich noch nie an eine Agentur geraten bin, die derart stümperhafte Arbeit abliefert. Und inzwischen bin ich 15Jahre in der IT unterwegs und habe schon das ein oder andere gesehen.
- Sven Rautenberg
Gruß Markus
-
Mal noch ne ganz allgemeine Frage zu dem Thema, auch wenn wie schon von Sven Rautenberg erwähnt das Abrufen von Seiten aus dem Cache mittels Apache Benchmark keine sinnige Aktion zur Bewältigung des Problems ist.
Ich habe mal mittels ab eine Minianwendung von mir getestet, deren Ergebnis nicht gecachet wird, wo eine relativ komplizierte SQL-Anweisung pro Aufruf ausgeführt wird. Da muss ich schon auf 100 concurent requests rauf, bis ich Reaktionszeiten von > 1000ms erreichen will.
Insgesamt sieht das Ergebnis so aus:
Concurrency Level: 100
Time taken for tests: 9.096 seconds
Complete requests: 1000
Failed requests: 4
(Connect: 0, Receive: 0, Length: 4, Exceptions: 0)
Write errors: 0
Non-2xx responses: 4
Total transferred: 11006235 bytes
HTML transferred: 10879508 bytes
Requests per second: 109.94 [#/sec] (mean)
Time per request: 909.613 [ms] (mean)
Time per request: 9.096 [ms] (mean, across all concurrent requests)
Transfer rate: 1181.63 [Kbytes/sec] receivedConnection Times (ms)
min mean[+/-sd] median max
Connect: 18 21 44.6 19 1018
Processing: 384 870 131.4 888 1447
Waiting: 364 850 131.1 867 1427
Total: 403 891 140.1 907 2044Percentage of the requests served within a certain time (ms)
50% 907
66% 940
75% 961
80% 977
90% 1026
95% 1071
98% 1136
99% 1176
100% 2044 (longest request)Eine ähnliche Abfrage auf eine dynamisch generierte Seite des im Ausgangsposting besagten Projekts bringt den Webserver zum Absturz und die Request-Zeiten werden mit "timed out" beantwortet.
Ab concurency level 5 wird's schon langsam. Das kann doch nicht normal sein, oder?Viele Grüße
Markus**
-