200 gleichzeitige Zugriffe

Also bei so konkreten Informationen, gibts auch ne konkrete Antwort ... klar, kann an Drupal liegen ... oder an ner Stromschwankung oder schlechtem Raumklima im Rechenzentrum. ;)
So kommen wir hier nicht weiter. Die Erfahrung mit 200 gleichzeitig angemeldeten Benutzern die auch tatsächlich noch 'gleichzeitig' was auf der Seite machen dürften hier allerdings nur seeeeeehr wenige haben.

Ich dachte 200 gleichzeitige Zugriffe ist nicht viel. Wir erwarten eigentlich viel viel mehr.

Ich denke du hast den Punkt nicht ganz verstanden. "200 gleichzeitigen Zugriffen" sagt technisch gesehen erstmal nicht aus, wovon du wirklich sprichst. 200 gleichzeitig eingeloggte User? 200 gleichzeitig (sagen wir mal in derselben Sekunde) angefragte Seiten? 200 parallel laufende Datenbankabfragen? 200 gleichzeitig laufende Webserver Instanzen?

Ohne konkrete Angaben kann man da auch nur oraklen, aber nicht wirklich hilfreich antworten. Es muss das Gesamtsystem (Hardware, Betriebssystem, Services, Anwendung, Anbindung, Konfiguration, Nutzerverhalten) betrachtet und analysiert werden und dazu reicht ein Gemeinplatz "gleichzeitige Zugriffe" nicht aus.

Mal so zum Vergleich:
Ein Traktor mit 200 PS wird an der Ampel keine Mofa verblasen, aber ein PKW mit 200 PS wird auch aufm Acker keinen Blumentopf gewinnen... Was also sagt "mein Fahrzeug hat 200 PS" aus? Genau: Für sich genommen erstmal nicht viel.

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Gibt es Werkzeuge mit dennen ich diese Zugriffe auswerten kann? Und Anhand dieser Auswertungen Schwachstellen erkenne? Zur Zeit schau ich auf die Seite und weiß nicht genau, wo ich anfangen kann.

Die Log-Dateien des Servers sollten eigentlich relativ einfach für Aufklärung sorgen oder wenigstens sehr weit weiterbringen.

Während des Hochbetriebs mal mit einem "ps aux" schauen was für Prozesse laufen, mit top schauen welche die Auslastung erzeugen, schauen ob es ein Last-Problem ist, oder ob einfach nur der Webserver zu unterdimensioniert konfiguriert ist, usw. usf.

Grundsätzlich bringt einen ein dedizierter Server nur dann weiter, wenn jemanden hat, der mit dem System umzugehen weiß und dieses im Idealfall auch aufgezogen hat.

Wie hieß es doch in Spiderman:
"With great power comes great responsibility."

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Ich habe jetzt ps aux aufgerufen und top angeschaut. Heute ist alles ruhig. Ich bin kein Systemadministrator, werde mich aber künftig mehr mit dieser Materie auseinander setzten müssen.

Ich weiß inzwischen auch welche Meldung damals gekommen ist. "To many Connections " Ist eigentlich eindeutig.

Es ist nicht im Drupal konfiguriert, dass diese Meldung kommt? Es ist im Server intergiert?

Mir wäre lieber, dass die Seite langsamer wird als er diese Meldung bringt.

Wir haben bereit einen deduzierten Server. Viel mehr kann der Kunde den Server nicht aufrüsten. Ich muss mir einfallen lassen wie ich die Auslastung optimieren kann.

Die Meldung "Too many connections" stammt im Grunde immer von der Datenbank. Für einen Webserver der am Limit agiert wäre es schwachsinnig eine Verbindung aufzumachen, die er nicht über hat, um eine solche Meldung auszugeben.

Also erstmal checken wie die RDBMS konfiguriert ist. Vermutlich ist es ein MySQL-Server. Also in die my.cnf bzw. die übrigen benutzten Dateien im Konfig-Verzeichnis schauen und die dortige Konfiguration checken. Außerdem schauen ob man irgendwo blöderweise persistente Verbindungen in seinem PHP-Kram nutzt. Das kann getrost auf normale Verbindung umgestellt werden, denn persistente Verbindungen müllen bei einem Webserver nur den RAM zu, werden gerne zu lange offen gelassen und bringen eher was bei wenigen langen Verbindungen mit jeweils vielen Abfragen, als bei vielen kurzen mit wenigen Abfragen.

Link: http://www.administrator.de/MySQL_-_Too_many_connections.html
(übrigens erster Treffer in Google für "too many connections" ;) )

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Jetzt habe ich es gesehe. Es ist der MySQL - Server der den Server überlastet. Es waren etwas über 100 Besucher auf der Seite. Weniger als 20 waren eingelogt.

Der MySQL Server hat wie wahnsinnig gearbeitet und es bewergte sich nichts mehr.

Ein deduzierter Server mit Prozessor 4,6 und Arbeitspeicher 3 GB müsste aber mehr verkraften oder?

Wenn ich nur wüsste welche Schritte den MySQL Server so belasten, könnte ich diese Funktion optimieren.

"show processlist;" wäre ein Anfang. Das Slow Query Log von MySQL wäre - wenn vorhanden - auch noch ein Quell interessanter Infos.

P.S.:
es heißt "dediziert" ;)

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Devel Modul

Schau dir außerdem mal das Devel Modul an (http://drupal.org/project/devel). Das hat eine funktion mit der du, als admin der Website, dir für jede Seite anzeigen lassen kannst
1) wieviele SQL abfragen pro Seite gemacht wurden
2) welche SQL Abfrage wie lange gedauert hat!!!
Über 2) wirst du relativ schnell feststellen können, dass es bestimmte Abfragen gibt die sehr oft und lange in anspruch genommen werden!

Caching?

Du hast geschrieben dass bei deinem letzten Test weniger als 20% der Benutzer wirklich eingelogt waren. D.h. du hast überwiegend anonyme Besucher für die caching sehr sinnvoll wäre. Hast du Caching eingeschaltet und ggf. mal den aggressive mode probiert bzw. dich damit beschäftigt?

Throttle

Damit deine Seite bei sehr hoher Besucherbelastung nicht vollkommen abschmiert gibt es, min. schon seit Drupalversion 4.7, das Modul "Throttle - Handles the auto-throttling mechanism, to control site congestion."
Mit diesem Modul kannst du bestimmte ressourcenintensive (siehe oben Punkt 2) ) Inhalte ausblenden lassen wenn ganz besonders viele Benutzer auf deiner Seite sind.

Drupal & MySQL High availability

Ob das jetzt noch weiterhilft weiss ich nicht genau, aber Dries Buytaert hat auf seinem blog vor einiger Zeit eine Präsentation von Kris Buytaert zum Thema "Drupal & MySQL High availability" beworben:
http://buytaert.net/drupal-and-mysql-high-availability

Beste Grüße und viel Erfolg!
Morgenstern

Vielen Dank.

Ich werde alles ausprobieren. Das Modul Devel installiert. Muss noch mit Konfiguration rumspielen und beobachten.

Caching aktiviert. Aggressive mode kann nicht einschalten, weil die Mehrsprachigkeit aktiviert haben.

Ich habe auch bereits an dem MySQL-Server in der my.cnf ein wenig an den Einstellugen geschraubt, da der Server größer ist als manche Standarteinstellungen.

Ich bin nur leicht frustriert, dass es bereits mit 100 Zugriffen so schlimm ist. Damit habe ich einfach nicht gerechnet. Man muss ja wirtschaftlich das betrachten. 1000 Zugrifee = 1 Abschluss. Man braucht schon Menge Zugriffe bis der Betreiber etwas verdient.

es gibt diverse Cache Module welche helfen

http://drupal.org/project/advcache
http://drupal.org/project/apc
http://drupal.org/project/blockcache
http://drupal.org/project/boost
--------------
Mein Blog: www.freeblogger.org
Deutscher IRC-Channel: irc.freenode.net #drupal.de je mehr desto besser
... Jabber-me: dereine@jabber.ccc.de Warum Jabber?

Ein paar Ratschläge in die Richtung:

a) Besorg Dir http://day32.com/MySQL/tuning-primer.sh
Damit kriegst Du auf die schnelle eine Auswertung der Einstellungen Deiner Datenbank. Wenn Du die Vorschläge umsetzt kitzelst Du eventuell etwas Leistung aus der Datenbank.

b) Php-Skripte cachen
http://eaccelerator.net/
Man glaubt gar nicht was das ausmachen kann.

c) Apache Server testen
Den Erfolg der Maßnahmen kannst Du leicht hiermit überprüfen

ab2 -n1000 -c100 http://www.DeineWebseite.de/

-n1000: 1000 Zugriffe
-c100: 100 zeitgleiche Zugriffe

Apache Server testen. Das habe ich nicht ganz verstanden. Wie kann ich das machen?

Entschuldigung, ich habe mich nicht deutlich ausgedrückt.

http://httpd.apache.org/docs/2.0/programs/ab.html

Ich weiß nicht wie es unter Windows aussieht, aber unter Linux kannst Du mit ab testen wann Dein Server in die Knie geht. Du simulierst von einem Fremdrechner die gewünschte Anzahl an (gleichzeitigen) Zugriffen und schaust Dir an wie sich die Antwortzeiten entwickeln.

Vor allem solltest du dir kurzfristig jemanden suchen, der mehr Erfahrung hat und dir sagen kann wo es hängt, warum es hängt und ggf. gegensteuern kann. Ohne eine fundierte Analyse sind alle Ratschläge, so gut gemeint sie auch sind, doch nur blinder Aktionismus.

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Hallo Leute,
wir stoßen so langsam an unsere Grenzen von Drupal oder denen des Servers. Dazu bräuchte ich Euer Fachwissen. Wir (www.allround-pc.com) nutzen D5.12 und bei 50 gleichzeitigen(!) Webserver Prozessen macht unser Server (Root: 2GB RAM, Dual Core Opteron, 2x160 GB) dicht. Die Auslastung von Mysql, PHP etc könnt Ihr hier beobachten: http://munin.allround-pc.com/com/Allround-PC.com.html
Ich habe seit wenigen Tagen die Lastreduzierung aktiviert und auf 45 Gäste eingestellt. Bin mir aber nicht wirklich sicher, ob es das bringt.
Folgende Performance Module sind installiert und aktiviert: Memcache, Boost, APC, CSS und Java Script Komprimierung, Cache auf normal eingestellt.
Vielleicht kann mir noch wer nen Tipp geben. Egal was für einer, ich bin für jede kleine Verbesserung offen! Danke!

Zum aktivierten Modul Boost - DB Lastreduzierung durch Dateien im Filesystem bei nicht eingeloggten Besuchern.

Bist Du sicher das Boost so laeuft wie es soll? Das bedeutet, hast Du geprueft ob als Ergebnis der Konfiguration von Boost wirklich Dateien im Filesystem liegen?

PS
Kannst Du mal den Link zu dieser Website mit den Lastproblemen posten?

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Der Link steht oben :) Es ist www.allround-pc.com

Boost läuft (richtig). Es werden im Cache Ordner massenhaft HTML Dateien angelegt, allerdings sehe ich gerade, nicht mehr mit der kompletten Größe wie früher. Alle Dateien sind nur noch 23 Bytes groß...
Liegt es evtl. daran, dass Boost nicht mit APC läuft? http://drupal.org/node/173804

Oeffne einfach solch eine Datei und sehe Dir ihren Inhalt an.

Damit Boost funktioniert benoetigt es keinen APC. Deswegen kann man Boost auch bei Shared Hosting verwenden.

-------------
quiptime

Nur tote Fische schwimmen mit dem Strom.

Hab die Datei runtergeladen, Quellcode stimmt mit der entsprechenden Seite überein, am Ende steht noch :
<!-- Page cached by Boost at 2008-12-03 11:00:46, expires at 2008-12-03 11:00:46 -->

PS: Das mit den 23 Bytes liegt daran, dass es eine Verknüpfung mit der node Datei (wegen pathauto). Die entsprechende Datei ist dann auch größer.

Man müsste sich die Auslastung / Aktivität und Konfiguration des apache, MySQL, Memcache und APC mal in Ruhe anschauen. Wenn man schon Munin einsetzt, ist es auch sinnvoll für alle relevanten Services Auswertungen zu fahren. In eurem Fall vermisse ich Memcache.

Was passiert bei euch morgens um 9, dass es dort immer einen einzelnen Peak beim Webserver gibt? Die Auswertung über die transferierte Datenmenge vom Apache ist mir auch nicht ganz geheuer. Hängt ihr mit der Karre an einem Inifiniband-Switch, oder wie kommt ihr auf Peaks von 125 MB die Sekunde? Sieht eher so aus, als würden da haufenweise Anfragen über localhost laufen..?

Interessant wäre auch zu wissen, was gestern ab etwa 1530 Uhr bei euch los war, dass es einen solchen Ausreißer gab. Leider hats durch das Geswappe in der Zeit auch die Stats zersemmelt. Ein bekanntes Problem. Von diesem breiten Peak abgesehen sieht alles soweit okay aus. CPU Last ist recht gering, IOWAIT ist bestens, RAM ist frei, ...

--

Gestern um 15:30 ist des zum Schlag gekommen, dass die 50 Prozesse erreicht wurden...

Die werden auch morgens um etwa halb neun erreicht. Die Frage ist, wo sie herkommen und ob sie "natürlichen" Ursprungs sind. Wenn dem so ist, ist eure Maschine ggf. nicht ausreichend für solche Spitzenlasten dimensioniert, da die 50 Webserverprozesse und die daran hängenden MySQL Abfragen den RAM Bedarf in die Höhe schrauben. Spätestens wenn die Karre auch noch anfängt den Speicher des Memcched auszulagern, ist der Server nur noch mit dem Swappen beschäftigt und reißt sich selber herunter. Darum wird in großen Szenarien der Memcached auf dedizierten Maschinen laufen gelassen, die nichts anderes machen. Lässt man alles auf derselben Maschine laufen, hat er keine größere Cache-Hit Rate als das DB-Caching von Drupal und entlastet die DB nur von den eh schon recht schnellen DB-Cache-Abfragen.

Entweder ihr findet Ursachen und schafft es über entsprechende Konfigurationen den Ressourcenbedarf im Worst Case deutlich zu reduzieren, oder ihr braucht viel mehr RAM.

Kann man aber alles von außen ohne passenden Input nicht adäquat beurteilen.

--

Der Begriff 200 Zugriffe gleichzeitig ist relativ.

Ich gebe mal einen Anhalt was mit

- Dual AMD 64 Bit (2,1 GHz BE-2350)
- 2-3GB RAM (400er)
- Normale Platten (Software RAID)

machbar ist.

Installation:

- Debian (ansich unwichtig)
- Diverse Drupal Versionen ab 4.7 aufwärts (mixed und Multisite)
- 1GB MyISAM Tables
- 256MB InnoDB Tables
- APC aktiv
- Memcache

Damit lassen sich durchaus komplette Page-Renderings von über 10-20/Sekunde erzielen. Das entspricht ~10-25K PageViews/Tag. Eher mehr.
Das entspricht auf meiner Installation etwa 2K DB Request in der Sekunde.
Das sind natürlich Zahlen, welche stark von der Anzahl Datenbanken, Tabellen, Drupal-Installs, Module etc abhängen. Die Zahlen bei mir fußen auf etwa 10K User, 100K Nodes und 50K Taxonomie-Begriffe. Also schon was mächtiger.

Bei allround-pc fällt auf, dass da die CPU zu 175% (von 200%) idle ist. Die pennt also nur (ein P3 würde das schaffen).
Das RAM kommt zwar theoretisch in Swap-Bereiche ist aber auch qausi leer. Das meiste ist da im allgemeinen Cache oder Buffer. Die effektive Nutzung des RAM liegt hier bei ~20%.
MySQL scheint ganz gut zu sein, da sehr viel aus dem Query-Cache bedient werden kann.

Der Engpass liegt hier woanders:
Was auffällt ist, dass die "Busy Apache Server" im Schnitt bei eta 10 liegen. Das ist nix :)
Der Peak von 150 MySQL-Threads ist enorm hoch und erzeugt dann auch direkt Swapping und Systemstillstand.

Von der Auslastung her würde allround-pc wesentlich mehr leisten können. Das Problem liegt hier klar am Durchsatz. Bei etwa 20% macht das System dicht und kümmert sich um sich selber, bis dass es anfängt zu swappen. Also etwas grundlegend falsch in der Config.
Wenn Du Dir die Stelle mit den 50 (Tuesday ~15:00) Prozessen anschaust, dann wirst Du feststellen, dass da Apache gestorben, MySQL 150 nichtstuende Thread gestartet hat, die nichts an Query machten (Deadlock). Dein Netstat ist zur gleichen Zeit hochgegangen, was eher seltsam ist und auf eine nicht vorhandene Firewall hinweisen kann und jemand versucht von extern auf Deine DB zu connecten.
Die CPU tat zu dem Zeitpunkt null-komma-nix. Dein RAM lief aber voll (150 nichtbeendende MySQL-Thread) und der Tod klopfte an die Tür.

Apache würde ich mal mit etwa

und MySQL mit

Bevor man anfängt in Drupal runmzutricksen sollte man ersteinmal zusehen, dass Apache und MySQL ordentlich installiert und konfiguriert sind. 99% der Sünden liegen schon hier.

Neben tuning_primer ist http://mysqltuner.com/ sehr zu empfehlen.

Mehr dazu auch am 17.+18. Januar 2009 (http://drupalcamp.de/node/77) ;)

schon probiert? Hat man beides (Webserver und Datenbankserver) auf einem Rechner oder dedizierten Server, ist die Leistung meiner Erfahrung nach sehr bescheiden. Eine Auslagerung hat bei mir zumindest das mehrfache der Leistung herausgeholt. Allgemein habe ich eine Richtlinie im Kopf (ich weiss nicht mehr woher) dass ein Prozessor ca. 1000 User pro Sekunde verarbeiten kann (Bitte um Berichtigung, falls das nicht mehr zutrifft). Alles andere liegt dann am Durchsatz der Datenbank (Anzahl Festplatten) oder der Größe des RAM. Ich denke aber nicht, dass deine DB 2 GB überschreitet, oder?

Danke schonmal für die Kommentare.
Unsere Apache:

Mysql hab ich gerade ned zur Hand...

Unsere DB hat etwa ne Größe von 300 MB. Dazu kommen halt noch paar kleinere Datenbank aufm Server, aber das spielt ja nur eine sehr kleine Rolle.

wird in dem Falle gar nichts bringen.
Der Server ist ja gestorben, weil 150 MySQL's das System ans Swappen brachten und eh kein Apache mehr lief.

Zum groben kalkulieren von RAM
Apache: Maximale Anzahl Threads * PHP-Ram-Limit = Max Apache RAM
MySQL: Globale Buffer + Maximale Anzahl Threads * PerThreadBuffer = Max MySQL RAM

Überschreitest Du mit beidem zusammen wesentlich (mehr als 25-50%) die echte RAM-Grenze, dann bekommst Du ein Problem mit dem Swapping und Dein System steht. Ist immer eine Mischkalkulation, wenn man Web, DB und Mailserver auf ein und derselben Box betreibt.

Der Deadlock:
Das passierte hier schon mit dem MySQL alleine. 150 MySQL-Thread bringen das System so in's swappen, dass sich nicht mehr tut.

Die Maschine verkraftet die Website locker. Das Problem ist hier ein Deadlock.
Die Last muss etwas geschickter verteilt werden und die Limits richtig gesetzt sein.

Weniger ist hier oft mehr.

Ist tödlich und kann nicht wirklich über MaxClients 50 liegen.

Würde ja bedeutet, dass maximal 50 Apache Instanzen laufen können aber 1 davon 250 Requsts absetzen darf. Damit könnte bei persistenter PHP-MySQL Verbindung und großem KeepAliveTimeout (sollte zwischen 5 und 15 liegen) richtiger Unsinn getrieben werden (F5 Reload).

Das wird aber mit Sicherheit nicht zu dem Ausfall geführt haben.

Auf der anderen Seite hast du bei kleinem MRPC den Overhead ständig neue Instanzen spawnen zu müssen. Bei Servern die nur eine Anwendung ausliefern sollte man ggf. mal schauen wieviele Ressourcen pro Seite angefragt werden und sich zahlenmäßig dahingehend orientieren.

Ein sauber laufendes System bringt den Benutzer gar nicht erst in die Verlegenheit F5 zu drücken, von daher ist das ein nachgelagertes Problem, welches man erstmal aus der Betrachtung ausnehmen kann.

Von Haus aus benutzt Drupal übrigens gar keine persistenten DB Verbindungen zu MySQL. Dazu müssten man händisch die /includes/mysql.inc.php ändern, wie dort im Kommentar zur Funktion db_connect() beschrieben.

--

Ich bin momentan ebenso am verbessern der Leistung unserer Seite. Ich arbeite gerade sämtliche YSlow Ergebnisse durch. Außerdem habe ich bereits JS Aggregation und Minimizing installiert. Wir betreiben eine D5 Seite.

Auf der Suche nach erweiterten Caching Methoden bin ich auf CacheRouter aufmerksam geworden (http://drupal.org/project/cacherouter). Allerdings gibt es bisher nur eine Beta Version. Hat jemand Erfahrung mit dem Modul? Es scheint APC und Memcache zu ersetzen bzw zu verwenden, das Projekt sieht sehr interessant aus.

Würde mich wie gesagt interessieren, wenn jemand zu dem besagten Modul schon Erfahrungen gesammelt hat.

Grüße
Florian

Cacherouter scheint wirklich interessant zu sein, aber ich scheiter schon an der Konfiguration.

Wo sollen die Zuwächse serverseitig denn auch herkommen, wenn die Karre kaum Last hat?

Du kannst deinen Wagen tunen wie du willst, so lange du nicht das Gaspedal durchdrückst, wirst du nichts davon haben.