QCO hat geschrieben:
massive Probleme betreffend der Performance erzeugt. Sobald diese Seite einmal aufgerufen wird arbeiten sehr viele http Prozesse gleichzeitig mit insgesammt 100% CPU Last. Ich vermute, dass die angewendete Applikation entweder sehr lastige Aktionen durchführt, oder eine Endlosschleife erzeugt.
Ohne zu wissen wieviele Seiten auf diesem Server gehostet werden und ohne zu wissen was für Scripte und wie Speicherintensiv bzw. Rechenintensiv diese gecodet werden ist eine mögliche Fehlerursache ungenau.......
Ich betreibe unter dieser Domain eine CMS-Seite, die auf phpbb fußt, allerdings relativ viele selbst geschriebene Skripte hat, die template und db-layer von phpbb nutzen. Im Prinzip werden also auf jeder Seite die phpbb-Basics instanziert und normal initialisiert und danach ein paar Aktionen durchgeführt, die ähnlich dem sind, was phpbb tun würde.
PHPBB Portale usw. kann man als Performance Bremse bezeichnen......Was SQL z.B. anbelangt und diverse Mods......
Auch das nicht cachen von Templates trägt dazu bei.....
Wie kann ein HTTP-Aufruf mehrere Prozesse zur Folge haben? Ok, beim Aufruf der Seite werden Bilder nachgeladen, aber das ist wohl normal, oder?
Wenn PHP als Modul läuft (und das tut es), sollte der Apache doch den einen Request mit auch nur einem Prozess bearbeiten, oder?
Apache hat geschrieben:
In particular, Apache required a "ramp-up" period in order to reach a number of children sufficient to serve the load being applied. After the initial spawning of StartServers children, only one child per second would be created to satisfy the MinSpareServers setting. So a server being accessed by 100 simultaneous clients, using the default StartServers of 5 would take on the order 95 seconds to spawn enough children to handle the load. This works fine in practice on real-life servers, because they aren't restarted frequently. But does really poorly on benchmarks which might only run for ten minutes.
The one-per-second rule was implemented in an effort to avoid swamping the machine with the startup of new children. If the machine is busy spawning children it can't service requests. But it has such a drastic effect on the perceived performance of Apache that it had to be replaced. As of Apache 1.3, the code will relax the one-per-second rule. It will spawn one, wait a second, then spawn two, wait a second, then spawn four, and it will continue exponentially until it is spawning 32 children per second. It will stop whenever it satisfies the MinSpareServers setting.
This appears to be responsive enough that it's almost unnecessary to twiddle the MinSpareServers, MaxSpareServers and StartServers knobs. When more than 4 children are spawned per second, a message will be emitted to the ErrorLog. If you see a lot of these errors then consider tuning these settings. Use the mod_status output as a guide.
Related to process creation is process death induced by the MaxRequestsPerChild setting. By default this is 0, which means that there is no limit to the number of requests handled per child. If your configuration currently has this set to some very low number, such as 30, you may want to bump this up significantly. If you are running SunOS or an old version of Solaris, limit this to 10000 or so because of memory leaks.
When keep-alives are in use, children will be kept busy doing nothing waiting for more requests on the already open connection. The default KeepAliveTimeout of 15 seconds attempts to minimize this effect. The tradeoff here is between network bandwidth and server resources. In no event should you raise this above about 60 seconds, as most of the benefits are lost.
Da hab ich nicht ganz den Durchblick, weil ich nur Windows kenne. Dort läuft der Apache mit nur einem Prozess und spant nur Threads zum Bearbeiten von Anfragen.
Auch da werden Child Prozesse erzeugt.....
Was hat das mit dem SQL-Server zu tun?
Ich hab gestern und heute gemessen. Die durchschnittliche Generierungszeit der bemängelten Seite schwankt zwischen 0,3 Sek Vormittags und 1,4 Sekunden am Abend. Das deutet doch eher auf eine generelle Auslastung des Servers hin.
Mit den ausgelasteten Apache Prozessen sicherlich wenig.....Aber wenn die Datenbank auf dem gleichen Server ist und sich dieser zu Tode quält hat das natürlich weitreichende Folgen bei einem Sharehosting.....
Auf welche Weise kann man den einen Server komplett auslasten? Ich hab den Code der Seite nochmal durchgesehen und nichts besonderes gefunden; zumindest keine Endlossschleife...
Resampling von Bildern via GD oder ein IP Scanner nach offenen Ports in einem Intranet z.B.
Schleifen im Allgemeinen bei z.B. einem Newsletterskript wo normal PHP stoppen sollte......(rechenintensiv)
Abschließend kann man sagen wenn nach Jedem starten deiner Seite die Prozesse ausgelastet sind, dann bist du das Problem des Servers......
Aber man soll den Teufel nicht an die Wand malen.....
