So leute habe mal geschaut wie es so aussieht mit dem Lighttpd da mit genug leute von dem vorschwärmen
Also hier mal ein kleiner Vergleichstest
Speed: Da nehmen sich Apache mit PHP Modul recht wenig wenn dann ist der Lighttpd ab und zu etwas schneller
RAM im leerlauf: der Apache hängt bei mir mit 12 Prozessen mit so je 2-3 MB im RAM der Lighttpd mit einem Prozess von 0.5MB in RAM
Benschmark: ab2 -n2000 -c100 $URL
Apache hat 120-130 REquest pro Sekunde geschaft mit einer unmenge an Prozessen
Lighttpd mit seinem einen Prozess und 4 php-cgi apps ca 140-150 Request pro sekunde geschaft
So nur mal für euch als kleine Info
www.lighttpd.net/
Lighttpd mit php über FastCGI
gepostet vor 18 Jahre, 9 Monate von woodworker
gepostet vor 18 Jahre, 9 Monate von mifritscher
Wobei man die Anzahl der Prozessen beim Apache festlegen kann
gepostet vor 18 Jahre, 9 Monate von woodworker
japp kann mann aber selbst wenn ich die auf einen runterstelle ist der eine immer noch mehr ram als der lighttpd
und bei request spawnen ja doch wieder ne menge apache's
und bei request spawnen ja doch wieder ne menge apache's
gepostet vor 18 Jahre, 9 Monate von Mudder
Wie sieht das mit der Kompatibilität von Plugins/Modulen für PHP und Co aus?
gepostet vor 18 Jahre, 9 Monate von Kampfhoernchen
Bis auf die Apache-Spezifischen Funktionen (logisch) habe ich noch keine Schwierigkeiten feststellen können. Und diese braucht man nicht wirklich.
gepostet vor 18 Jahre, 9 Monate von Kallisti
mod_gzip ?
mod_rewrite ?
mod_ssl ?
mod_perl ?
mod_rewrite ?
mod_ssl ?
mod_perl ?
gepostet vor 18 Jahre, 9 Monate von Chojin
Original von Kallisti
mod_gzip ?
mod_rewrite ?
mod_ssl ?
mod_perl ?
die ersten drei funktionen findest du nach 20 sekunden auf der webseite (featureliste). Ich hab langsam das gefühl, dass du ein bisschen faul wirst.
Ich kann irgendwie nicht recht glauben das dieses ding besser als ein solider apache sein soll. Ich finds zum beispiel gut das mir apache für jede usersession hunderte von variabeln automatisch zu verfügung stellt die ich einfach auslesen kann.
ich hör mal weiter gespannt zu, vieleicht gibt es ja einen sinvollen einsatz für diesen server. :roll:
reg4rds
chojin
gepostet vor 18 Jahre, 9 Monate von woodworker
Original von Kallisti
mod_gzip ?
mod_rewrite ?
mod_ssl ?
mod_perl ?
mod_compress !
mod_redirect !
lighttpd supports SSLv2 and SSLv3 if it is compiled against openssl.
kein mod_perl da ja auch kein mod_php
FastCGI ist doch auch im titel enthalten
Original von Chojin
ich hör mal weiter gespannt zu, vieleicht gibt es ja einen sinvollen einsatz für diesen server. :roll:
reg4rds
chojin
naja es geht ja beim lighttpd um speed/performance nicht um 12Millionen variablen die er zur verfügung stellt
aber das enhanced vhost modul ist schonmal super
und der ram verbrauch
wenn du aber natürlich nen quadxeon kiste mit 4GB ram hast wäre der lighttpd nen unützes brachliegen lassen an hardware
gepostet vor 18 Jahre, 9 Monate von schokofreak
2 Anmerkungen:
- CGi / FastCGI ermöglicht KEINE Prekompilierung von PHP Scripts. Dies resultiert je nach Scripts in immensem Aufwand
- Apache IST grottig langsam
Deshalb: Wieso nicht einen Webserver Marke eigenbau implementieren / Schnittstelle zu Apache PHP Modul implementieren?
Somit wäre es möglich, Precompiled zu arbeiten.
Mit dem Hinweis dass es mir vor 2 Jahren gelungen ist, einen Webserver zu entwickeln, welcher bis zu 10'000 Requests die Sekunde abarbeiten kann.
Gruss
- CGi / FastCGI ermöglicht KEINE Prekompilierung von PHP Scripts. Dies resultiert je nach Scripts in immensem Aufwand
- Apache IST grottig langsam
Deshalb: Wieso nicht einen Webserver Marke eigenbau implementieren / Schnittstelle zu Apache PHP Modul implementieren?
Somit wäre es möglich, Precompiled zu arbeiten.
Mit dem Hinweis dass es mir vor 2 Jahren gelungen ist, einen Webserver zu entwickeln, welcher bis zu 10'000 Requests die Sekunde abarbeiten kann.
Gruss
gepostet vor 18 Jahre, 9 Monate von woodworker
Original von schokofreak
2 Anmerkungen:
- CGi / FastCGI ermöglicht KEINE Prekompilierung von PHP Scripts. Dies resultiert je nach Scripts in immensem Aufwand
kann ich nicht sagen apc funzt super bei mir im cgi mode
hast du evtl ne quelle
gepostet vor 18 Jahre, 9 Monate von schokofreak
Löl? APC funzt?
Dann ist alles gut.
Funzt eigentlich PHP auch als FastCGI? Dann wär das ja n perfekter server?
Dann ist alles gut.
Funzt eigentlich PHP auch als FastCGI? Dann wär das ja n perfekter server?
gepostet vor 18 Jahre, 9 Monate von woodworker
Original von schokofreak
Löl? APC funzt?
Dann ist alles gut.
Funzt eigentlich PHP auch als FastCGI? Dann wär das ja n perfekter server?
bei mir in der phpinfo steht unter Server API: CGI/FastCGI
und die configure hat ne option mit namen --enable-fastcgi
und habe mir erstmal 3 vhosts angelegt mit php 5.1.1 5.1.2 und 4.4.2
kommt bald noch einer mit php-6.0.0-cvs hinzu
hab von nem kumpel nen gutes script[1] der x belibige php versionen unter /usr/local/php hinpackt - brauche da nur ein paar configure anweisungen hinzu tun
[1] http://pire-project.org/svn/lighttpd-tutorial/
gepostet vor 18 Jahre, 9 Monate von schokofreak
wow das ist ja hammer...
gepostet vor 18 Jahre, 9 Monate von Kallisti
Original von Chojin
Original von Kallisti
mod_gzip ?
mod_rewrite ?
mod_ssl ?
mod_perl ?
die ersten drei funktionen findest du nach 20 sekunden auf der webseite (featureliste). Ich hab langsam das gefühl, dass du ein bisschen faul wirst.
[...]
Stimmt :-) Wollte einfach mal ganz faul fragen ohne zu suchen.
gepostet vor 18 Jahre, 9 Monate von schokofreak
right, so hab ichs auch gemacht ;-)
gepostet vor 18 Jahre, 9 Monate von Sarge
weiß jemand ob lighttpd eine Connection limitierung auf Vhost ebene beherrscht? (wie z.b. mod_throttle beim apache o.ä.) .. ich hab nur eine bandwith beschränkung gefunden was mir aber nicht weiterhilft...
gepostet vor 18 Jahre, 9 Monate von woodworker
gepostet vor 18 Jahre, 9 Monate von The_Alien
Hm, hört sich soweit ja ganz gut an, habe mir auch mal die Seite etc angeschaut aber eine Frage hätte ich mal. Ist er schon ernsthaft einsetzbar oder gibt es noch Bedenken wegen Sicherheit / Stabilität. Und in wie weit ist der kompatibel was die php Scripte betrifft (was muß umgebaut werden).
Kann man den zum testen neben einem Apachen laufen lassen (zb anderer Port?).
Kann man den zum testen neben einem Apachen laufen lassen (zb anderer Port?).
gepostet vor 18 Jahre, 9 Monate von woodworker
Original von The_Alien
Hm, hört sich soweit ja ganz gut an, habe mir auch mal die Seite etc angeschaut aber eine Frage hätte ich mal. Ist er schon ernsthaft einsetzbar oder gibt es noch Bedenken wegen Sicherheit / Stabilität. Und in wie weit ist der kompatibel was die php Scripte betrifft (was muß umgebaut werden).
Kann man den zum testen neben einem Apachen laufen lassen (zb anderer Port?).
also neben dem apache auf nen anderen port ist ja wohl klar - webserver deren default port sich nicht ändern lassen würde kenne ich mal garkeinen
wenn du apache funktionen nutzt ist es halt ein problem weil die es nicht gibt
http://de.php.net/manual/en/ref.apache.php
bedenken gibts meiner seits keiner und die anderen 21000 die den einsetzen haben auch keine probleme
gepostet vor 18 Jahre, 9 Monate von MannaZ
Wir haben vor kurzem komplett auf lighttp umgestellt - mit Erfolg.
Nichtnur das der Server generell schneller läuft, wir haben auch weniger Probleme mit Confixx (da es ja wegfällt).
Wir haben zz aber noch eine Host-Connection zwischen lighttp und php, da das mit den Socets irgendwie nicht laufen will (hat einer eine Idee woran das liegen kann, bzw ähnliche probleme gehabt?).
...
Und in wie weit ist der kompatibel was die php Scripte betrifft (was muß umgebaut werden).
...
Ein paar sachen funktionieren nicht ganz. - wie die $_server['php_self'], ...
Nichtnur das der Server generell schneller läuft, wir haben auch weniger Probleme mit Confixx (da es ja wegfällt).
Wir haben zz aber noch eine Host-Connection zwischen lighttp und php, da das mit den Socets irgendwie nicht laufen will (hat einer eine Idee woran das liegen kann, bzw ähnliche probleme gehabt?).
Original von The_Alien
...
Und in wie weit ist der kompatibel was die php Scripte betrifft (was muß umgebaut werden).
...
Ein paar sachen funktionieren nicht ganz. - wie die $_server['php_self'], ...
gepostet vor 18 Jahre, 9 Monate von woodworker
Original von MannaZ
Ein paar sachen funktionieren nicht ganz. - wie die $_server['php_self'],...
nur wenn man falsch konfiguriert
http://www.lighttpd.net/documentation/fastcgi.html#configuring-php
gepostet vor 18 Jahre, 9 Monate von The_Alien
Habe auf beiden Servern mal Lighttpd testweise auf Port 81 laufen und läuft bis jetzt mal ohne Fehler. Wenn nichts gravierendes auftaucht werde ich am Wochenende den Apache abschalten und nur noch Lighttpd laufen lassen. Dann kann ich auch was zu der Performance sagen.
Aber ich muß sagen das ich den Lighttpd schonmal alleine vom configurieren um einiges besser&einfacher finde. Danke schonmal für den Tipp
Aber ich muß sagen das ich den Lighttpd schonmal alleine vom configurieren um einiges besser&einfacher finde. Danke schonmal für den Tipp
gepostet vor 18 Jahre, 9 Monate von Nuky
ja, bitte. wär sehr gespannt ob das auch bei rein dynamischen seiten nen guten vorteil bringt..
@alien: hast du eAccelerator laufen? Schon oder?
@alien: hast du eAccelerator laufen? Schon oder?
gepostet vor 18 Jahre, 9 Monate von woodworker
Original von Nuky
ja, bitte. wär sehr gespannt ob das auch bei rein dynamischen seiten nen guten vorteil bringt..
@alien: hast du eAccelerator laufen? Schon oder?
eAccelerator finde ich nicht mehr so toll - ich nutze nur noch APC
gepostet vor 18 Jahre, 9 Monate von Sarge
nachdem eaccelerator ein paar mal mist gebaut hat bei uns läuft auch nurnoch apc ... allerdings verschluckt der sich auch manchmal bei fileupdates.. aber ansonsten keine beschwerden anzumelden bei apc
gepostet vor 18 Jahre, 9 Monate von Kallisti
Habe mit dem Umstieg von php 4.4.2 mit eAccelerator auf 5.1 mit APC auch merkliche Geschwindigkeitsverbesserungen festgestellt. Allerdings doch noch auf Apache Basis.
Nochmal eine Frage ohne selbst nachgelesen zu haben: Wie sieht es bei dem lighweightdingens hier mit vhosts und entsprechender Recheverwaltung aus? Also dass ich ueber z.B. syscp meien Hosts konfiguriere und jeder User ein virtueller User in einer mysql tabelle ist, der dann mit nss dem System vorgegaukelt wird. PHP Scripts sollten natuerlich immer nur mit den Rechten des jeweiligen Users im jeweiligen vhost laufen, inkl. open basedir und safemode.
Ist das moeglich?
Nochmal eine Frage ohne selbst nachgelesen zu haben: Wie sieht es bei dem lighweightdingens hier mit vhosts und entsprechender Recheverwaltung aus? Also dass ich ueber z.B. syscp meien Hosts konfiguriere und jeder User ein virtueller User in einer mysql tabelle ist, der dann mit nss dem System vorgegaukelt wird. PHP Scripts sollten natuerlich immer nur mit den Rechten des jeweiligen Users im jeweiligen vhost laufen, inkl. open basedir und safemode.
Ist das moeglich?
gepostet vor 18 Jahre, 9 Monate von Nuky
is 5.1 zu 4.x vollkommen kompatibel oder hattet ihr gravierende umstell-probleme?
hab derzeit 4.3 mit eAccelerator laufen, hab eig. keine probleme - lohnt sich der umstieg (auch im bezug auf never change a running system?)
hab derzeit 4.3 mit eAccelerator laufen, hab eig. keine probleme - lohnt sich der umstieg (auch im bezug auf never change a running system?)
gepostet vor 18 Jahre, 9 Monate von Kallisti
Kommt auf deine Scripts an. :-) Squirrelmail hat 2-3 Probleme nach der Umstellung, ist aber noch nutzbar (moechte es nicht manuell updaten, warte aufs debian paket). Mein Browsergame liess sich problemlos migrieren. Ich musste absolut gar nichts aendern.
Auf der PHP Webseite gibt es detaillierte Infos was man beruecksichtigen sollte, passt aber nun auch nicht mehr so ganz hier rein.
Auf der PHP Webseite gibt es detaillierte Infos was man beruecksichtigen sollte, passt aber nun auch nicht mehr so ganz hier rein.
gepostet vor 18 Jahre, 9 Monate von Nuky
womit meine hauptfrage net beantwortet wäte - die auch mehr zum thema passt - gibt das nochn irgendwie merkbaren geschwindigkeitsunterschied?
gepostet vor 18 Jahre, 9 Monate von woodworker
Original von Kallisti
Habe mit dem Umstieg von php 4.4.2 mit eAccelerator auf 5.1 mit APC auch merkliche Geschwindigkeitsverbesserungen festgestellt. Allerdings doch noch auf Apache Basis.
Nochmal eine Frage ohne selbst nachgelesen zu haben: Wie sieht es bei dem lighweightdingens hier mit vhosts und entsprechender Recheverwaltung aus? Also dass ich ueber z.B. syscp meien Hosts konfiguriere und jeder User ein virtueller User in einer mysql tabelle ist, der dann mit nss dem System vorgegaukelt wird. PHP Scripts sollten natuerlich immer nur mit den Rechten des jeweiligen Users im jeweiligen vhost laufen, inkl. open basedir und safemode.
Ist das moeglich?
1. k.a. ob syscp mit lighttpd klar kommt
2. wenn dir lighttpd zu schwer ist lighty ist der offizielle kosename
3. ja es geht mit dem userrechten für php
4. da ja jedes php mit eigenem user läuft lass safemode aus das ist nur ne flag die für dumme admins eingebaut wurde und eingtlich nicht wirklich was besser macht und eher die armen user nervt.
http://pire-project.org/svn/lighttpd-tutorial/default/bin/fcgi.sh <- da nen shellscript um php unter eigenem usernamen laufen zu lassen
http://pire-project.org/svn/lighttpd-tutorial/default/lighttpd.conf <- da ne default vhost template
@nuky also es gibt scripte die sind 100% unter php4 und php5 lauffähig, aber es gibt auch grosse sachen wie z.B. ezPublish die funktionierne nur unter php4. da ist immer testen angesagt. kannst dir ja aber erstmal nen testvhost anlegen der php5 am laufen hat. und die selbe documentroot hat wie dein "normaler" php4 vhost.
gepostet vor 18 Jahre, 9 Monate von exception
Der benötigte Rechenaufwand setzt sich ja grob zusammen aus:
1. PHP-kompilieren bzw. aus Cache holen (APC, eaccelerator)
2. PHP- init/exit Overhead
3. Ausführung des PHP-Scripts
4. Webserver init/exit Overhead
Die Ausführung des PHP-Scripts dürfte wohl bei allen Browsergames den größten Rechenaufwand verursachen.
Durch einen Wechsel des Webservers kann lediglich 4. und evtl. 2. optimiert werden. Reicht das aus um signifikante Performance-Unterschiede zu erzeugen?
Andererseits könnten durch einen anderen Webserver der Speicherbedarf sinken und somit vor allem auf Systemen mit wenig RAM auch die anderen 3 Phasen beschleunigt werden.
Von daher würden mich mal interessieren, wieweit sich das ganze bei einem Browsergame praktisch auswirkt.
1. PHP-kompilieren bzw. aus Cache holen (APC, eaccelerator)
2. PHP- init/exit Overhead
3. Ausführung des PHP-Scripts
4. Webserver init/exit Overhead
Die Ausführung des PHP-Scripts dürfte wohl bei allen Browsergames den größten Rechenaufwand verursachen.
Durch einen Wechsel des Webservers kann lediglich 4. und evtl. 2. optimiert werden. Reicht das aus um signifikante Performance-Unterschiede zu erzeugen?
Andererseits könnten durch einen anderen Webserver der Speicherbedarf sinken und somit vor allem auf Systemen mit wenig RAM auch die anderen 3 Phasen beschleunigt werden.
Von daher würden mich mal interessieren, wieweit sich das ganze bei einem Browsergame praktisch auswirkt.
gepostet vor 18 Jahre, 9 Monate von woodworker
ja php init exit overhead verschwindet ausm request das php ja als fcgi läuft also presistente bins im hintergrund
genau wie beim apache mit mod_php (ok da ist php im apache drine)
apache ist aber recht gross und von dem mal eben nen neuen prozess spawnen dauert da etwas länger als beim lighttpd
aber der spawnt halt mal eben nur ne neue php-cgi und keinen kompletten lighttpd prozess oder der apache halt nen apache prozess
desweiteren sind sachen wie statisches ausliefern von bildern oder css beim lighty auch etwas schneller und ram effizienter
also ist der vorteil zum apache auf jedenfall wie anfangs erwähnt schonmal der sehr geringe ram bedarf
genau wie beim apache mit mod_php (ok da ist php im apache drine)
apache ist aber recht gross und von dem mal eben nen neuen prozess spawnen dauert da etwas länger als beim lighttpd
aber der spawnt halt mal eben nur ne neue php-cgi und keinen kompletten lighttpd prozess oder der apache halt nen apache prozess
desweiteren sind sachen wie statisches ausliefern von bildern oder css beim lighty auch etwas schneller und ram effizienter
also ist der vorteil zum apache auf jedenfall wie anfangs erwähnt schonmal der sehr geringe ram bedarf