RootForum Community

Hallo liebe Rootcommunity,

wir haben einen Rootserver XL von 1&1 und haben massive Probleme mit dem Server in Spitzenzeiten, dh. wenn sehr viele User online sind (ca. 250 000 Hits / Stunde) und auf ein paar wenige HTML Seiten (werden durch PHP generiert) zugreifen, die ständig akutalisiert werden. In dieser Zeit läuft alles sehr langsam, wenn überhaupt noch. Eine Anfrage dauert etwa 20-30 Sekunden. An was kann das liegen, die 1&1 Hotline hat auch keinen Rat, woran das liegen kann.

Ich bitte um Hilfe oder evtl. Links zu vorhandenen Threads zu diesem Thema.

...aber irgendwie liegt das doch auf der Hand, oder? Es sind keine statischen Seiten, sondern dynamisch erzeugte... ;-)
Da wird PHP der Flaschenhals sein... benutzt du noch 'ne MySQL-Datenbank im HG, die dir die Daten liefert?

Hilfreich wären Informationen über deine Speicherauslastung auf dem Server und ein Ã?berblick über die laufenden Prozesse...

Du solltest einmal generell ein paar Optimierungen vornehmen, um dem Server ein wenig unter die Arme zu greifen. Ein PHPCache wie TurckMM wäre wohl recht praktisch, zudem ein QueryCache, wenn die Daten durch MySQL geliefert werden. Und eine Abschaltung der persistenten MySQL Connections bringt auch meistens etwas...
Wenn du mit der Speicherauslastung Probleme haben solltest, dann bietet sich es an, dass du unbenutzte Apache-Module auskommentierst (Python, Perl...) und deine PHP-Distribution etwas abspeckst (Postgres Unterstützung raus usw...)

Schilder mal deine Probleme etwas genauer belegt durch Zahlen und Fakten, dann können wir dir wohl auch ein ganzes Stück weiterhelfen.

Gruß, Vevelt.

Vevelt wrote:Es sind keine statischen Seiten, sondern dynamisch erzeugte...

Nein, es sind eben keine dynamischen Seiten, sondern rein statisches HTML. PHP wird nur zum Schreiben dieser Seiten benutzt. Das was den Usern zur Verfügung gestellt wird ist reines HTML, hier wird nichts geparst. Die Seiten werden geschrieben, dann in ein anderes Verzeichnis kopiert und von dort abgerufen. Was die Zzahlen betrifft, so müssen wir diese erst generieren. Aber eben weil es sich nur um HTML-Seiten handelt, kann ich das Problem nicht nachvollziehen.

Andi22 wrote:Nein, es sind eben keine dynamischen Seiten, sondern rein statisches HTML

Google: thttp fnord tux

Andi22 wrote:

Vevelt wrote:Es sind keine statischen Seiten, sondern dynamisch erzeugte...

Nein, es sind eben keine dynamischen Seiten, sondern rein statisches HTML. PHP wird nur zum Schreiben dieser Seiten benutzt. Das was den Usern zur Verfügung gestellt wird ist reines HTML, hier wird nichts geparst. Die Seiten werden geschrieben, dann in ein anderes Verzeichnis kopiert und von dort abgerufen. Was die Zzahlen betrifft, so müssen wir diese erst generieren. Aber eben weil es sich nur um HTML-Seiten handelt, kann ich das Problem nicht nachvollziehen.

So ganz kann ich das noch nicht verstehen... :?:
So, wie ich das verstanden habe, werden die HTML-Seiten bei jedem Aufruf erzeugt, oder? Irgendein "Signal" des Anstosses muss PHP ja bekommen, um diese Seiten zu erzeugen... ;-)
Und was für Zahlen sind das? Wo kommen die her?

Wenn es wirklich nur statische HMTL-Seiten sind, kann ich das Problem auch nicht wirklich nachvollziehen, aber irgendwie scheint PHP da ja nun auch eine Rolle zu spielen... kannst du das noch genauer schildern?

Was noch an Infos nützlich wäre: Apache Version, PHP Version...
Hast du den Server zu Spitzenzeiten mal per ssh beobachtet, welche Prozesse dort viel Zeit und Speicher beanspruchen?

Gruß & Danke, Vevelt.

Joe User wrote:

Andi22 wrote:Nein, es sind eben keine dynamischen Seiten, sondern rein statisches HTML

Google: thttp fnord tux

Gute Idee, wenn es wirklich der Apache als Engpass ist und nicht PHP oder andere möglicherweise beteiligten Komponenten... :D

Das ist folgendermaßen: über ein Formular werden während eines Events stetig Daten in eine Datenbank geschrieben. Nachdem der Datensatz eingetragen wurde, werden aus der Tabelle heraus mehrere statische HTML-Files geschrieben, die nachdem sie geschrieben wurden in ein anderes Verzeichnis kopiert werden, wo sie für den User zum Abruf bereitgestellt werden. Zu dieser Lösung habe ich mich entschlossen, da ich zuvor mit einer reinen PHP-Mysql-Lösung (dynamische Seiten mit direktem Datenbankzugriff) den Server ebenfalls regelmäßig an den Rand des Kollaps brachte, und regelmäßig mit den Ops der Provider in Kontakt stand.

Andi22 wrote:Das ist folgendermaßen: über ein Formular werden während eines Events stetig Daten in eine Datenbank geschrieben. Nachdem der Datensatz eingetragen wurde, werden aus der Tabelle heraus mehrere statische HTML-Files geschrieben, die nachdem sie geschrieben wurden in ein anderes Verzeichnis kopiert werden, wo sie für den User zum Abruf bereitgestellt werden. Zu dieser Lösung habe ich mich entschlossen, da ich zuvor mit einer reinen PHP-Mysql-Lösung (dynamische Seiten mit direktem Datenbankzugriff) den Server ebenfalls regelmäßig an den Rand des Kollaps brachte, und regelmäßig mit den Ops der Provider in Kontakt stand.

Ok, das gibt doch einen ganz guten Ã?berblick... ;-)
Dir ist klar, dass auf die gerade in den Kopiervorgang involvierten Dateien noch kein Zugriff möglich ist? Das könnte teilweise ein "bremsender" Faktor sein. Ansonsten würde ich Joe User zustimmen, dass du möglicherweise einmal einen alternativen "minimalistischen" WebServer ausprobieren solltest, der sich nur um die Verzeichnisse/Domains mit den HMTL-Files kümmert... :D

Gruß. Vevelt.

70 Hits / Sekunde sind halt auch schon recht viel. Im Apache evtl. KeepAliveTimeout klein stellen oder ganz abschalten. Ist MaxClients hoch genug?

Alexander Newald wrote:Im Apache evtl. KeepAliveTimeout klein stellen oder ganz abschalten.

Sinn macht dies nur bei rein dynamischen Elementen. Die Ausieferung statischer Elemente wird dadurch erheblich ausgebremst...

Joe User wrote:

Alexander Newald wrote:Im Apache evtl. KeepAliveTimeout klein stellen oder ganz abschalten.

Sinn macht dies nur bei rein dynamischen Elementen. Die Ausieferung statischer Elemente wird dadurch erheblich ausgebremst...

Kommt darauf an, ob die Anzahl der Clients, die evtl. auf einen Timeout vom Keepalive warten die Anzahl der freien Clients soweit einschränkt, dass nicht mehr genügend freie Clients zur Verfügung stehen.

Dies ist übrigens auch die offizielle Empfehlung der Apache Docs...