Webserver, welche Hardware?

[suppengrün]

Hey CBler,
Ich bin grad mit ein paar Freunden an einem Projekt dran. Wir sind dabei eine Androidapp zu entwickeln. Diese speichert Daten in einer Datenbank online. Über Php-Skripte, die die App anspricht, wird die Datenbank dann gefüllt. Es sind meist nur Strings, Longs und Ints. Wir nehmen an ein Appbenutzer wird so ca 100 Anfragen täglich tätigen.

Da ich jedoch keine Ahnung von Webserver und der gleichen habe ist meine Frage:
Was für eine Hardware brauch man dabei so ungefähr für sagen wir 10.000, 50.000, 200.000, 500.000, 1.000.000 Benutzer?
Kann man das überhaupt abschätzen?

Ich hoffe ihr könnte mir helfen, denn mit der Suche habe ich leider nichts brauchbares gefunden.


Grüße Suppengrün

 

[NemesisFS]

Vorschlag:
Mietet euch Ressourcen zB bei Amazon EC2. Ihr könnt so Lastszenarien simulieren ohne das große Kosten entstehen.

 

[suppengrün]

Ah okay. Das sagt mir jetzt zwar nichts, aber ich werde es mir mal anschauen und den anderen vorschlagen. Danke für die schnelle Antwort

 

[DunklerRabe]

Du bist da schon deutlich im Bereich von mehreren, teilweise sogar recht großen Servern, um solche Mengen abarbeiten zu können. Es kommt ein wenig drauf an wie groß die Anfragen sind und wie viele User parallel auf dem System sind, aber wir reden hier eher von einem Webserver/Applikationsserver Cluster im Frontend und einem DB Server Cluster im Backend.

 

[Karol_]

Sind alle dieser Zugriffe rein schreibender Natur oder wie sieht der Anteil der lesenden Anfragen aus? Wie groß ist die zu erwartende Datenbankgröße, beziehungsweise die Größe der gespeicherten Daten pro Nutzer?

Wenn pro Nutzer nur ein paar wenige Datenfelder gespeichert werden und diese daraufhin nur noch ausgelesen oder aktualisiert werden müssen, sind die Speicheranforderungen ganz anders - bei 1 Mio Nutzer und 1KB Daten pro Nutzer wird die DB kaum mehr als 1GB groß - als wenn sich die vom Nutzer übertragenen Inhalte in der Datenbank akkumulieren. Besonders in letzterem Fall kannst du bei mehreren (hundert) tausend Nutzern schon innerhalb einem Jahr auf eine Datenbank in der Größe von hunderten GB's und später mehr kommen.

Im Prinzip hängen die Hardwareanforderungen sehr stark davon ab, wie groß die DB ist, ob man diese vollständig in den RAM puffern kann, wie stark die Gewichtung der Anfragen zu einer bestimmten Tageszeit ist und wie komplex der PHP-Code aussieht.

Im günstigsten Fall (Datenbank im Bereich von >1GB bis zu einigen wenigen GB, einfaches Skript mit nur einer DB-Abfrage) wäre bereits ein moderner Desktop-PC leistungsfähig genug, um geschätzt eine halbe Million Nutzer zu bedienen, ohne auch nur mit Caching zu arbeiten. Wenn es nicht so günstig aussieht, könnte tatsächlich eine Cluster-Lösung, bestehend aus mehreren Front/Backendservern, notwendig werden.

Was du aber wirklich brauchst, weißt du erst, nachdem du ein Beispielskript und eine Beispieldatenbank erstellt hast und damit dann Load Tests durchführst. Dazu spuckt Google sehr viel Lektüre aus, in die man sich einlesen kann.

 

[ice-breaker]

Gegenfrage: Ist eure Software bzw. geplante Infrastruktur überhaupt für 100mio Nfragen ausgelegt? Da kommen wir in den Bereich von mehreren Servern mit Sharding und und und

Mietet euch einfach erstmal guten (!) Webspace, das ganze mit eigenen Servern nach oben skalieren kann man immernoch, aber ihr habt dann wenigstens erstmal geringe Kosten. Vermutlich werden die Userzahlen eh in einem geringen Bereich dümpeln.

 

[suppengrün]

Also im Moment sind ca 1000 User in der DB. Die DB ist grad 130kB groß. Aber es sind viele dummy Benutzer, das heißt man kann wahrscheinlich gut 600kB pro 1000 Nutzer rechnen. Die DB Anfragen sind ca 30-70 (Schreiben - Lesen) und es sind immer nur maximal 5 SQL-Queries in einem PHP-Skript.

Gegenfrage: Ist eure Software bzw. geplante Infrastruktur überhaupt für 100mio Nfragen ausgelegt? Da kommen wir in den Bereich von mehreren Servern mit Sharding und und und

Mietet euch einfach erstmal guten (!) Webspace, das ganze mit eigenen Servern nach oben skalieren kann man immernoch, aber ihr habt dann wenigstens erstmal geringe Kosten. Vermutlich werden die Userzahlen eh in einem geringen Bereich dümpeln.

Ja, die hohen Nutzerzahlen wird man wohl eher nicht erreichen, das ist uns auch klar. Aber da unser halbes Team Bwler sind und so die Planung und Marktseite machen, wollten die das halt wissen und festhalten.

 

[ice-breaker]

Aber da unser halbes Team Bwler sind und so die Planung und Marktseite machen, wollten die das halt wissen und festhalten.

Nur, dass das es eben nicht funktioniert. Eure Software, die ihr jetzt geschrieben habt, wird in der Form sicherlich keine hunderttausenden Nutzer aushalten. Da sind dann nachher mehr Server nötig, Umbauten an der Infrastruktur, weil man auf die Probleme von geteilten Systemen stößt und und.
Eventuell kommt ihr dann sogar auf die Idee, dass es besser wäre das System nicht mehr in PHP laufen zu lassen (stateless, es muss jedesmal alles neu geladen werden) sondern schreibt einen eigenen Server, der dauerhaft läuft und z.B. die Nutzerdaten von aktiven Nutzern dauerhaft im Ram behält (In-Memory), und somit viel effizienter arbeitet und weniger Last benötigt.

Wooga hat das z.b. schon hinter sich (Games for the masses, leider gibt es das Video zur Präsentation nicht online). Die haben auch mit PHP angefangen, das funktionierte irgendwann vorne und hinten nicht mehr, da sie bei jedem neuen PHP-Request die Daten ds Nutzers aus irgendeinem Datenspeicher laden mussten. Das wurde dann durch schnellere In-Memory Datenspeicher verbessert (Redis), aber auch da stieß man wieder an Grenzen. Bis man eben irgendwann den Weg gehen und wirklich einfach alles von geraden aktiven Nutzern im Ram behielt und die Daten nur speicherte und wieder geladen hat, wenn der Nutzer aufgehört hat zu spielen bzw. wieder begonnen hat.
Gelandet sind die dann eben bei Erlang, weil man darin verteilte Systeme und massiv parallele viel leichter als mit anderen Sprachen umsetzen kann. Das ganze hätte aber auch ein Java, Python oder Node.js Server sein können, das spielt hier keine Rolle.

Ich denke es wird klar was ich sagen wollte: Eure Lösung kann nicht bis zu den Zahlen skalieren wie ihr wollt ohne dass ihr irgendwann hunderte Server braucht, früher oder später wird da ein Rewrite nötig sein. Und an der Präsentation von Wooga sieht man auch, dass bei den richtigen Entscheidungen, die Anzahl der benötigten Server dann nochmal signifikant sinkt.