Einschätzung Webserver für MySQL und Bildhosting

[Mosher]

Hallo, ich bräuchte mal eine kleine Einschätzung von euch:

Ich habe eine Applikation, in der pro Benutzer ca. 50-100 Bilder angezeigt werden sollen. "Bilder" will ich jetzt erst mal stehen lassen und noch nicht weiter bezüglich Größe, Auflösung etc. konkretisieren. Gehen wir einfach mal von irgendwas durchschnittlichem aus.


Diese Applikation greift im Prinzip auf eine MySQL-Datenbank zu, ferner eine Tabelle mit lediglich 3 Spalten:
ID (Primärschlüssel) (int)
URL zum Bild (VARCHAR)
TimeStamp (Unixzeit)

der Einfachkeit halber wird immer die komplette Tabelle abgefragt, später wird vermutlich nach TimeStamp gefiltert und nur neuere Einträge berücksichtigt.

In der Applikation werden dann aus allen verfügbaren IDs 50-100 ausgewürfelt, und die entsprechenden Bilder über die URLs geladen. Die Bilder selbst werden sich auf dem gleichen Webserver befinden.


Ich gehe jetzt mal von ca. 20.000-30.000 Tabelleneinträgen + Bildern aus und max. 100-150 Benutzer, die "gleichzeitig" darauf zugreifen wollen.

D.h. bei 1MB pro Bild käme ich auf 30GB, die Tabelle sind, was weiß ich, 200Bytes pro Eintrag, also eher zu vernachlässigen, oder?

--> Speicherplatz ist nicht das Problem, 50GB kosten nichts
--> Traffic mittlerweile meist inklusive

Wie siehts mit der Transferrate aus? Sagen wir, ich habe GBit/s-Anbindung, dann würden bei 100 Usern pro User 10MBit/s übrigbleiben. Wäre schon eng, wenn jeder 100 Bilder laden soll, man müsste dann auf jeden Fall irgendwie dynamischer vorgehen und vielleicht weniger Bilder vorladen.

Muss ich sonst noch auf was achten? Mords Rechenleistung wird so ein Webserver wohl nicht brauchen, oder? So ein stinknormaler Webserver von gängigen Anbietern sollte doch eigentlich völlig ausreichen?

Oder soll ich lieber gleich auf was größeres gehen, bevor ich den ganzen Kram irgendwann auf eine größere Heimat umziehen muss?

Habe ich noch irgendwelche groben Denkfehler in meiner Abschätzung?

Danke,
Grüße,
Mosher

Edit: Ach so, als Ergänzung:
Da die ID zu jedem Bild eindeutig ist, bietet es sich ja an, in der Applikation zu hinterlegen, welche Bilder bereits geladen wurden. D.h. jedes Bild wird nur ein mal geladen und befindet sich dann auf dem lokalen Speicherplatz, auf dem auch die Applikation läuft. D.h. eben, im Schnitt entzerrt sich der Traffic etwas, aber ich möchte trotzdem möglichst wenige Flaschenhälse haben

[registrierter Gast]

Es gibt ISS, welche ihre Infrastruktur je nach Anwendung aufgliedern.
z.B. fast computing, high RAM usage, fast traffic, much traffic.

Was für dich passt, wäre dann fast traffic (xx gbit/s). Dafür braucht der Rest dann nur unterste Schublade sein und kostet entsprechend wenig.

[RattuS]

Du überschätzt die Anforderungen. Solche kleinen Zahlen sind überhaupt nicht der Rede wert. In deiner Lage ist selbst vertikales Skalieren noch kostengünstig, falls es doch mehr werden sollte als erwartet.

[sei laut]

Die 100 Benutzer sind ein fixer Kalkulationsfehler. 100*3600 ergibt 360.000 Besucher pro Stunde.

[Mosher]

Den Einwand verstehe ich nicht so ganz. Die Nutzerbasis wird gar nicht so groß sein, dass in einer Stunde 360.000 neue Logins+Transfers stattfinden können.

Ich ging bei meiner Kalkulation davon aus, dass von einer ~4-stelligen Anzahl Nutzern zu einem beliebigen Zeitpunkt höchstens 100 angemeldet sind und gerade Daten ziehen.

Wenn sich natürlich alle gleichzeitig anmelden, wird es zu gehörigen Engpässen kommen, aber ich wüsste jetzt nicht, wie ich dem entgegenwirken könnte, außer durch extrem schnelle Anbindung, die dann 2 Minuten täglich benötigt wird.

Gibt es auch solche Modelle?

[Ben Carter]

AWS kann das möglicherweise: https://aws.amazon.com

Aber ich denke auch nicht, dass hier irgendetwas Besonderes nötig ist.

lg Ben

[sei laut]

[QUOTE=Mosher;10757655]Den Einwand verstehe ich nicht so ganz. /QUOTE]

Dann darfst du aber auch nicht deinen Traffic so blöd berechen mit 100/1000Mbit/s und dann sagen: Da hat ja jeder nur noch 10Mbit/s zur Verfügung.

Ein Zugriff dauert 10s.
1Gbit/s * 10 = 1,25 Gigabyte Übertragemenge.
Also 1250 Megabye

100 Bilder a 100 Nutzer a 1MB/Bild = 10.000 Megabyte

Aber - um dich zu beruhigen . das sind theoretische Werte. Bei deiner Nutzerbasis wird das selten bis vermutlich nie vorkommen.
Dazu müsste man aber wissen, welche Nutzer das sind, wie aktiv diese sind etc.

Oder anders formuliert: Schwer vom theoretisch Standpunkt auf den praktischen zu schließen ;)
(das wollte ich sagen)

[Mosher]

Ja, wir meinten schon das gleiche, ich habe mich zu einfach ausgedrückt.

Natürlich verwischen sich die Zugriffe umso mehr, je größer die Datenmenge ist, aber ich wollte jetzt keine zu komplizierten Berechnungen anstellen.

Ich denke auch, dass ich mit 1000MBit/s hinkommen werde, aber das wird sich zeigen.

[Lokadamus]

Da sind ein paar Sachen krumm.

1.) Thumbs, grundsätzlich bekommt man eine kleine Vorschau angeboten anstatt das Bild in voller Größe.
2.) Es werden nur eine bestimmte Anzahl an Bilder geladen und beim Herunterscrollen wird nachgeladen (Facebook und Pinterest machen es zum Beispiel so) oder es werden pro Seite 10 - 30 Bilder geladen, was einstellbar sein sollte.
3.) Welcher Webserver soll zum Einsatz kommen? Diesen noch richtig konfigurieren.
Ansonsten gibt es noch HTTP Proxy wie Varnish (https://www.varnish-cache.org/), welche die Last noch einmal abfedern sollten.

[Mosher]

Aktuell teste ich die Sache (Also Datenbank, php, MySQl) auf meinem privaten 0815-Webserver, allerdings noch mit weit weniger Datensätzen. Thumbs sind eher ungeeignet, Nachladen wäre ein Option, aber es muss dann eben flüssig sein.

Ich kenne mich leider mit dem Thema nicht so aus. Die Implementierung auf der Applikationsseite und die Serverkonfig bekomme ich zwar hin, aber die Performance kann ich nicht abschätzen.

Ab wann wird zB die schiere Anzahl der Anfragen zum Problem, wenn zwar weniger Daten pro Zugriff übertragen werden, aber eben im selben Verhältnis häufigere Anfragen stattfinden?
Meinem Verständnis nach müsste es irgendwo einen "sweet spot" geben, aber - ich wiederhole mich - ich betrete hier gerade ziemliches Neuland.

[Lokadamus]

Ab wann wird zB die schiere Anzahl der Anfragen zum Problem, wenn zwar weniger Daten pro Zugriff übertragen werden, aber eben im selben Verhältnis häufigere Anfragen stattfinden?
Meinem Verständnis nach müsste es irgendwo einen "sweet spot" geben, aber - ich wiederhole mich - ich betrete hier gerade ziemliches Neuland.Wie gesagt, die Frage ist, welchen Webserver benutzt du?
IIS, Apache, lighttpd, nginx oder noch was anderes? Je nachdem können dir andere Tipps helfen.

Hinzu kommt die Frage, welche Hardware hast du zu hause und soll nachher eingesetzt werden. Welche Sprache wird eingesetzt usw. und selbst dann kann man nur anfangen, rudimentär Tipps zu geben.

[Mosher]

Wie gesagt, die Frage ist, welchen Webserver benutzt du?
IIS, Apache, lighttpd, nginx oder noch was anderes? Je nachdem können dir andere Tipps helfen.

Hinzu kommt die Frage, welche Hardware hast du zu hause und soll nachher eingesetzt werden. Welche Sprache wird eingesetzt usw. und selbst dann kann man nur anfangen, rudimentär Tipps zu geben.


Der Webserver ist Apache (Version weiß ich leider nicht.. /, aber ich wollte nächste eh mal nach einer neuen Config Ausschau halten, dann bekomme ich sicher auch die nötigen Infos)

Hardware des Webservers: nicht weiter spezifiziert. Ist ein 2,99€-Ding von Celeros, aber das ist aktuell ja eh nur meine Testumgebung.


Ich weiß, das sind sehr dürftige Infos.
Mir ging es jetzt eher um die grobe Information
"OMG, du brauchst eine 12-Core Workstation mit 20GBit/s Backbone für die Anwendung" oder
"Häng deinen Raspberry hin und gut ist"