nicht angemeldet
DoS
Hallo,
vielleicht kennt der eine oder andere das Phänomen:
Die Logdateien sind leer, der Browser sendet nur ein Timeout, ps aux liefert seitenweise Kindprozesse des apachen... Die Errorlogdatei ist dagegen voll von:
[info] server seems busy, (you may need to increase StartServers, ThreadsPerChild or Min/MaxSpareThreads), spawning 8 children, there are around 1 idle threads, and 20 total children
Was ist zu tun?
Soll man auf Keep-Alive verzichten und Timeout herabsetzen? Gibt es eine Faustformel nach Arbeitspeicher und CPUs wieviele Prozesse (in dem Fall Threads) der Apache maximal starten darf?
Die derzeitige Testkonfiguration:
Apache 2.0.53 mit MPM worker auf Linux
ThreadLimit 610
ServerLimit 21
StartServers 2
MaxClients 600
MinSpareThreads 5
MaxSpareThreads 50
ThreadsPerChild 30
MaxRequestsPerChild 100000
Vielen Dank und Gruß aus Berlin! eddi
-
Moin!
Die derzeitige Testkonfiguration:
Apache 2.0.53 mit MPM worker auf Linux
War da nicht was, dass der Apache mit MPM Worker (noch) ein Problem mit PHP hatte? Du hast doch bestimmt auch PHP drauf, oder?
Außerdem gibts ein Problem mit amd64 und mod_rewrite. Einige reguläre Muster erzeugen Endlosschleifen.
Mit anderen Worten: Deine Konfigurationsbeschreibung ist noch lange nicht vollständig.
- Sven Rautenberg
-
Moi Moin!
Apache 2.0.53 mit MPM worker auf Linux
War da nicht was, dass der Apache mit MPM Worker (noch) ein Problem mit PHP hatte? Du hast doch bestimmt auch PHP drauf, oder?
Außerdem gibts ein Problem mit amd64 und mod_rewrite. Einige reguläre Muster erzeugen Endlosschleifen.
Aha, das wußte ich nicht.
Mit anderen Worten: Deine Konfigurationsbeschreibung ist noch lange nicht vollständig.
Der Server ist derzeit mit
./configure
--with-mpm=worker
--enable-auth-digest
--enable-expires
--enable-headers
--enable-logio
--enable-so
--enable-ssl
--enable-suexec
--with-suexec-bin=/~
--with-suexec-caller=10000
--with-suexec-docroot=/~
--with-suexec-gidmin=100
--with-suexec-safepath=/~
--disable-actions
--disable-asis
--disable-auth
--disable-autoindex
--disable-cgi
--disable-cgid
--disable-env
--disable-imap
--disable-include
--disable-status
--disable-userdir
CFLAGS="-O3 -march=athlon -fomit-frame-pointer -pipe"kompiliert worden. PHP wurde in Version 5.0.4 als Hanlder eingebunden und im wesentlichen mit --disable-all konfiguriert; die Erweiterungen werden modular eingebunden.
Das Problem ist prinzipieller Art, da es auch auf einen apachen 1.3.x anwendbar ist.
Gruß aus Berlin! eddi
-
Hallo!
Die Logdateien sind leer, der Browser sendet nur ein Timeout, ps aux liefert seitenweise Kindprozesse des apachen...
Welche Logdateien? access_log? Wieviel hat der Server denn zu tun? Was sagt
topund evtl. auch mod_status?Die Errorlogdatei ist dagegen voll von:
[info] server seems busy, (you may need to increase StartServers, ThreadsPerChild or Min/MaxSpareThreads), spawning 8 children, there are around 1 idle threads, and 20 total children
Das heißt Du hast sehr viele dieser Einträge? http://httpd.apache.org/docs-2.0/misc/perf-tuning.html#process
Soll man auf Keep-Alive verzichten und Timeout herabsetzen?
Bei PHP würde ich Keep-Alive abschalten, ja.
Gibt es eine Faustformel nach Arbeitspeicher und CPUs wieviele Prozesse (in dem Fall Threads) der Apache maximal starten darf?
Das kommt drauf an wie groß die Prozesse sind (ist wegen shared memory aber nicht ganz einfach zu berechnen, siehe ggfs.: http://kris.koehntopp.de/artikel/webtune/)
Die derzeitige Testkonfiguration:
Apache 2.0.53 mit MPM worker auf Linux
> ThreadLimit 610 > ServerLimit 21 > StartServers 2 > MaxClients 600 > MinSpareThreads 5 > MaxSpareThreads 50 > ThreadsPerChild 30 > MaxRequestsPerChild 100000 >Das sind soweit ich das sehe nicht die Standardwerte. Wie bist Du auf die gekommen?
Zu dem was Sven zum Worker-MPM zusammen mit PHP gesagt hat siehe: http://de3.php.net/manual/de/faq.installation.php#faq.installation.apache2
Vielleicht ist Deine Hardware einfach überfordert? Vielleicht hilft Dir in dem Fall auch der Feature Artikel von CK: http://aktuell.de.selfhtml.org/artikel/server/apachetuning/index.html
Grüße Andreas
--
SELFHTML Feature Artikel: http://aktuell.de.selfhtml.org/artikel/-
Hallo Andreas,
cielen Dank für diese Links. Wenn Du JETZT(!) kurz auf http://eddi.to-grip.de/ schauen würdest. (Es dauert extrem lange, bis eine Verbindung einsetzt.) Das ist ein apache 1.3.29, den ich nicht eingerichtet habe (PHP ist hier CGI). Der einzige unterschied ist, das hier in den Logdatein der Status 408 notiert wird.
Gruß aus Berlin! eddi
-
Hallo!
cielen Dank für diese Links. Wenn Du JETZT(!) kurz auf http://eddi.to-grip.de/ schauen würdest. (Es dauert extrem lange, bis eine Verbindung einsetzt.) Das ist ein apache 1.3.29, den ich nicht eingerichtet habe (PHP ist hier CGI). Der einzige unterschied ist, das hier in den Logdatein der Status 408 notiert wird.
Hm. Komischerweise ist ein ping sehr schnell. Ist aus der Entfernung schwer zu sagen. Entweder der Server ist total überlastet (was ich wie gesagt eher nicht glaube, wg. ping), dann müsstest Du in top halt eine entsprechende Auslastung sehen. Wie sieht das vor allem mit Swap, CPU... aus? 408 heißt ja "Request Timeout" (http://www.checkupdown.com/status/E408.html). Wenn ich mich richtig erinnere gibt es auch DoS-Tools ganz viele Verbindungen zum Server aufbauen, dann aber keinen Request senden, so dass der irgendwann nicht mehr richtig arbeiten kann. Aber ich weiß nicht ob das zu 408-Fehlern führt. Vielleicht hängen sich die Prozesse auch der Reihe nach durch ein kaputtes Script auf? Ich würde auch mal einen Blick auf mod_status werfen! Da kannst Du sehen was die einzelnen Prozesse gerade machen.
Grüße Andreas
--
SELFHTML Linkverzeichnis: http://aktuell.de.selfhtml.org/links/-
Hallo Andreas!
Hm. Komischerweise ist ein ping sehr schnell. Ist aus der Entfernung schwer zu sagen. Entweder der Server ist total überlastet (was ich wie gesagt eher nicht glaube, wg. ping), dann müsstest Du in top halt eine entsprechende Auslastung sehen. Wie sieht das vor allem mit Swap, CPU... aus?
Swap leer, CPU ca. 1%.
408 heißt ja "Request Timeout" (http://www.checkupdown.com/status/E408.html). Wenn ich mich richtig erinnere gibt es auch DoS-Tools ganz viele Verbindungen zum Server aufbauen, dann aber keinen Request senden, so dass der irgendwann nicht mehr richtig arbeiten kann. Aber ich weiß nicht ob das zu 408-Fehlern führt. Vielleicht hängen sich die Prozesse auch der Reihe nach durch ein kaputtes Script auf? Ich würde auch mal einen Blick auf mod_status werfen! Da kannst Du sehen was die einzelnen Prozesse gerade machen.
Ja - exakt das passiert da mit einem PHP-Script (ein FÜNFZEILER!). Nur wie schütze ich mich davor?
Gruß aus Berlin! eddi
-
Hi!
Ja - exakt das passiert da mit einem PHP-Script (ein FÜNFZEILER!).
Wie sehen die 5 Zeilen aus, und woher weißt Du dass die dafür verantwortlich sind?
Nur wie schütze ich mich davor?
Hm, eigentlich sollte sowas überhaupt nicht passieren. Musst halt die genaue Ursache finden und beheben. Ich hatte sowas mal mit einer Zend-Extensions für PHP. Die hatte irgendeinen Fehler, und hat unter bestimmten Bedingungen den Prozess aufgehängt. Sobald Du so einen Fehler im System hast, kannst Du AFAIK nicht viel dagegen machen, jeder Apache-Prozess bei dem der Fehler auftritt wird sich aufhängen, oder zumindst für einige Zeit nichts machen.
Grüße Andreas
--
SELFHTML Feature Artikel: http://aktuell.de.selfhtml.org/artikel/-
Hallo,
Ja - exakt das passiert da mit einem PHP-Script (ein FÜNFZEILER!). Wie sehen die 5 Zeilen aus, und woher weißt Du dass die dafür verantwortlich sind?
Das script macht sich per Mail zu Dir auf den Weg, es ist das DoS-Script, ich habe damit den localen und produktiven Server außer Gefecht gesetzt.
Nur wie schütze ich mich davor?
Hm, eigentlich sollte sowas überhaupt nicht passieren. Musst halt die genaue Ursache finden und beheben. Ich hatte sowas mal mit einer Zend-Extensions für PHP.
Was macht Euch beide so sicher, daß ein PHP-Script auf dem Server angesprochen wird, gar PHP nur irgendetwas damit zutun hat, außer das das DoS-Script in PHP geschrieben ist und mit dem CLI-Binär ausgeführt wird?
Die hatte irgendeinen Fehler, und hat unter bestimmten Bedingungen den Prozess aufgehängt. Sobald Du so einen Fehler im System hast, kannst Du AFAIK nicht viel dagegen machen, jeder Apache-Prozess bei dem der Fehler auftritt wird sich aufhängen, oder zumindst für einige Zeit nichts machen.
Ich habe schlicht und einfach nur noch Schieß, wenn ich sehe, wie schnell ein Server mal kurz Port 80 dicht macht...
Gruß aus Berlin! eddi
-
Hallo!
Das script macht sich per Mail zu Dir auf den Weg, es ist das DoS-Script, ich habe damit den localen und produktiven Server außer Gefecht gesetzt.
Ach, Du provozierst selbst einen DoS? Das war mir nicht klar ;-)
Nur wie schütze ich mich davor?
Naja, wenn Du viele Verbindungen zum Server herstellst, wartet der Apache bis der "Timeout" abläuft, um die Verbindung zu schließen falls da nichts vom Client kommt. Wenn sowas passiert musst Du halt inidividuell reagieren, vielleicht kannst Du die Angriffe per Firefall abblocken, und sonst den Timeout sehr weit runtersetzen, dass Du diese Verbindungen möglichst schnell wieder los bist. Allerdings, wenn der Angreifer genügend Bandbreite / Performance hat und Du nicht in der Lage bist dessen Pakete vor dem Webserver abzufangen, kannst Du nicht viel tun. Es gibt immer wieder Angriffe die komplette Cluster lahmlegen (z.B. erst kürzlich den Heise LoadBalancer mit 25 Servern dahinter), dessen Admins sicher wissen was sie tun. D(D)OS ist halt ein Problem für das es noch nicht wirklich ein Patentrezept gibt.
Siehe auch http://www.heise.de/ix/artikel/2005/04/107/
Was macht Euch beide so sicher, daß ein PHP-Script auf dem Server angesprochen wird, gar PHP nur irgendetwas damit zutun hat
Weil das oft der Fall ist ;-)
Ich habe schlicht und einfach nur noch Schieß, wenn ich sehe, wie schnell ein Server mal kurz Port 80 dicht macht...
Ach, so ein Angriff wie von Deinem Script lässt sich sehr leicht filtern ;-)
Grüße Andreas
--
SELFHTML Linkverzeichnis: http://aktuell.de.selfhtml.org/links/-
Hallo!
Ach, Du provozierst selbst einen DoS? Das war mir nicht klar ;-)
Das muß ich mir eingestehen, im blanken Schock habe ich das auch vergessen deutlich zu sagen.
Nur wie schütze ich mich davor? Naja, wenn Du viele Verbindungen zum Server herstellst, wartet der Apache bis der "Timeout" abläuft, um die Verbindung zu schließen falls da nichts vom Client kommt. Wenn sowas passiert musst Du halt inidividuell reagieren, vielleicht kannst Du die Angriffe per Firefall abblocken, und sonst den Timeout sehr weit runtersetzen, dass Du diese Verbindungen möglichst schnell wieder los bist. Allerdings, wenn der Angreifer genügend Bandbreite / Performance hat und Du nicht in der Lage bist dessen Pakete vor dem Webserver abzufangen, kannst Du nicht viel tun. Es gibt immer wieder Angriffe die komplette Cluster lahmlegen (z.B. erst kürzlich den Heise LoadBalancer mit 25 Servern dahinter), dessen Admins sicher wissen was sie tun. D(D)OS ist halt ein Problem für das es noch nicht wirklich ein Patentrezept gibt.
Auch google weiß zu Hauf von Angriffen zu berichten. Dabei sind der deutschsprachige Raum sehr geprägt von einer Erzählung über zwei Rechtsanwälte... Allgemein sehe ich aber auch nirgends Lösungshinweise, sondern nur die reine Berichterstattung.
Ich habe schlicht und einfach nur noch Schieß, wenn ich sehe, wie schnell ein Server mal kurz Port 80 dicht macht...
Ach, so ein Angriff wie von Deinem Script lässt sich sehr leicht filtern ;-)
Also heißt das eine Firewall? Nanu war ihr nicht immer die einhellige Meinung "man kennt doch seine laufenden Dienste auf der Maschine - warum ein Firewall". Auch die Dokumentation des apachen spricht sich in Hinblick auf den Nutzen für Keep-Alive und wegen alter druchgeschliffener C-Code gegen ein herabsetzen des Timeout aus. Sind das alles nur auf der Watte -ein jeder benimmt sich so, wie der Zweck es vorhergesehen hat- gutgemeinte Ratschläge?
Also bitte ich noch mals um Hilfe: Was an Sicherheit(ssoftware) braucht nun ein Server wirklich?
Gruß aus Berlin! eddi
-
Hi!
Allgemein sehe ich aber auch nirgends Lösungshinweise, sondern nur die reine Berichterstattung.
Es gibt aufgrund der Struktur des Internets keine "richtige" Lösung - wäre mir zumindest nicht bekannt.
Es gibt durchaus viele Informationen wie man die Auswirkungen von DoS Angriffen abmindern kann, z.B.
http://www.cert.org/tech_tips/denial_of_service.html http://www.dfn-cert.de/infoserv/dib/dib-2000-01.html ...
In der letzten iX gab es auch einen Artikel "Strategien gegen DDoS-Angriffe".
Worauf man achten sollte ist dass das System möglichst keine Fehler enthält, die einen DoS-Angriff erleichtern. Es gibt immer wieder Bugs im Kernel, in Webservern, in PHP, in allen möglichen Bibliotheken die es erlauben mit sehr viel weniger Aufwand das System zum Stillstand zu bekommen. Diese sollte man entsprechend also immer schnellst möglich beheben.
Je aufwändiger die "Aktion" ist, die ein Angreifer per Request auf dem Server auslöst, desto schneller ist das System am Ende. Z.B. hält ein Paketfilter der die Pakete des Angreifers direkt verwirft sehr viel mehr aus, als wenn die Requests z.B. auf sehr komplexe CGI-Scripte "durchkommen".
Auch kann man durch Konfiguration des Netzwerk-Stacks und des angegriffenen Dienstes die Folgen mindern, eben durch solche Sachen wie Timeouts herabsetzen, Begrenzungen für Anzahl Clients hochsetzen, SYN-Cookies... Man kann einige Pakete die auf dem Server eigentlich nicht vorkommen, und oft für irgendwelche Angriffe ausgenutzt werden in der Kernel-Konfiguration blocken, siehe z.B. http://www.gentoo.org/doc/de/gentoo-security.xml#doc_chap10 für ein paar Beispiele (das ist so oder so ein recht guter Artikel!).
Wie gesagt, einfache Angriffe von einer IP aus sind einfach per Paketfilter zu blocken, Angriffe über gespoofte IPs kann man AFAIR auch blocken.
Aber wie gesagt, diese Maßnahmen können alle lediglich die Auswirkungen mindern, wenn der Angreifer genügend Resourcen hat, kannst Du nichts dagegen machen. Ist allerdings fraglich ob Du so ein interessantes Ziel für solche Angriffe darstellst ;-)
Ach, so ein Angriff wie von Deinem Script lässt sich sehr leicht filtern ;-)
Also heißt das eine Firewall?
In dem Fall ja.
Nanu war ihr nicht immer die einhellige Meinung "man kennt doch seine laufenden Dienste auf der Maschine - warum ein Firewall".
Weil die meisten Leute denken, ein lokaler Paketfilter sei dazu da die Ports zu schließen die man nicht braucht, und die zu öffnen die man braucht. Dazu braucht man keinen Paketfilter. Das beste ist wenn der Provider schon in seinem Netz dafür sorgt dass Pakete des Angriffs erst gar nicht bis auf Deinen Server kommen, das ist aber nicht immer möglich. Zum Filtern sollte dann eine dedizierte Firewall zwischen Deinem Server und dem Internet dienen. Wenn man sowas nicht hat dann hilft auch noch der lokale Paketfilter, denn besser dieser filtert die Pakete des Angreifers, als dass der Apache sich so schnell verabschiedet wie Du es ja selber erlebt hast.
Auch die Dokumentation des apachen spricht sich in Hinblick auf den Nutzen für Keep-Alive und wegen alter druchgeschliffener C-Code gegen ein herabsetzen des Timeout aus.
Im Manual geht es ja auch nicht darum einen DoS abzuwehren!
Sind das alles nur auf der Watte -ein jeder benimmt sich so, wie der Zweck es vorhergesehen hat- gutgemeinte Ratschläge?
Nein, nur gelten bei der Abwehr von DoS andere Voraussetzungen als im Alltag.
Also bitte ich noch mals um Hilfe: Was an Sicherheit(ssoftware) braucht nun ein Server wirklich?
Der Server sollte halt gut gesichert sein (auf aktuellem Stand, sicher konfiguriert... der obige Gentoo-Artikel beschreibt da so einige Sachen), und wenn Du Dich dann gegen DoS-Angriffe wehren willst hast Du am besten eine Firewall zwischen Server und Internet, die es Dir erlaubt entsprechende Pakete zu filtern. Ich halte eine Firewall auch im Alltag für durchaus sinnvoll, z.B. um zu verhindern dass der Server Code nachläd wenn es einen Fehler in einem PHP-Script gibt... Zum Thema Firwall findest Du auch einen Abschnitt im oben verlinkten Gentoo Linux Sicherheitsleitfaden.
Grüße Andreas
--
SELFHTML Tipps & Tricks: http://aktuell.de.selfhtml.org/tippstricks/-
Hallo Andreas,
[ erste Antwort ] http://kris.koehntopp.de/artikel/webtune/ http://www.cert.org/tech_tips/denial_of_service.html http://www.dfn-cert.de/infoserv/dib/dib-2000-01.html
Die kannte ich noch nicht. Danke!
In der letzten iX gab es auch einen Artikel "Strategien gegen DDoS-Angriffe".
Werde ich mir raussuchen. Danke!
Da mangelt es an Zugriffsrechten. Mal sehen, ob ein Liebguck und eine Bitte hilft ;)
[...] Firewall In dem Fall ja. [...] Paketfilter [...]
Das Kapitel werde ich von Grund auf neu bewerten und testen, testen, testen... Danke für die Betrachtung!
An einem Satz bin ich allerdings klebengeblieben:
Ich halte eine Firewall auch im Alltag für durchaus sinnvoll, z.B. um zu verhindern dass der Server Code nachläd wenn es einen Fehler in einem PHP-Script gibt...
In welchem Bezug meinst Du hierbei das Nachladen von Code? (Das einzige, was mir dazu einfällt, wäre dabei ein Debbingsystem.)
Alles in allem von ganzem Herzen DANKE!
Gruß aus Berlin! eddi
-
Hi!
In welchem Bezug meinst Du hierbei das Nachladen von Code? (Das einzige, was mir dazu einfällt, wäre dabei ein Debbingsystem.)
Sehr viele Script-Kiddies versuchen über Schwachstellen im Code (so Sachen wie "include($_GET['file']);" oder "exec($_GET['cmd']);"...), eigenen Code aus dem Internet nachzuladen, der dann ausgeführt wird. Wenn man jetzt ausgehende Verbindungen entsprechend filtert funktioniert das nicht mehr, auch wenn irgendwo eine Lücke vorhanden sein sollte. Das ist zwar keine Lösung des Problems, aber IMHO durchaus sinnvoll wenn man nicht selber alle installierten Scripte kennt.
Grüße Andreas
--
SELFHTML Tipps & Tricks: http://aktuell.de.selfhtml.org/tippstricks/
-
-
-
-
-
-
-
-
-
-
Hallo,
um 1:40 habe ich dann den online-Server aus der Schußbahn wirder rausgenommen.
Die Logdateien sind leer, der Browser sendet nur ein Timeout, ps aux liefert seitenweise Kindprozesse des apachen...
Welche Logdateien? access_log? Wieviel hat der Server denn zu tun? Was sagt
topund evtl. auch mod_status?Status ist nicht eingebunden. top meldet dieses auf dem Testsystem:
top - 01:42:31 up 1 day, 20:15, 24 users, load average: 0.13, 0.08, 0.08 Tasks: 766 total, 1 running, 765 sleeping, 0 stopped, 0 zombie Cpu(s): 2.0% us, 2.3% sy, 0.0% ni, 94.1% id, 0.0% wa, 0.3% hi, 0.0% si Mem: 644412k total, 515472k used, 128940k free, 47236k buffers Swap: 1048816k total, 0k used, 1048816k free, 258552k cached
Der Browser hat kaum eine Chance auf http://127.0.0.1/ zuzugreifen. (Etwas 1/10 = (gesendeter Request)/Timeout)
Die Errorlogdatei ist dagegen voll von:
[info] server seems busy, (you may need to increase StartServers, ThreadsPerChild or Min/MaxSpareThreads), spawning 8 children, there are around 1 idle threads, and 20 total children
Das heißt Du hast sehr viele dieser Einträge? http://httpd.apache.org/docs-2.0/misc/perf-tuning.html#process
Leider habe ich feststellen müssen, das die einzelnen Serverprozesse im Betrieb allmählig größer wurden, deshalb habe ich die Begrenzung auch Hunderttausent Requests per Child gesetzt.
Soll man auf Keep-Alive verzichten und Timeout herabsetzen?
Bei PHP würde ich Keep-Alive abschalten, ja.
Warum?
Gibt es eine Faustformel nach Arbeitspeicher und CPUs wieviele Prozesse (in dem Fall Threads) der Apache maximal starten darf?
Das kommt drauf an wie groß die Prozesse sind (ist wegen shared memory aber nicht ganz einfach zu berechnen, siehe ggfs.: http://kris.koehntopp.de/artikel/webtune/)
Die derzeitige Testkonfiguration:
Apache 2.0.53 mit MPM worker auf Linux
> > ThreadLimit 610 > > ServerLimit 21 > > StartServers 2 > > MaxClients 600 > > MinSpareThreads 5 > > MaxSpareThreads 50 > > ThreadsPerChild 30 > > MaxRequestsPerChild 100000 > >Das sind soweit ich das sehe nicht die Standardwerte. Wie bist Du auf die gekommen?
Richtig, das ist kein Standart. Aus der highperformance.conf:
<IfModule worker.c> StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 </IfModule>
Die maximale Anzahl der Threads hatte ich damal mit top ermittelt und sie dann bei 610 festgesetz, somit ergeben sich zu den 21 an ServerLimit 30 ThreadsPerChild
Zu dem was Sven zum Worker-MPM zusammen mit PHP gesagt hat siehe: http://de3.php.net/manual/de/faq.installation.php#faq.installation.apache2
Das ist mir bekannt und es ist eine Testumgebung.
Vielleicht ist Deine Hardware einfach überfordert? Vielleicht hilft Dir in dem Fall auch der Feature Artikel von CK: http://aktuell.de.selfhtml.org/artikel/server/apachetuning/index.html
Auch den kenne ich und habe daher die Werte vergleichsweise hoch angesetzt.
Allgemein ist das Problem portierbar auf einen Apachen 1.3.x.
Gruß aus Berlin! eddi
-
Hi!
Bei PHP würde ich Keep-Alive abschalten, ja.
Warum?
Weil bei Keep-Alive ein Apache-Prozess solange der Keep-Alive Timeout nicht abläuft nichts anderes machen kann, und so nichts zu tun hat und sinnlos Speicher verschwendet. Und gerade bei so rechenintensiven Geschichten wie serverseitig interpretierten Scriptsprachen ist dieser Nachteil AFAIK größer als der Vorteil sich den TCP-Handshake zu sparen.
Grüße Andreas
--
SELFHTML Tipps & Tricks: http://aktuell.de.selfhtml.org/tippstricks/-
Re:
Weil bei Keep-Alive ein Apache-Prozess solange der Keep-Alive Timeout nicht abläuft nichts anderes machen kann, und so nichts zu tun hat und sinnlos Speicher verschwendet. Und gerade bei so rechenintensiven Geschichten wie serverseitig interpretierten Scriptsprachen ist dieser Nachteil AFAIK größer als der Vorteil sich den TCP-Handshake zu sparen.
Aha, Danke!
Gruß aus Berlin! eddi
-
-
-