lighttpd Optimierung

Apache, Lighttpd, nginx, Cherokee
oezgueng
Posts: 14
Joined: 2005-08-15 18:00

lighttpd Optimierung

Post by oezgueng » 2008-02-11 09:33

Hallihallo,

falls jemand hier langeweile haben sollte, könnte jemand mir paar Tipps geben wie ich mein Lighttpd Server optimieren/verbessern könnte?

Hardware Details:
AMD Athlon64 3000+
1024 MB DDR-RAM
80 GB Festplatte
Debian 3.1 Sarge

Config:

Code: Select all

# Debian lighttpd configuration file
#

############ Options you really have to take care of ####################

## modules to load
# mod_access, mod_accesslog and mod_alias are loaded by default
# all other module should only be loaded if neccesary
# - saves some time
# - saves memory

server.modules              = (
           "mod_access",
           "mod_alias",
#      "mod_cgi",
           "mod_accesslog",
           "mod_rewrite",
           "mod_redirect",
           "mod_status",
#           "mod_evhost",
#           "mod_compress",
#           "mod_usertrack",
#      "mod_auth",
           "mod_rrdtool",
#           "mod_expire",
#      "mod_proxy",
#      "mod_secdownload",
      "mod_fastcgi"
#           "mod_flv_streaming",
#           "mod_evasive"
)

#flv-streaming.extensions = ( ".flv" )

## CGI ##
#cgi.assign = ( ".pl"  => "/usr/bin/perl",
#               ".cgi" => "/usr/bin/perl" )

## a static document-root, for virtual-hosting take look at the
## server.virtual-* options
server.document-root       = "/var/www-vhosts/www.myIT.org/"

## where to send error-messages to
#server.errorlog            = "/var/log/lighttpd/error.log"

## files to check for if .../ is requested
index-file.names           = ( "index.html",
                               "index.htm", "index.php" )


## Use the "Content-Type" extended attribute to obtain mime type if possible
#mimetype.use-xattr = "enable"

#### accesslog module
#accesslog.filename         = "/var/log/lighttpd/access.log"

## deny access the file-extensions
#
# ~    is for backupfiles from vi, emacs, joe, ...
# .inc is often used for code includes which should in general not be part
#      of the document-root
url.access-deny            = ( "~", ".inc" )



######### Options that are good to be but not neccesary to be changed #######

## bind to port (default: 80)
server.port               = 80

## bind to localhost only (default: all interfaces)
## server.bind                = "localhost"

## error-handler for status 404
#server.error-handler-404  = "/error-handler.html"
#server.error-handler-404  = "/error-handler.php"
#server.error-handler-500 = "http://www.404pay.de/script.php?ec=500&id=1842"
#server.error-handler-404 = "http://www.404pay.de/script.php?ec=404&id=1842"
#server.error-handler-403 = "http://www.404pay.de/script.php?ec=403&id=1842"

## to help the rc.scripts
server.pid-file            = "/var/run/lighttpd.pid"


auth.debug = 2
auth.backend = "plain"
auth.backend.plain.userfile = "/var/www-vhosts/.lighttpdpassword"


##
## Format: <errorfile-prefix><status>.html
## -> ..../status-404.html for 'File not found'
#server.errorfile-prefix    = "/var/www/"

## virtual directory listings
dir-listing.encoding        = "iso-8859-1"
server.dir-listing          = "enable"

## send unhandled HTTP-header headers to error-log
#debug.dump-unknown-headers  = "enable"

### only root can use these options
#
# chroot() to directory (default: no chroot() )
#server.chroot            = "/"

## change uid to <uid> (default: don't care)
server.username            = "oezgueng"

## change uid to <uid> (default: don't care)
server.groupname           = "users"

#### compress module
compress.cache-dir          = "/var/tmp/lighttpd/"
compress.filetype           = ("text/plain", "text/html", "text/javascript", "text/css", "text/xml")

#### status module
status.status-url = "/LIGHTTPD-server-status"
status.config-url = "/LIGHTTPD-server-config"

server.max-keep-alive-requests = 0
server.max-keep-alive-idle = 0
server.event-handler = "linux-sysepoll"
server.network-backend = "linux-sendfile"

#### url handling modules (rewrite, redirect, access)
# url.rewrite                 = ( "^/$"             => "/server-status" )
# url.rewrite = "^/phpmyadmin" => "/var/phpmyadmin" )
#url.redirect                = ( "^/joborange/(.+)" => "http://joborange.myIT.org/" )
#url.rewrite           = ( "^/phpmyadmin" => "/var/phpmyadmin" )

#
# define a pattern for the host url finding
# %% => % sign
# %0 => domain name + tld
# %1 => tld
# %2 => domain name without tld
# %3 => subdomain 1 name
# %4 => subdomain 2 name
#
# evhost.path-pattern = "/home/storage/dev/www/%3/htdocs/"

#### expire module
# expire.url                  = ( "/buggy/" => "access 2 hours", "/asdhas/" => "access plus 1 seconds 2 minutes")

#### rrdtool
rrdtool.binary = "/usr/bin/rrdtool"
rrdtool.db-name = "/rrdtool/lighttpd.rrd"


#### handle Debian Policy Manual, Section 11.5. urls
#### and by default allow them only from localhost

#$HTTP["remoteip"] =~ "127.0.0.1" {
#   alias.url += (
#      "/doc/" => "/usr/share/doc/",
#      "/images/" => "/usr/share/images/"
#   )
#   $HTTP["url"] =~ "^/doc/|^/images/" {
#      dir-listing.activate = "enable"
#   }
#}

#### variable usage:
## variable name without "." is auto prefixed by "var." and becomes "var.bar"
#bar = 1
#var.mystring = "foo"

## integer add
#bar += 1
## string concat, with integer cast as string, result: "www.foo1.com"
#server.name = "www." + mystring + var.bar + ".com"
## array merge
#index-file.names = (foo + ".php") + index-file.names
#index-file.names += (foo + ".php")

#mimetype.assign             = (".pdf"          =>      "application/pdf", )
include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"
include "include.conf"
include "vhost.conf"

fastcgi.server = ( ".php" => ( "localhost" => (
   "socket" => "/tmp/php-fastcgi.socket",
   "bin-path" => "/usr/bin/php5-cgi",
   "max-procs" => 10,
        "bin-environment" => (
            "PHP_FCGI_CHILDREN" => "10",
            "PHP_FCGI_MAX_REQUESTS" => "1000"
        )
   ,"broken-scriptfilename" => "enable"
 ) ) )


#
#$HTTP["referer"] =~ "^http://(www.)?(eBesucher.de)" {
#  url.redirect = ( ".*" => "http://www.google.com" )
#}
#proxy.server = ( "/ajaxterm" => ( ( "host" => "127.0.0.1", "port" => 8022 ) ) )

#alias.url = ( "/phpmyadmin/" => "/usr/share/phpmyadmin/")

User avatar
Joe User
Project Manager
Project Manager
Posts: 11138
Joined: 2003-02-27 01:00
Location: Hamburg

Re: lighttpd Optimierung

Post by Joe User » 2008-02-11 11:47

PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

twins
Posts: 13
Joined: 2008-02-12 15:05

Re: lighttpd Optimierung

Post by twins » 2008-02-13 12:34

Ich habe zu der Optimierung mal eine Frage, habe in der Lighttpd-Dokumentation zwar was gefunden, aber ich verstehe das nicht so ganz.

Bei mir sieht das FastCGI-Module so aus:

Code: Select all

fastcgi.server             = ( ".php" =>
                               ( "localhost" =>
                                 (
                                   "socket" => "/tmp/fcgi_tmp.socket",
                                   "bin-path" => "/usr/local/php5/bin/php-cgi"
                                 )
                               )
                            )

Ich habe jetzt aber mehrmals etwas von max_procs, min_procs, PHP_FCGI_CHILDREN und PHP_FCGI_MAX_REQUESTS gelesen. Was bedeuten diese "Variablen" und wie setze ich die richtig ein? Kann man die mit den Child-Prozessen von Apache vergleichen?
Die Doku sagt mir da nur "upper limit of processes to start", aber daraus wird mir nicht klar wie sich das auf die Performance oder Sicherheit auswirkt.

miker
Posts: 64
Joined: 2005-03-26 13:33
Location: Wildeshausen

Re: lighttpd Optimierung

Post by miker » 2008-02-13 18:59

max-procs definiert die Anzahl der PHP-Parent-Prozesse, die beim Start von Lighty mitgestartet werden. Diese Parentprozesse spawnen dann jeweils die in PHP_FCGI_CHILDREN angegebene Zahl an Childprozessen, die Anfragen beantworten.
Gibt es zu wenig Prozesse, stauen sich die Anfragen. Werden zuviel Prozesse gespawned, fressen die deinen RAM und der Server fängt an zu swappen. Beides doof!
Wieviele PHP-Prozesse es braucht, wird in der Doku behandelt: http://trac.lighttpd.net/trac/wiki/Docs%3APerformanceFastCGI#how-many-php-processes-do-i-need

oezgueng
Posts: 14
Joined: 2005-08-15 18:00

Re: lighttpd Optimierung

Post by oezgueng » 2008-02-13 19:15

Gibt es eigentlich eine Möglichkeit eine Maximale Anzahl von Prozesse anzugeben?
Sprich, wenn der Server ein hohe Last hat, dass es erstmal in den Idle-Modus geht?

miker
Posts: 64
Joined: 2005-03-26 13:33
Location: Wildeshausen

Re: lighttpd Optimierung

Post by miker » 2008-02-13 19:27

Mehr Prozesse als max-procs*(1 + PHP_FCGI_CHILDREN) werden nicht gespawned.

twins
Posts: 13
Joined: 2008-02-12 15:05

Re: lighttpd Optimierung

Post by twins » 2008-02-13 20:18

Ich habe da keine Definitionen gemacht und wie im Link beschrieben, taucht in meinen Logs auch kein Hinweis auf, dass sich die Anfragen in einer Warteschlange drängen.

Also am besten so lassen oder trotzdem Limits definieren? Habe RAM mind. 256 MB bis dynamisch 700.

miker
Posts: 64
Joined: 2005-03-26 13:33
Location: Wildeshausen

Re: lighttpd Optimierung

Post by miker » 2008-02-13 20:33

Wenn du keine Werte setzt, greifen die Defaultwerte (max-procs 4, PHP_FCGI_CHILDREN 1).

twins
Posts: 13
Joined: 2008-02-12 15:05

Re: lighttpd Optimierung

Post by twins » 2008-02-13 20:46

MikeR wrote:Wenn du keine Werte setzt, greifen die Defaultwerte (max-procs 4, PHP_FCGI_CHILDREN 1).

Das bedeutet ich habe 4 "Kernprozesse" mit jeweils 1 Child, der Request beantwortet? Zusammen 4 Prozesse für die Request... bedeutet das automatisch 4 Anfragen gleichzeitig und wenn es mehr werden, Warteschlange?

miker
Posts: 64
Joined: 2005-03-26 13:33
Location: Wildeshausen

Re: lighttpd Optimierung

Post by miker » 2008-02-13 21:05

Genau. Wenn 4 Anfragen reinkommen, hat jeder deiner Prozesse was zu tun. Kommen 5 rein, werden 4 Anfragen durchgereicht und eine Anfrage wartet in der Queue, bis der erste PHP-Prozess wieder frei ist.

twins
Posts: 13
Joined: 2008-02-12 15:05

Re: lighttpd Optimierung

Post by twins » 2008-02-13 21:09

Momentan ist der Seitenaufruf bei mir relativ schnell, habe allerdings noch mehr als genug RAM frei und etwas mehr als 5 Anfragen pro Sekunde.

Sollte ich jetzt lieber die "Kernprozesse" erhöhen oder die Childprozesse? Oder einfach die PHP_FCGI_MAX_REQUESTS, also die maximale Anzahl an beantworteten Request pro Child?

User avatar
Joe User
Project Manager
Project Manager
Posts: 11138
Joined: 2003-02-27 01:00
Location: Hamburg

Re: lighttpd Optimierung

Post by Joe User » 2008-02-13 21:17

Bei 5 req/s benötigst Du nur einen PHP-FCGI-Child keine 4...
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

miker
Posts: 64
Joined: 2005-03-26 13:33
Location: Wildeshausen

Re: lighttpd Optimierung

Post by miker » 2008-02-13 21:23

und etwas mehr als 5 Anfragen pro Sekunde.

Von Sekunden hab ich aber kein Wort verloren. Eine Sekunde Laufzeit ist schon ne ganze Menge Holz bei normalen PHP-Scripten. Zumindest ungefähr benchmarken kannst du das mit microtime(), um mal nen Richtwert zu bekommen, wie lange dein Script so werkelt.

Sollte ich jetzt lieber die "Kernprozesse" erhöhen oder die Childprozesse?

Also, when configuring lighty to manage php-fcgi processes, it is better to have more processes and less children than less processes and more children.

Wobei man durchaus mehr als ein Child pro Parentprozess starten darf. :wink:

PHP_FCGI_MAX_REQUESTS solltest du auf 500 setzen.

twins
Posts: 13
Joined: 2008-02-12 15:05

Re: lighttpd Optimierung

Post by twins » 2008-02-13 21:43

Also dann sieht die optimale Konfiguration so aus:
max-procs = 20
PHP_FCGI_CHILDREN = 10

Lieber mehr Prozesse und weniger Childs als umgekehrt... jedenfalls verstehe ich das so.

miker
Posts: 64
Joined: 2005-03-26 13:33
Location: Wildeshausen

Re: lighttpd Optimierung

Post by miker » 2008-02-13 21:56

Du hattest vorher 4 Childprozesse, jetzt sind es 200. Sicher, dass du so viele brauchst? (Zumal das insgesamt ca. 3GB an RAM fressen wird.)

Lies mal die beiden Abschnitte:
http://trac.lighttpd.net/trac/wiki/Docs%3APerformanceFastCGI#how-many-php-processes-do-i-need
http://trac.lighttpd.net/trac/wiki/Docs%3APerformanceFastCGI#can-i-have-too-many-php-processes

User avatar
Joe User
Project Manager
Project Manager
Posts: 11138
Joined: 2003-02-27 01:00
Location: Hamburg

Re: lighttpd Optimierung

Post by Joe User » 2008-02-13 22:19

Hallo? Er hat lächerliche 5req/s, dafür braucht er nur einen Parent mit einem Child. Die Lighty Doku bezieht sich auf High-Load-Systeme, nicht auf Systeme die vor sich hin idlen...
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

twins
Posts: 13
Joined: 2008-02-12 15:05

Re: lighttpd Optimierung

Post by twins » 2008-02-14 12:12

Ich werde meine Konfiguration mal so lassen, 4 Childprozesse sollten momenentan eigentlich reichen und wenn, dann ich nachhaltig noch was ändern.
MikeR wrote:PHP_FCGI_MAX_REQUESTS solltest du auf 500 setzen.

Was passiert eigentlich, wenn diese Anzahl überschritten wird?

Bei Apache ist es ja so, dass nach der Anzahl der max. Request der Child neu aufgeforkt wird.

braindead
Posts: 250
Joined: 2002-10-22 09:49
Location: vorm Rechner

Re: lighttpd Optimierung

Post by braindead » 2008-02-14 14:50

Bei Apache ist es ja so, dass nach der Anzahl der max. Request der Child neu aufgeforkt wird.


Es passiert genau das selbe.

twins
Posts: 13
Joined: 2008-02-12 15:05

Re: lighttpd Optimierung

Post by twins » 2008-02-14 15:30

Ah, vielen dank. Ich glaube jetzt hab ich alles verstanden. :-D