Kapazität von normalen Servern

Bengo

Das kommt sehr auf den Programmierer an, wer weiß was er tut, kann viel mehr raushohlen, als ein Anfänger.
Und der scheinst du mir zu sein, sonst hättest du nämlich gesagt, was genau ein Request sein soll, so eine statische html geht natürlich wesentlich schneller als ein aufwendiges php script.
10.000 Anfragen pro Sekunde ist aber schon verdammt viel und lässt sich mit einem billigen V-Server maximal bei einer statischen html Seite machen und wenn man den Webserver wirklich gut konfiguriert.

SeppJ

Bengo schrieb:

10.000 Anfragen pro Sekunde ist aber schon verdammt viel und lässt sich mit einem billigen V-Server maximal bei einer statischen html Seite machen und wenn man den Webserver wirklich gut konfiguriert.

Es soll auch Leute geben, die sich die Serverlogik in einer compilierbaren Sprache programmieren, anstatt, wie von volkard beschrieben und tatsächlich millionenfach so betrieben, mittels Skriptsprachen mit 38 Virtualisierungsebenen über der Hardware. Dann kann eher die Netzanbindung ein Problem werden.

Mir ist schon klar, dass das natürlich nicht jeder mal eben so machen kann und daher macht das auch nicht jeder. Das machen eben nur Enthusiasten (wenn volkard eine Webseite betreibt, erwarte ich so etwas von ihm, und ich von mir selber auch) oder große Unternehmen, wenn sie keine Wahl haben (Google ist gewiss nicht in php mit sql-Backend programmiert ).

PS: Während ich diesen Beitrag absenden wollte, war c-plusplus.net auch prompt ohne Ende am Laggen

nman

SeppJ: Bitte gib doch nicht solche Antworten, du weißt doch selbst genau dass hier nicht die Sprache der Flaschenhals ist. Sonst glauben wieder massig Anfänger, dass Webseiten langsam sind, weil sie nicht in C++ geschrieben sind.

Volkards Antwort passt recht gut; typischerweise sind solche Seiten einfach langsam, weil sie nie darauf ausgelegt waren, schnell zu sein. Da schreibt der Cousin vom Nachbarn vom Neffen des Besitzers ein bisschen PHP und verkauft das dann und wenn ein Pageload bei einem einzelnen User vier Sekunden braucht, ist es auch kein Drama. Mehr als zehn Clients hat die Seite ohnehin nie und von denen sind acht Bots. Typischerweise wäre die Seite wahrscheinlich schon signifikant schneller, wenn die Datenbank Indizes hätte, ein paar statische Ressourcen gecached würden, nicht überall n+1 Selects abgesetzt würden, der Client nicht hundertfünfzig einzelne Files abholen müsste, der Webserver ordentlich konfiguriert wäre, der VHost nicht gnadenlos überprovisioniert wäre, und so weiter und so fort.

Kurz: Die meisten 0815-Webshops sind mit 100 Usern überfordert, weil sie einfach nie darauf ausgelegt waren.

Tun wir jetzt doch bitte nicht so, als wären 10000 Concurrent Users auf einem Webserver nichts; die meisten von euch haben sowas doch noch nie selbst gesehen. Verwendet doch mal ein bisschen Grundschulmathe. Behaupten wir, der Server hätte ein 1Gbit/s-Interface komplett für sich alleine (was er nicht hat – normalerweise muss er sich das mit einem Berg von anderen Guests teilen, möglicherweise noch mit anderen Seiten am selben Guest und das Rechenzentrum hat auch noch eine recht schmalbrüstige Anbindung und und und); wieviel bleibt dann pro User? 100kbit/s? Wie groß ist eine durchschnittliche Webseite? Vier MB? Fünf MB?

You have: 5MB/(1Gbit/s/10000)
You want: minutes
	* 6.6666667
	/ 0.15

Bitte alle aufzeigen, die normalerweise sechseinhalb Minuten auf eine Website warten, bevor sie den Tab schließen. Bitte alle aufzeigen, die glauben dass es in sechseinhalb Minuten keine Timeouts gibt.

nman

Kleiner Nachtrag: Wenn ich einen langweiligen kleinen Webshop betreibe, der normalerweise vielleicht hundert Kunden am Tag hat und irgendein Techie mir einreden will, dass ich alles so weit überprovisionieren sollte, dass ich auch 10000 gleichzeitige Kunden abfertigen kann, frage ich den auch ob er spinnt, lasse wieder den Nachbarsneffen ran und bleibe bei meinem Drei-Euro-fünfzig-Webhoster. Und wenn Twitch daherkommt, bin ich eben zwei Stunden down; auch kein Problem – die Twitcher hätten ohnehin nicht viel gekauft. Wahrscheinlich kommt Twitch aber ohnehin nicht.

nman schrieb:

Kurz: Die meisten 0815-Webshops sind mit 100 Usern überfordert, weil sie einfach nie darauf ausgelegt waren.

Tun wir jetzt doch bitte nicht so, als wären 10000 Concurrent Users auf einem Webserver nichts; die meisten von euch haben sowas doch noch nie selbst gesehen. Verwendet doch mal ein bisschen Grundschulmathe. Behaupten wir, der Server hätte ein 1Gbit/s-Interface komplett für sich alleine (was er nicht hat – normalerweise muss er sich das mit einem Berg von anderen Guests teilen, möglicherweise noch mit anderen Seiten am selben Guest und das Rechenzentrum hat auch noch eine recht schmalbrüstige Anbindung und und und); wieviel bleibt dann pro User? 100kbit/s? Wie groß ist eine durchschnittliche Webseite? Vier MB? Fünf MB?
You have: 5MB/(1Gbit/s/10000)
You want: minutes
	* 6.6666667
	/ 0.15
Bitte alle aufzeigen, die normalerweise sechseinhalb Minuten auf eine Website warten, bevor sie den Tab schließen. Bitte alle aufzeigen, die glauben dass es in sechseinhalb Minuten keine Timeouts gibt.

5MB pro Seite? Die muss aber schon voll mit Bildern sein. Ich würde mal sagen der Text macht ca. 100K - 300K aus. Dann würde man 10 bis 30 Sekunden warten, bis der Text da ist. Jetzt ist die Frage, ob Anfragen auf Bilder usw. von einem Server standardmäßig immer mit niedriger Priorität behandelt werden.

nman schrieb:

SeppJ: Bitte gib doch nicht solche Antworten, du weißt doch selbst genau dass hier nicht die Sprache der Flaschenhals ist. Sonst glauben wieder massig Anfänger, dass Webseiten langsam sind, weil sie nicht in C++ geschrieben sind.

Da wäre ich mir garnicht so sicher. Ich würde mal schätzen, dass die Kombination php + SQL es nicht schafft, unter 100ms eine 100K Seite dynamisch zusammen zu bauen. Da wären wir bei 10000 Anfragen schon bei 1000s also 16 Minuten, was mehr als deine 6 Minuten für 5MB Netzwerktraffic wären.

Übrigen hätten wir nur 1ms pro Anfrage Zeit, wenn wir 10000 Anfragen in 10 Sekunden schaffen wollen, das wäre sogar für guten C++ Code sportlich.

volkard

comboboxer schrieb:

Übrigen hätten wir nur 1ms pro Anfrage Zeit, wenn wir 10000 Anfragen in 10 Sekunden schaffen wollen, das wäre sogar für guten C++ Code sportlich.

C++ kommt noch ein wenig weiter als die SQL-Datenbank.

nman

fünf? schrieb:

5MB pro Seite? Die muss aber schon voll mit Bildern sein.

Ja, so wie das zB. bei jedem Webshop der Fall ist. Habe gerade einen Webshop gecheckt, bei dem ich vorgestern etwas bestellt habe. Die Startseite wiegt 3.5MB. Die Startseite von amazon.de wiegt 11.5MB. 5MB sind schon ein brauchbarer Wert für einen Webshop.

Ich würde mal sagen der Text macht ca. 100K - 300K aus.

Ich behaupte, dass sich die wenigsten nicht extra auf Größe optimierten modernen Seiten mit 300K Datentransfer rendern lassen.

comboboxer: Wir sprechen von Flaschenhälsen. Wenn der Traffic ohnehin nicht über das Netzwerkinterface hinauskäme, ist das der Flaschenhals – unabhängig davon was dahinter noch passieren könnte. Ich habe häufig mit Seiten mit viel Traffic zu tun und die erste Frage ist _nie_ "In welcher Sprache ist das Backend geschrieben?".

Ich sage nicht, dass die Sprache vollkommen uninteressant ist, aber such doch mal nach "C10K problem". 10000 Clients erschlägst du nicht einfach durch "nehmen wir eben C++ statt PHP", das ist ein hartes Problem. Gleichzeitig wird es bei jedem 0815-Webshop Berge von nicht ausgereiztem Optimierungspotential geben, die auch nichts mit der Programmiersprache zu tun haben.

Versteht mich nicht falsch; ich halte PHP für eine _furchtbare_ Sprache. Aber sie ist nicht der Grund, aus dem "durchschnittliche Server Anfragen von ca. 10000 Usern nicht gleichzeitig verarbeiten" können.

edit: Falsche Tags.

nman schrieb:

comboboxer: Wir sprechen von Flaschenhälsen. Wenn der Traffic ohnehin nicht über das Netzwerkinterface hinauskäme, ist das der Flaschenhals – unabhängig davon was dahinter noch passieren könnte. Ich habe häufig mit Seiten mit viel Traffic zu tun und die erste Frage ist _nie_ "In welcher Sprache ist das Backend geschrieben?".

Ich sage nicht, dass die Sprache vollkommen uninteressant ist, aber such doch mal nach "C10K problem". 10000 Clients erschlägst du nicht einfach durch "nehmen wir eben C++ statt PHP", das ist ein hartes Problem.

Ja und ich sage, dass Rechenzeit und DB Zugriffe der engere Flaschenhals sind. Und ich habe auch gesagt, dass es mit C++ schwierig wäre. Da müsste man wahrscheinlich die standard DB schon ganz raus nehmen und sich sehr effiziente Datenstrukturen ausdenken oder eine wirklich gute teure DB verwenden.

pointercrash**

nman, richtig, PHP ist grausig als Sprache und hat als Interpreter sowieso einen Nachteil. HTML ist für mich der allerletzte Schwachsinn, aber als First Draw irgendwelcher cordhosentragender Ur- Nerds immer weiter ausgebaut worden.

Aber damit hört's ja nicht auf, 10'000 gleichzeitig online ist schon eine Herausforderung (offene files, threads, egal), bereits wenn die connects inaktiv sind, 10'000 requests/s ist Hammer, wenn man mal drüber nachdenkt.

Bei den meisten Leuten gegen Ende 20 setzt der -3 dB- Knick bei etwa 12 kHz ein, was das Gehör anbelangt. Aber den ganzen Kram berechnen und rüberpusten soll gehen?

Mit Kram meine ich die überblähten Seiten, 5 MB ist fast noch zu nieder gegriffen. Ich war eine Zeit lang auf ISDN angewiesen, da bricht mittlerweile fast jede Seite mit Timeout ab. Dabei könnte man die meisten auf ein paar Zeilen handgeschnitztes HTML runterbrechen, ohne viel Bedienkomfort zu verlieren.

Aber es funktioniert halt, wie woanders auch: Jeder eingelernte Depp muß mit einem Homepagebaukasten was Ansehnliches hinkriegen, was ungefähr so aussieht, wie von dicken Firmen gebaut. Und so übel das auch ist, in 90% aller Fälle sind die Ansprüche ja bedient, was interessiert es mich, daß der Laden nicht mehr geht, wenn 100 Leute gleichzeitig drinstecken und üblicherweise so etwa 50 übern Tag verteilt kommen.

Also, 10'000 requests/s ist schon sehr engagiert, da wird alles zum Flaschenhals. Nicht Nur PHP/MySQL.

nman

comboboxer schrieb:

Ja und ich sage, dass Rechenzeit und DB Zugriffe der engere Flaschenhals sind.

Ja, aber auf etwas andere Art als du vielleicht glaubst. Wenn du 10k Clients gleichzeitig bedienen möchtest, machst du das nicht mit einer CPU und hast schon sehr sehr viel gecached. DB fällt dabei ohnehin flach und größere Mengen dynamischer Inhalte auch.

Was ich sagen wollte: 10k Clients mit einem Server sind auch für vollkommen statische Files schon eher ambitioniert. Mit genug Ressourcen schaffbar, aber ambitioniert.

Da müsste man wahrscheinlich die standard DB schon ganz raus nehmen und sich sehr effiziente Datenstrukturen ausdenken oder eine wirklich gute teure DB verwenden.

Wirklich gut und teuer gibt es für den Anwendungszweck IMO nicht. Mit mehr Geld kannst du dir dafür höchstens Leute einkaufen, die dir erklären, wie man sowas stemmen könnte.

pointercrash() schrieb:

Also, 10'000 requests/s ist schon sehr engagiert, da wird alles zum Flaschenhals. Nicht Nur PHP/MySQL.

Ack.

SeppJ

nman schrieb:

SeppJ: Bitte gib doch nicht solche Antworten, du weißt doch selbst genau dass hier nicht die Sprache der Flaschenhals ist. Sonst glauben wieder massig Anfänger, dass Webseiten langsam sind, weil sie nicht in C++ geschrieben sind.

Ironischerweise wollte ich solch eine Relativierung kurz nach Abschicken meines Beitrags noch reineditieren, aber c-plusplus.net war zu der Zeit dermaßen langsam, dass ich das Vorhaben schließlich aufgab.

nman schrieb:

Mit mehr Geld kannst du dir dafür höchstens Leute einkaufen, die dir erklären, wie man sowas stemmen könnte.

Glaube ich nicht, die sagen alle auch nur mehr Server kaufen.

nman

ExperteFürExperten schrieb:

Glaube ich nicht, die sagen alle auch nur mehr Server kaufen.

Klar, mache ich auch oft. Weil es oft billiger ist als eine Lawine von Consultingstunden um die gleiche Leistung mit weniger Servern zu bekommen.

SeppJ schrieb:

Ironischerweise wollte ich solch eine Relativierung kurz nach Abschicken meines Beitrags noch reineditieren, aber c-plusplus.net war zu der Zeit dermaßen langsam, dass ich das Vorhaben schließlich aufgab.

Wir kennen beide die PhpBB-Codebase. C++ wäre da auch keine Hilfe.