Hallo,
ich denke gerade über verschiedene Server-Architekturen nach. Ein geratener Faktor dabei ist immer, wo typischerweise bei Web-Anwendungen das bottleneck ist. Ich tippe mal auf das Netzwerk, gefolgt von der Datenbank. Später erst die CPU, ansonsten wären interpretierte Sachen wie PHP oder RoR nicht so populär.
mfg Todi
Bottleneck
gepostet vor 17 Jahre, 12 Monate von Todi42
gepostet vor 17 Jahre, 12 Monate von mifritscher
Die meisten Probleme kommen wegen Murks in der Programmierung
HW-mäßig sind meist die CPU und der Speicher die Schwachstellen
Wenn deine Server mit 100 mbit oder gar 1gbit verbunden sind sollte das kein Flaschenhals mehr darstellen.
HW-mäßig sind meist die CPU und der Speicher die Schwachstellen
Wenn deine Server mit 100 mbit oder gar 1gbit verbunden sind sollte das kein Flaschenhals mehr darstellen.
gepostet vor 17 Jahre, 12 Monate von Sarge
Im normalfall speicher dann cpu bei dynamischen sachen würd ich nun mal behaupten... netzwerkkarte kriegst du normalerweise nur ausgelastet wenn du rein statische dateien servierst..
die datenbank kann man ja nun nicht so pauschal sagen, ist ja wieder von cpu+speicher etc abhängig
die datenbank kann man ja nun nicht so pauschal sagen, ist ja wieder von cpu+speicher etc abhängig
gepostet vor 17 Jahre, 12 Monate von Teonas
Ein Paper, das ich mal zum Vergleich von PHP und Java gelesen habe, untersucht zwei Szenarien mit dynamischem Content: Einen Online-Shop und ein Auktionshaus.
Im Shop sind CPU und DB-Locks (wegen vieler komplexer Transaktionen) das Bottleneck, beim Auktionshaus CPU, wegen starkem Lesezugriff und kurzen Transaktionen. PHP wird als vorteilhaft in diesem Kontext gesehen, weil es als Apache-Modul läuft und damit wenig Interprozess-Kommunikation und der verbundene Overhead produziert wird.
Im Shop sind CPU und DB-Locks (wegen vieler komplexer Transaktionen) das Bottleneck, beim Auktionshaus CPU, wegen starkem Lesezugriff und kurzen Transaktionen. PHP wird als vorteilhaft in diesem Kontext gesehen, weil es als Apache-Modul läuft und damit wenig Interprozess-Kommunikation und der verbundene Overhead produziert wird.
gepostet vor 17 Jahre, 12 Monate von Todi42
Danke für eure Einschätzungen. Sieht wohl so aus, wie ich es mit vorgestellt, habe: "Man kann es wohl nicht so genau sagen". Ich gehe dann bei meinen Architekturentscheidungen wohl mal davon aus, das ich mehr praxis brauche und bis dahin eher mit prototypen arbeiten sollte.
gepostet vor 17 Jahre, 12 Monate von Lunikon
Es hängt auch stark von der Natur der Anwendung ab. Bei uns ist und war der Bottleneck immer die Datenbank, weil wir sehr viele, teils aufwändige Queries an die Datenbank schicken mussten. PHP war nur an wenigen Stellen wirklich kritisch. Hängt aber wie gesagt meines Erachtens stark vom Spiel ab.
gepostet vor 17 Jahre, 11 Monate von schokofreak
DAs heisst flaschenhalst. Obwohl ich englisch sehr gern hab, hasse ich anglizismen. Entweder alles englisch, oder alles deutsch.
Meiner Meinung nach kann es so gut wie gar nicht der Prozessor sein. Ausser man macht etwas spezielles. Höchstens RAM; ist aber sehr einfach ausbar. Höchst warscheinlcih wird das system schlichtwegs an die Leistungsgrenzen stossen, obwohl eigentlich keine Ressource absolut ausgelastet ist. Von dem her kann man ab einer gewissen Auslastung fast nichts mehr tun...
Gruss
Meiner Meinung nach kann es so gut wie gar nicht der Prozessor sein. Ausser man macht etwas spezielles. Höchstens RAM; ist aber sehr einfach ausbar. Höchst warscheinlcih wird das system schlichtwegs an die Leistungsgrenzen stossen, obwohl eigentlich keine Ressource absolut ausgelastet ist. Von dem her kann man ab einer gewissen Auslastung fast nichts mehr tun...
Gruss
gepostet vor 17 Jahre, 11 Monate von Teonas
Original von schokofreak
Höchst warscheinlcih wird das system schlichtwegs an die Leistungsgrenzen stossen, obwohl eigentlich keine Ressource absolut ausgelastet ist. Von dem her kann man ab einer gewissen Auslastung fast nichts mehr tun...
Was ist denn das für eine Aussage (oder vielmehr der Mangel daran)...? Irgendwann gehts nicht mehr, obwohl nix (1. Satz) und alles (2. Satz) ausgelastet ist. 0% analytischer Wert...
gepostet vor 17 Jahre, 11 Monate von Todi42
Original von schokofreak
DAs heisst flaschenhalst. Obwohl ich englisch sehr gern hab, hasse ich anglizismen. Entweder alles englisch, oder alles deutsch.
Na siehste und ich hasse es englische Fachbegriffe ins deutsche zu übersetzen, da muß man die Übersetzung dann meist wieder ins englische zurück übersetzen, um zu wissen, das mit Flaschenhals ein Engpass gemeint ist ;-) Ansonsten wirst Du bei mir wenig englisch finden, da wird nix gedowngeloaded, sondern heruntergeladen! So war ich das hier gewrotet hab ;-)
gepostet vor 17 Jahre, 11 Monate von Agmemon
Der klassische Flaschenhals (in der von-Neumann-Architektur) war eigentlich die CPU. Der Speicher konnte schneller Daten liefern, als die CPU verarbeiten konnte. Durch die Entwicklung, die mittlerweile vonstatten ging, hat sich das verschoben und der klassische Flaschenhals ist der Speicher. Zumindest was die Hardware Architektur betrifft.
Bei einer Software Architektur kann man das nicht so einfach bestimmen, da es von der Architektur und der Umsetzung abhängt. Bei einer Webbasierten Anwendung ist aber die Datenbank immer ein guter Kandidat, den man im Auge behalten sollte.
Viel interessanter dabei ist, wie man mit einem Flaschenhals umgehen soll. Stellt sich zum beispiel die Datenbank als Flaschenhals heraus, kann man erstmal gucken, ob einen der Einsatz von memcached weiter bringt, bevor man sich einen zweiten Server hinstellt.
Bei einer Software Architektur kann man das nicht so einfach bestimmen, da es von der Architektur und der Umsetzung abhängt. Bei einer Webbasierten Anwendung ist aber die Datenbank immer ein guter Kandidat, den man im Auge behalten sollte.
Viel interessanter dabei ist, wie man mit einem Flaschenhals umgehen soll. Stellt sich zum beispiel die Datenbank als Flaschenhals heraus, kann man erstmal gucken, ob einen der Einsatz von memcached weiter bringt, bevor man sich einen zweiten Server hinstellt.
gepostet vor 17 Jahre, 11 Monate von Teonas
Original von Agmemon
Der klassische Flaschenhals (in der von-Neumann-Architektur) war eigentlich die CPU. Der Speicher konnte schneller Daten liefern, als die CPU verarbeiten konnte. Durch die Entwicklung, die mittlerweile vonstatten ging, hat sich das verschoben und der klassische Flaschenhals ist der Speicher. Zumindest was die Hardware Architektur betrifft.
Gilt das generell oder nur für den prof. bzw. privaten Bereich? Und hast du vielleicht ne gute Quelle dazu?
Original von Agmemon
Viel interessanter dabei ist, wie man mit einem Flaschenhals umgehen soll. Stellt sich zum beispiel die Datenbank als Flaschenhals heraus, kann man erstmal gucken, ob einen der Einsatz von memcached weiter bringt, bevor man sich einen zweiten Server hinstellt.
In dem von mir oben zitierten Beispiel wird Speicher-Locking als Entlastung für die DB eingesetzt.
gepostet vor 17 Jahre, 11 Monate von abuzeus
Original von Teonas
Original von Agmemon
Der klassische Flaschenhals (in der von-Neumann-Architektur) war eigentlich die CPU. Der Speicher konnte schneller Daten liefern, als die CPU verarbeiten konnte. Durch die Entwicklung, die mittlerweile vonstatten ging, hat sich das verschoben und der klassische Flaschenhals ist der Speicher. Zumindest was die Hardware Architektur betrifft.
Gilt das generell oder nur für den prof. bzw. privaten Bereich? Und hast du vielleicht ne gute Quelle dazu?/quote]
Ich könnte meinen Inf3-Prof zitieren. *g* Problem ist halt, dass die CPU immer schneller wird, die Geschwindigkeitssteigerungen bei RAMs da aber kaum mithalten können. Vgl [1]. Schneller Speicher ist halt sauteuer, und große Speichermengen sind halt teuer. Deswegen greift man ja auch zu Cache-Architekturen, mit diversen Cache-Ebenen. Daten aus dem Hauptspeicher nachzuladen bedeutet für die CPU meistens einige Millionen Stallzyklen, aus dem Cache gehts deutlich schneller. Inwiefern das auf die klassische Webanwendungg Auswirkungen hat, kann ich leider nicht sagen.
[1] www.acm.org/crossroads/xrds5-3/pmgap.html
vgl. auch Googlesuche nach "Performance Gap" evtl. mit Keywords Memory usw...
gepostet vor 17 Jahre, 11 Monate von Sarge
Also die aussage es ist ausgelastet obwohl nichts ausgelastet ist, ist schwachsinn.
Pauschalisieren kann man das im allgemeinen imho nicht aber mal ein wenig konkreter zu werden.
Bei einem nicht-threaded Webserver ist es meist der Speicher der die gleichzeitigen Requests limitiert. 2Gig Ram, im schnitt z.b. 10mb/process -> max 200 maximale gleichzeitige Requests.
Muss der Webserver swappen ist die performance absolut im eimer.
Hat nun jemand aber z.b. viele große schleifen die im cache arbeiten können, so kann dies aber ohne probleme auch direkt die cpu auslasten. Kommt drauf an was so läuft.
Serviert der Webserver reine statischen Files so ist cpu/ram zumeist kein problem und du kannst selbst mit einem alten 500mhz rechner die 100mbit der Netzwerkkarte auslasten.
Damit ein Datenbank-server voll ausgelastet werden kann, sollten alle Indezes und Daten (die genutzt werden) im Ram gehalten werden können. Dazu noch ein gewisse Menge für die query und thread-caches. Kurz um RAM kann Datenbank-server quasi nie genug haben. Sollte der RAM nicht reichen z.B. die Indezes im RAM zu halten, ist ein signifikanter leistungsverlust in der Regel zu spüren, da immer wieder auf die hdd zugegriffen werden muss.
Wieviel von der CPU-Leistung überhaupt genutzt werden kann hängt stark vom Datenbankdesign ab. Was nützen einem 4cpu's wenn alle versuchen auf eine myisam-tabelle zuzugreifen die nur table-locks beherrscht.
Will man sich viel ärger ersparen sollte man btw immer versuchen das im Normalbetrieb nie 100% der verfügbaren Ressourcen ausgelastet werden sondern ein genügen großes Pölsterchen zur verfügung steht.
//Btw dies sind nur meine Erfahrungen, nicht mehr nicht weniger.
Pauschalisieren kann man das im allgemeinen imho nicht aber mal ein wenig konkreter zu werden.
Bei einem nicht-threaded Webserver ist es meist der Speicher der die gleichzeitigen Requests limitiert. 2Gig Ram, im schnitt z.b. 10mb/process -> max 200 maximale gleichzeitige Requests.
Muss der Webserver swappen ist die performance absolut im eimer.
Hat nun jemand aber z.b. viele große schleifen die im cache arbeiten können, so kann dies aber ohne probleme auch direkt die cpu auslasten. Kommt drauf an was so läuft.
Serviert der Webserver reine statischen Files so ist cpu/ram zumeist kein problem und du kannst selbst mit einem alten 500mhz rechner die 100mbit der Netzwerkkarte auslasten.
Damit ein Datenbank-server voll ausgelastet werden kann, sollten alle Indezes und Daten (die genutzt werden) im Ram gehalten werden können. Dazu noch ein gewisse Menge für die query und thread-caches. Kurz um RAM kann Datenbank-server quasi nie genug haben. Sollte der RAM nicht reichen z.B. die Indezes im RAM zu halten, ist ein signifikanter leistungsverlust in der Regel zu spüren, da immer wieder auf die hdd zugegriffen werden muss.
Wieviel von der CPU-Leistung überhaupt genutzt werden kann hängt stark vom Datenbankdesign ab. Was nützen einem 4cpu's wenn alle versuchen auf eine myisam-tabelle zuzugreifen die nur table-locks beherrscht.
Will man sich viel ärger ersparen sollte man btw immer versuchen das im Normalbetrieb nie 100% der verfügbaren Ressourcen ausgelastet werden sondern ein genügen großes Pölsterchen zur verfügung steht.
//Btw dies sind nur meine Erfahrungen, nicht mehr nicht weniger.
gepostet vor 17 Jahre, 11 Monate von exception
Bei Datenbankservern (gerade wenn die Datenbanken sehr groß werden) sollte man auch auf die Festplatten achten. Nichts ist ärgerlicher als eine Festplatte, die die ganze Zeit am hin und herspringen ist und damit das ganze System ausbremst.
Vermeiden am besten durch Reduktion der Schreibzugriffe und ausreichend RAM.
Vermeiden am besten durch Reduktion der Schreibzugriffe und ausreichend RAM.