nicht angemeldet
Henry
klawischnigg
Henry
Henry
Der Martin
Henry
Henry
Der Martin
Henry
MudGuard
Henry
Hallo,
nächte Woche habe ich ein Release und erwarte, aus Erfahrungswerten, eine Überlastung des Webspaces. Beim gleichen Vorgängerprojekt hatte ich zu Anfang eine Speicherung der Eingaben als Textdatei. Das lief auch überraschend gut, machte die Nachbearbeitung aber recht aufwendig und einige Optionen entfielen. Ach ja, sollt evielleicht noch erwähnen, dass es sich um eine Registierungsplattform ohne direkte weitere Kundeninteraktionen, es werden allerdings Bestätigungs-Emails versendet. Der Rest läuft im Hintergrund ohne Kundenzutun ab. Die Verarbeitung klappt also, lediglich die zu hohen Besucherzahlen/Anfragen sind das Problem. Suche also nur für diese wenigen Tage eine Lösung.
Ach ja, vielleicht auch nicht unwichtig, das Problem ist nur beim Andrang am Anfang vorhanden, passiert also nur 3-4 mal im Jahr, bei normalem Besucheraufkommen, kein Problem.
Beim letzten Mal habe ich dazu allerdings die Shopfunktion von Wordpress (Woocomerce) genutzt und die, bzw. der Vserver, war dem Ansturm nicht gewachsen. Funktionierte zwar alles, solange die Seite erreichbar war, aber oft war die Seite viele minutenlang nicht erreichbar.
Jetzt überlege ich, wie ich es anstellen kann, dem vorzubeugen.
1. Dedicated Server? Auch wenn das technisch natürlich effektiver sein müsste, so zeigen uralte Erfahrungen, dass dies auch keine Garantie darstellt. Z.B. eine schmerzhafte Erfahrung ist ca. 12 Jahre her, da blockierte der Server und der Support konnte auch nicht helfen, bis ich durch Try&Error den Fehler beim aktiven Keep-Alive lokalisieren konnte. Daher setze ich seit Jahren eher auf viele aber kleinere Möglichkeiten, wie eben Vserver. Das bringt mich zur nächten Option:
2. Spiegeln? Ich könnte das Ganze auf verschiedene Server aufteilen und (meine Theorie viell gibts bessere Lösungen dabei) die Erreichbarkeit eines Servers live prüfen und bei Prolemen den Kunden umleiten. Hätte aber zb. das Problem, dass ich im Nachhinein alle Einträge aus verschiedenen System synchronisieren muss, also sicher eine Inkonsitenz vorhanden sein wird und sicher noch andere Probleme, die ich jetzt nicht mal auf dem Schirm habe.
Alternativen? Wahrscheinlich gäbe es noch unzählige Quick&Dirty Lösungen, doch ich habe die Hoffnung, dass es vielleicht viel sauberer und dennoch simple gehen könnte.
Daher, wie würdet ihr das angehen?
Gruss
Henry
Hi there,
Daher, wie würdet ihr das angehen?
Ich würde einen Cache vorschalten...
Hallo klawischnigg,
Ich würde einen Cache vorschalten...
Könnte das wirklich helfen? Ich vermute, das Problem tritt ja erst auf wenn die Kunden ihre Daten eingeben.
Gruss
Henry
Hallo klawischnigg,
Ich würde einen Cache vorschalten...
Könnte das wirklich helfen? Ich vermute, das Problem tritt ja erst auf wenn die Kunden ihre Daten eingeben.
Zu dem Zweck müßte man mehr analysieren, wo die Probleme wirklich auftreten. Ich hab ein ähnliches Problem einmal mit einer Drupal-Applikation gehabt, da hat der Varnish-Cache Wunder vollbracht. Es war allerdings eingeräumterweise so, daß das Verkehrsaufkommen an sich das Problem war bei einer eher statischen Seite. Wenn Du jedesmal andere Requests und Outputs hast, dann nützt ein Cache natürlich weniger.
Ich hab von Wordpress wenig bis gar keine Ahnung, aber der Seitenaufbau auch einer statischen Drupal-Seite belastet den Server ziemlich, wenn auch nur kurzzeitig und da kann ein Cache schon helfen...
nächte Woche habe ich ein Release und erwarte, aus Erfahrungswerten, eine Überlastung… […] Daher, wie würdet ihr das angehen?
Hätte ich nächste Woche ein Release und Bedenken, dann würde ich schleunigst erstmal messen. Wenn Du komplexere Post-Requests im Verdacht hast, dann wirst Du Dir vielleicht was basteln müssen. Für regulären Traffic eignet sich z.B. ApacheBench.
Bis nächste Woche werden Dir nicht all zu viele Optionen bleiben. Loadbalancing / spiegeln ist komplex. Soweit Du da keine Erfahrung hast und/oder die Fallstricke des verwendeten Stack dabei nicht kennst: vergiss es.
Einen Varnish vorzuschalten, könnte bis nächste Woche noch klappen. Wenn Du aber zu 99% Post-Requests erwartest, wird das nicht helfen.
Mein Tipp lautet: messen, Flaschenhälse finden und womöglich optimieren. Überlegen, wie die Messergebnisse zum prognostizierten Aufkommen passen.
Worst case Szenario, aber dann wirds richtig Quick&Dirty: Loadbalancing mit Sticky-Sessions und auf die Spiegelung / Synchronisation pfeiffen.
Oder, wenn Du alle beweglichen Daten in einer DB hast und die nicht selbst der Flaschenhals ist: Loadbalancing für die Applikation und einer zentralen DB.
Aber nochmal: ich würde erstmal messen! Viel Glück - bis nächste Woche ist sportlich.
Hallo Mitleser,
ja danke, scheint schon sehr komplex und diesen Feinjustierungen fehlt mir Wissen und Erfahrung.
Mir ist noch eine andere Vorgehensweise in den Sinn gekommen, weiss aber nicht ob realisierbar:
Lässt sich das Besucheraufkommen steuern? Also ähnlich wie im normalen Leben im Club, oder Restaurant, usw... Lasse also zb. nur 1000 Leute drauf, die Nachfolgenden sehen so lange eine Warteseite. Technisch würde ich das mit einem Zähler umsetzen wollen, Problem ist aber ich weiss dann nicht genau wann andere die Seite verlässlich verlassen haben.
Wäre das eine Option? Sollte vielleicht erwähnen, auch wenns vielleicht komisch klingt ist aber so, dass die Kunden dafür Verständnis haben werden.
Gruss
Henry
Hallo,
Lässt sich das Besucheraufkommen steuern? Also ähnlich wie im normalen Leben im Club, oder Restaurant, usw... Lasse also zb. nur 1000 Leute drauf, die Nachfolgenden sehen so lange eine Warteseite. Technisch würde ich das mit einem Zähler umsetzen wollen, Problem ist aber ich weiss dann nicht genau wann andere die Seite verlässlich verlassen haben.
genau das ist im Web das Problem. Es gibt keine permenente Verbindung zwischen Client und Server, an der du erkennen kannst, ob ein Besucher noch "online" ist. Da müsste man dann also auf Hypothesen aufbauende Krücken benutzen. Zum Beispiel annehmen, dass ein Besucher wieder "weg" ist, wenn länger als 3 Minuten kein neuer Request von ihm kam.
Wäre das eine Option?
Wenn's technisch zuverlässig möglich wäre ...
Sollte vielleicht erwähnen, auch wenns vielleicht komisch klingt ist aber so, dass die Kunden dafür Verständnis haben werden.
Das ist in der Tat interessant und ungewöhnlich. Ich bin eigentlich gewöhnt, dass Leute sehr schnell anfangen zu knurren, wenn sie irgendwo warten müssen - sei es an der Kinokasse, im Museum, oder jetzt in Corona-Zeiten auch mal beim ALDI vor der Tür.
Live long and pros healthy,
Martin
Das ist in der Tat interessant und ungewöhnlich. Ich bin eigentlich gewöhnt, dass Leute sehr schnell anfangen zu knurren, wenn sie irgendwo warten müssen - sei es an der Kinokasse, im Museum, oder jetzt in Corona-Zeiten auch mal beim ALDI vor der Tür.
Ja ist meist so. Aber weisst du wo das nicht ist? Wenn Apple ein neues Produkt mit endlosen Warteschlangen vor den Stores verkauft, oder Leute sogar vorm Kino übernachten wenn neuer Star Wars oder Herr der Ringe rauskam, eben bei Fan-Kult, ja und sowas ähnliches ist das bei mir halt.
Gruss
Henry
Lässt sich das Besucheraufkommen steuern? Also ähnlich wie im normalen Leben im Club, oder Restaurant, usw... Lasse also zb. nur 1000 Leute drauf, die Nachfolgenden sehen so lange eine Warteseite.
Wäre das eine Option? Sollte vielleicht erwähnen, auch wenns vielleicht komisch klingt ist aber so, dass die Kunden dafür Verständnis haben werden.
Theoretisch ja. Praktisch in Deinem Fall? Eher nein. Ich habe jetzt keine Zeit, dass inhaltlich zu erklären, aber der Ansatz ist alles andere als trivial umsetzbar, bis er vernünftig funktioniert und/oder das Problem zunächst nicht sogar verschlimmert.
Sollte vielleicht erwähnen, auch wenns vielleicht komisch klingt ist aber so, dass die Kunden dafür Verständnis haben werden.
Na das klingt ja fast so, als ob Du die Kunden kennst? Dann schreib die vorab an und bitte sie um Verständnis, dass sie es beim einem Fehler später einfach nochmal probieren sollen.
Apropos: Wenn es zur Überlastung kommt, dann werden die Kunden ja irgendwann einen Server Error, Gateway Timeout oder so bekommen. Also könntest Du einfach die Fehlerseiten für die fraglichen Kandidaten(HTTP 500, 503…) dazu anpassen.
Zusätzlich noch die eingegebenen Formulardaten via JavaScript im Localstorage hinterlegen, damit die Leute Dein Formular nicht von vorne ausfüllen müssen.
Hallo Mitleser,
Na das klingt ja fast so, als ob Du die Kunden kennst? Dann schreib die vorab an und bitte sie um Verständnis, dass sie es beim einem Fehler später einfach nochmal probieren sollen.
Ja das habe ich schon und kennen die auch aus den letzten Aktionen. Aber schöner wäre trotzdem fehlerfrei.
Apropos: Wenn es zur Überlastung kommt, dann werden die Kunden ja irgendwann einen Server Error, Gateway Timeout oder so bekommen. Also könntest Du einfach die Fehlerseiten für die fraglichen Kandidaten(HTTP 500, 503…) dazu anpassen.
Das funktioniert irgendwie nicht, weil der Server die eigenen Fehlerseiten dann auch nicht mehr ausgibt, nur die Defaults vom Browser.
Zusätzlich noch die eingegebenen Formulardaten via JavaScript im Localstorage hinterlegen, damit die Leute Dein Formular nicht von vorne ausfüllen müssen.
Bei den meisten ist es zum Glück nur das Login und das kennen die ja bereits oder haben es im Browser hinterlegt.
Gruss
Henry
Ja das habe ich schon und kennen die auch aus den letzten Aktionen. Aber schöner wäre trotzdem fehlerfrei.
Fehlerfrei gibt es nicht. Was Du anstrebst sind 99,9% Mehr schaffen auch Amazon und Google nicht. Viel Spaß dabei, auf Dich wartet viel Arbeit 😉
Apropos: Wenn es zur Überlastung kommt, dann werden die Kunden ja irgendwann einen Server Error, Gateway Timeout oder so bekommen. Also könntest Du einfach die Fehlerseiten für die fraglichen Kandidaten(HTTP 500, 503…) dazu anpassen.
Das funktioniert irgendwie nicht, weil der Server die eigenen Fehlerseiten dann auch nicht mehr ausgibt, nur die Defaults vom Browser.
Dann würde ich Dir empfehlen, Dich genau darum zu kümmern. Das funktioniert defintiv, aber in Deinem Setup scheint dabei etwas schief zu gehen. Finde raus was und beheb es. Das scheint mir aktuell der für Dich sinnvollste Tipp bis nächste Woche.
Dedicated Server?**
Grundsätzlich kann man schon sagen: viel hilft oft auch viel. Wenn Du jetzt auf einem Mini VServer arbeitest, dann wird Blech mit 64 GB Ram und 16 Kernen die Wahrscheinlichkeit einer Überlastung durchaus reduzieren. Oder direkt 768 GB Ram und guck, was Du alles im Ram laufen lassen kannst 😉
Ansonsten: Wordpress hat doch eigene Cache-Plugins, meine ich. Keine Ahnung, was die taugen…
Hallo,
Ansonsten: Wordpress hat doch eigene Cache-Plugins, meine ich. Keine Ahnung, was die taugen…
aber wenn es um dynamisch je nach Benutzer generierte Inhalte geht (wir reden von einem Login, also kundenspezifischen Daten), hilft Caching nicht viel.
Das trifft dann nur die ohnehin statischen Ressourcen wie Bilder und Stylesheets. Und dass statische Ressourcen den Flaschenhals ausmachen, kann ich mir eigentlich nicht vorstellen.
Live long and pros healthy,
Martin
aber wenn es um dynamisch je nach Benutzer generierte Inhalte geht (wir reden von einem Login, also kundenspezifischen Daten), hilft Caching nicht viel.
Das trifft dann nur die ohnehin statischen Ressourcen wie Bilder und Stylesheets.
Das ist nicht ganz richtig. Ich meine, diese WP-Cache-Plugins cachen auch „Seiten“. Also zum Beispiel Startseite, Impressum… Wenn da der Roundtrip über die PHP-Interna und/oder Datenbank weg fällt, ist das ja durchaus hilfreich.
Hallo Mitleser,
Das ist nicht ganz richtig. Ich meine, diese WP-Cache-Plugins cachen auch „Seiten“. Also zum Beispiel Startseite, Impressum… Wenn da der Roundtrip über die PHP-Interna und/oder Datenbank weg fällt, ist das ja durchaus hilfreich.
Da hst du sicherlich recht, aber die Statistik zeigt da wenige Besucher, aber immerhin Kleinvieh macht…
Das Problem was ich habe, ist die Performance unter Volllast zu prüfen, bzw Volllast zu simulieren. Wenn ich das unter normalen Bedingungen teste, habe ich eben mal im Vergleich mit dem Forum hier gemacht siehe Sreenshot, siehst super aus, aber eben nicht wenn der Ansturm kommt.
Gruss
Henry
Das Problem was ich habe, ist die Performance unter Volllast zu prüfen, bzw Volllast zu simulieren.
Für alle GET-Requests: ApacheBench. Für die Posts im wirst Du Dir evtl. was bauen müssen.
Hi,
wie erfahren die Kunden von dem Release?
Evtl. kann man ja da ansetzen, und die Kunden nicht alle auf einen Schlag informieren.
cu,
Andreas a/k/a MudGuard
Hallo MudGuard,
e erfahren die Kunden von dem Release?
Evtl. kann man ja da ansetzen, und die Kunden nicht alle auf einen Schlag informieren.
wäre schön aber leider nicht machbar, alles öffentlich, Social Media, Presse, Agenturen, usw...
Gruss
Henry
