Dirk, liebe Liste, > Allerdings gibts eine nicht unerhebliche Differenz zwischen dem > Skript-Processing und den Response-Times.
Ich lese den thread mit belustigter Verwirrung mit. Da ich php für Teufelskram halte kann ich dazu auch nichts sagen. Aber vielleicht müssen wir zu den Wurzeln zurück: load=30 ist hammerhart. load=3 würde ich schon für extrem kritisch halten: Da warten bei load=30 also 30 Prozesse im Scheduler dass die auch mal drankommen dürfen. Und das sind wohl genau die Prozesse, die mit "write" beim Apache rumstehen. Ich versteige mich zu der Aussage, dass das Ziel load < 1 ist. Irgendwo ist also ein _extremer_ Flaschenhals. Und der Teufel namens php kann das ja nun kaum sein. Was haben wir als Verdächtige? * CPU ** wohl kaum. Die hätte schon abgekackt. * Bandbreite gen Web. Das wäre wirklich ein Verdächtiger. Aber das erklärt nicht, warum das mit steigenden Requests steigt. Passt auch nicht. * Bus-Breite gegen Plattenstrecke. Ich habe mehrfach die Beobachtung gemacht, dass Apache extrem nicklig ist, wenn er nix bekommt oder nix wegschreiben kann. Dann steigt die load schnell in extreme Größen. Und das ist mein Verdacht beim Mitlesen. Rein analythisch: Was haben wir da so? * die mysql-Datenbank selbst: Liefert die schnell genug? * das interne Netz: Bounct da was? IRGENDWAS, was da falsch geroutet wird? * die eigene Plattenstrecke: Alle Platten ok? Ok, nun lehne ich mich ganz weit aus dem Fenster: 10 Euro als Wette auf den Tisch! Dein Apache bekommt die Logs nicht weggeschrieben. Du hast ein Problem mit der Plattenstecke in dem Rechner, in dem Apache läuft. Wette ich jetzt mal. Mit freundlichen Gruessen, Martin Ebert -- http://www.klug-suchen.de -------------------------------------------------------------------------- Apache HTTP Server Mailing List "users-de" unsubscribe-Anfragen an [EMAIL PROTECTED] sonstige Anfragen an [EMAIL PROTECTED] --------------------------------------------------------------------------
