5
High Load -Traffic Website, welche Software - HW?
Hallo liebe Community,
habe aktuell das Problem das mir meine Seite (Apache 2.2, FAST CGI PHP 7.4 mit Maria DB) bei etwa 1000 gleichzeitigen Besuchern in die Knie geht. (TIME OUT seitens Browser da der Server komplett überlastet war).
Ich hatte damals bereits ein Setup mit 3 dedicated Servern (3 x LoadBalancer (HA-Proxy) und Galera Cluster, Storage direkt auf jedem Server diese untereinander repliziert wird) aufgebaut.
Am besten wäre das Setup das ich es skalieren kann wie ich es brauche.
Welche Software würdet ihr in der heutigen Zeit einsetzen? Opensource, oder bezahlte Software?
Gibt es vielleicht schon etwas fertiges?
Die Anwendung läuft mittels PHP 7.4 und Maria DB und wurde nicht auf Clustering aufgebaut. D.h. die Server-Software müsste das gesamte Balancing ausführen.
Welche Hardware wäre hier am besten? Viele Prozessorkerne und mehr RAM pro Server (inkl. NVME SSD), oder eher weniger Kerne mit mehr Leistung?
Könnt ihr mir helfen? Vielen Dank
Lg Iceget
habe aktuell das Problem das mir meine Seite (Apache 2.2, FAST CGI PHP 7.4 mit Maria DB) bei etwa 1000 gleichzeitigen Besuchern in die Knie geht. (TIME OUT seitens Browser da der Server komplett überlastet war).
Ich hatte damals bereits ein Setup mit 3 dedicated Servern (3 x LoadBalancer (HA-Proxy) und Galera Cluster, Storage direkt auf jedem Server diese untereinander repliziert wird) aufgebaut.
Am besten wäre das Setup das ich es skalieren kann wie ich es brauche.
Welche Software würdet ihr in der heutigen Zeit einsetzen? Opensource, oder bezahlte Software?
Gibt es vielleicht schon etwas fertiges?
Die Anwendung läuft mittels PHP 7.4 und Maria DB und wurde nicht auf Clustering aufgebaut. D.h. die Server-Software müsste das gesamte Balancing ausführen.
Welche Hardware wäre hier am besten? Viele Prozessorkerne und mehr RAM pro Server (inkl. NVME SSD), oder eher weniger Kerne mit mehr Leistung?
Könnt ihr mir helfen? Vielen Dank
Lg Iceget
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 625060
Url: https://administrator.de/contentid/625060
Printed on: April 16, 2024 at 15:04 o'clock
5 Comments
Latest comment
Hallo,
zu Deiner Frage:
wir haben entweder HAProxy verwendet oder den LB des Anbieters (z.B. AWS).
Zur Deiner Frage fehlen sehr viele Angaben.
Vor allem über die Art der Software.
Ein Magento-Server braucht z.B. 8 CPUs für ca. 50 gleichzeitige Anfragen.
Und PHP skaliert ab einem bestimmten Wert, der von der Anwendung und dem Server abhängt, immer schlechter.
4 Server mit 32 Kernen sind schneller als 1 Server mit 128 Kernen.
Man kann sehr viel Geld (für das Hosting) mit FPCs sparen.
Ganze Seiten oder Seitenteile die nicht berechnet werden müssen sparen Geld und liefern schnell Seiten aus.
Auch mit einem CDN kann man Traffic am Server einsparen.
Oder primär statische Seiten ausliefern und den Inhalt mit AJAX "nachliefern".
Du schreibst von Besuchern. Das klingt nach FPC.
Weniger die Anzahl der Besuchern als die Anzahl gleichzeitiger Anfragen ist relevant.
Es gibt viele Möglichkeiten Lasttests auszuführen.
Auch zum Thema Geld sparen kann man nachts mehrere Server ausschalten.
Stefan
zu Deiner Frage:
wir haben entweder HAProxy verwendet oder den LB des Anbieters (z.B. AWS).
Zur Deiner Frage fehlen sehr viele Angaben.
Vor allem über die Art der Software.
Ein Magento-Server braucht z.B. 8 CPUs für ca. 50 gleichzeitige Anfragen.
Und PHP skaliert ab einem bestimmten Wert, der von der Anwendung und dem Server abhängt, immer schlechter.
4 Server mit 32 Kernen sind schneller als 1 Server mit 128 Kernen.
Man kann sehr viel Geld (für das Hosting) mit FPCs sparen.
Ganze Seiten oder Seitenteile die nicht berechnet werden müssen sparen Geld und liefern schnell Seiten aus.
Auch mit einem CDN kann man Traffic am Server einsparen.
Oder primär statische Seiten ausliefern und den Inhalt mit AJAX "nachliefern".
Du schreibst von Besuchern. Das klingt nach FPC.
Weniger die Anzahl der Besuchern als die Anzahl gleichzeitiger Anfragen ist relevant.
Es gibt viele Möglichkeiten Lasttests auszuführen.
Auch zum Thema Geld sparen kann man nachts mehrere Server ausschalten.
Stefan
Sind die meisten Anfragen Cache-Fähig?
Dann ließe sich mit einem Reverse-Proxy, der als Cache vorgeschaltet wird, ein Teil der Last vom Backend zurückhalten.
Voraussetzung dafür ist, dass es Inhalte sind, die für viele bzw. alle Seitenbesucher identisch sind und keine persönlichen Einstellungen aus Cookies oder Sessions notwendig sind.
Falls ein Login erfolgt, aber dennoch die Inhalte weitesgehend für alle identisch sind, kann man darüber nachdenken, den individuellen Teil der Daten per Ajax nachzuladen und die Seiten ansonsten komplett aus einem Proxy-Cache auszuliefern.
Dann ließe sich mit einem Reverse-Proxy, der als Cache vorgeschaltet wird, ein Teil der Last vom Backend zurückhalten.
Voraussetzung dafür ist, dass es Inhalte sind, die für viele bzw. alle Seitenbesucher identisch sind und keine persönlichen Einstellungen aus Cookies oder Sessions notwendig sind.
Falls ein Login erfolgt, aber dennoch die Inhalte weitesgehend für alle identisch sind, kann man darüber nachdenken, den individuellen Teil der Daten per Ajax nachzuladen und die Seiten ansonsten komplett aus einem Proxy-Cache auszuliefern.
Moin,
das erste ist mal wieder das einfach zu wenig Infos drinne sind.
Du musst ja erst mal schauen WO geht denn deine Leistung überhaupt verloren? Ist das überhaupt im Webserver? Nehmen wir an du hast ne Datenbank mit 10 Mio. Einträgen und das wäre deine Artikelnummer:
XYZ000000001
XYZ000000002
XYZ000000003
Führst du jetzt Anfragen z.B. mit nem "LIKE" aus dann wirst du merken das es einen Moment dauert. Bei 1000 gleichzeitigen Anfragen eben auch einige Momente mehr. Gehst du jetzt bei und machst deine Artikelnummern lediglich als Zahl und deine Abfrage enthält somit nur noch "where artNr = 000000002" hast du die Abfrage bereits erheblich schneller gemacht (grad unter Last). Du siehst aber - du kannst hier in dem Webserver reingesteckt haben was du willst -> da ist gar nicht das Problem...
Ein anderer Fall wäre das du in deinem PHP-Code Unsinn hast und du bei der o.g. Artikel-DB z.B. sowas machst:
for (i = 0; i < 10000000; i++) {
mysql_open....
select xyz from artdb where art-nr = $i
mysql_close
}
Das wäre jetzt mal wirklich ganz platt -> aber du würdest merken das du dir grad die DB zerlegst weil die Verbindungen ständig geöffnet und geschlossen werden. Auch da würdest du ganz schnell dahin kommen das deine Seite nicht mehr funktioniert wie du willst... Und das auch wieder völlig unabhängig davon welche Hardware du einsetzt.
Von daher: Bevor du da jetzt wild mit Hardware versuchst was zu lösen würde ich zu erst mal gucken WO überhaupt das Problem ist. DA kann man dann ansetzen - sei es durch Code-Verbesserung, sei es durch RAM, irgendwelche Software-Caches oder eben auch durch mehr / schnellere Server. Alles andere wird dir zwar ggf. kurzfristig helfen aber in 4 Wochen oder 4 Monaten stehst du wieder vor genau demselben Problem... Weils dann eben ggf. 1500 Leute sind.
das erste ist mal wieder das einfach zu wenig Infos drinne sind.
Du musst ja erst mal schauen WO geht denn deine Leistung überhaupt verloren? Ist das überhaupt im Webserver? Nehmen wir an du hast ne Datenbank mit 10 Mio. Einträgen und das wäre deine Artikelnummer:
XYZ000000001
XYZ000000002
XYZ000000003
Führst du jetzt Anfragen z.B. mit nem "LIKE" aus dann wirst du merken das es einen Moment dauert. Bei 1000 gleichzeitigen Anfragen eben auch einige Momente mehr. Gehst du jetzt bei und machst deine Artikelnummern lediglich als Zahl und deine Abfrage enthält somit nur noch "where artNr = 000000002" hast du die Abfrage bereits erheblich schneller gemacht (grad unter Last). Du siehst aber - du kannst hier in dem Webserver reingesteckt haben was du willst -> da ist gar nicht das Problem...
Ein anderer Fall wäre das du in deinem PHP-Code Unsinn hast und du bei der o.g. Artikel-DB z.B. sowas machst:
for (i = 0; i < 10000000; i++) {
mysql_open....
select xyz from artdb where art-nr = $i
mysql_close
}
Das wäre jetzt mal wirklich ganz platt -> aber du würdest merken das du dir grad die DB zerlegst weil die Verbindungen ständig geöffnet und geschlossen werden. Auch da würdest du ganz schnell dahin kommen das deine Seite nicht mehr funktioniert wie du willst... Und das auch wieder völlig unabhängig davon welche Hardware du einsetzt.
Von daher: Bevor du da jetzt wild mit Hardware versuchst was zu lösen würde ich zu erst mal gucken WO überhaupt das Problem ist. DA kann man dann ansetzen - sei es durch Code-Verbesserung, sei es durch RAM, irgendwelche Software-Caches oder eben auch durch mehr / schnellere Server. Alles andere wird dir zwar ggf. kurzfristig helfen aber in 4 Wochen oder 4 Monaten stehst du wieder vor genau demselben Problem... Weils dann eben ggf. 1500 Leute sind.
Es gibt natürlich Webseiten, die auch etwas CPU Last erzeugen, während sie die Antwort errechnen, z.B. wenn eine Grafik errechnet wird. Dann gibt es Webseiten, die einfach viel RAM oder Plattenaktivität benötigen, weil große Datenmengen durchsucht werden. Somit ist die Frage nach CPU, RAM und HDD nicht wirklich beantwortbar. Jede Webseite bringt etwas Anderes in die Knie.
Du hast jedoch bereits ein laufendes System, das in die Knie geht. An diesem lässt sich der Flaschenhals und auch die noch unbenutzten Recourcen einsehen - exakt basierend zum Anspruch Deiner eingesetzten Webseite.
Es macht also keinen Sinn eine schnellere CPU einzuplanen, wenn in deinem alten System die CPU noch nicht voll belastet war. Mehr Kerne zu verwenden macht dann sinn, wenn im alten System alle Kerne vom PHP in Anspruch genommen wurden. Mehr RAM macht Sinn, wenn im alten System der RAM über 75% belegt war. Auch die Plattenbelastung lässt sich so gut erkennen.
Und, wie oben bereits erwähnt, die Art der Datenbankabfrage sowie einsatz von smarty bzw einem template-cache.
Du hast jedoch bereits ein laufendes System, das in die Knie geht. An diesem lässt sich der Flaschenhals und auch die noch unbenutzten Recourcen einsehen - exakt basierend zum Anspruch Deiner eingesetzten Webseite.
Es macht also keinen Sinn eine schnellere CPU einzuplanen, wenn in deinem alten System die CPU noch nicht voll belastet war. Mehr Kerne zu verwenden macht dann sinn, wenn im alten System alle Kerne vom PHP in Anspruch genommen wurden. Mehr RAM macht Sinn, wenn im alten System der RAM über 75% belegt war. Auch die Plattenbelastung lässt sich so gut erkennen.
Und, wie oben bereits erwähnt, die Art der Datenbankabfrage sowie einsatz von smarty bzw einem template-cache.
Moin Ice,
hier kommt nicht zur Sprache, was darauf läuft, daher kann man zum dahinter keine Aussagen treffen. 1000 User klingt auf den ersten Blick nun auch nicht nach so viel, kommt aber eben drauf an, wie die damit arbeiten, wie es programmiert ist und wie der dauerhafte Load ausschaut.
Aber das ist alles nichts mehr für'nen kurzen Tipp übers Forum, sondern harte Analyse am System, wenn bzw am besten bevor es in die Knie geht. Die danach folgende Frage ist, wie baust du es auf, damit es nicht zu Datenproblemen kommt etc.
Soweit so gut, bei Fragen, klopf gerne an.
Grüße,
Christian
certifiedit.net
hier kommt nicht zur Sprache, was darauf läuft, daher kann man zum dahinter keine Aussagen treffen. 1000 User klingt auf den ersten Blick nun auch nicht nach so viel, kommt aber eben drauf an, wie die damit arbeiten, wie es programmiert ist und wie der dauerhafte Load ausschaut.
Aber das ist alles nichts mehr für'nen kurzen Tipp übers Forum, sondern harte Analyse am System, wenn bzw am besten bevor es in die Knie geht. Die danach folgende Frage ist, wie baust du es auf, damit es nicht zu Datenproblemen kommt etc.
Soweit so gut, bei Fragen, klopf gerne an.
Grüße,
Christian
certifiedit.net