Server entlasten mit lighttpd
Eingetragen von Alexander Langer (3416)am 08.02.2008 - 11:24 Uhr in
Wer einen Root-Server (dediziert oder virtualisiert) sein Eigen nennt und etwas mehr Performance gebrauchen könnte, für den könnte folgendes Tutorial ein passendes Puzzlestück sein:
Reduce Apache's Load With lighttpd On Debian Etch
Eine evtl. Anpassung an andere Distributionen dürfte simpel sein. Für Drupal drängt sich der files-Ordner bei Verwendung der öffentlichen Download-Methode von Drupal geradezu auf, um sich über lighttpd verarzten zu lassen.
Da wir derzeit auf keinem Server Performance-Engpässe haben, spare ich mir das Ausprobieren erstmal noch auf ;)
- Anmelden oder Registrieren um Kommentare zu schreiben
Vorsicht mit lighttpd.
am 09.02.2008 - 06:29 Uhr
Vorsicht mit lighttpd. Schnell und gut, aber wer sich nicht wirklich mit mod_rewrite Regeln selber schreiben auskennt hat ein Problem.
Ich habe mich 2 Wochen damit rumgeärgert und bin heavy-hearted back to apache.
Wer mod_rewrite per htaccess braucht hat es schwer. Kaum hilfe dort und sieht aus als wäre lighty am sterben.
Das Forum besteht nur noch aus Porn-Spam...
________________
To The Extreme
Wer spricht and dieser
am 09.02.2008 - 12:40 Uhr
Wer spricht and dieser Stelle von mod_rewrite?
Ist ziemlich schwer etwas sterben zu lassen, dass eine 1.5 Mio Installationsbasis vorzuweisen hat, mit einigen sehr prominenten Namen. Dass lightys Jungs da kein großes Tamtam machen und ihre Freieit in Code statt in Foren investieren, gestehe ich jedem zu.
--
"Look, Ma, I'm dead!"
Cell, Stephen King
Ich verwende den "lighttpd"
am 09.02.2008 - 12:42 Uhr
Ich verwende den "lighttpd" schon seit einem halben Jahr produktiv, ist echt wahnsinnig schnell, sowohl bei dynamischen, aber insbesondere bei statischen Inhalten sehr gut zu gebrauchen. Allerdings stockt momentan etwas die Weiterentwicklung, was ich persönlich etwas schade finde. Aber dies ist sicherlich nicht das Ende des schnellen HTTP-Servers.
Die Rewrite-Rules sind in der Tat etwas gewöhnungsbedürftig, allerdings gibt es bereits einige Rewrite-Rules im Internet für Drupal + Lighttpd. Also sollte dies auch kein Problem mehr darstellen =D
-------------------------------------
Meine Entwicklungen:
www.minis-kuemmersbruck.de | www.hausmeisterteam-glaser.de
Sollte ja nur ein hinweiß
am 10.02.2008 - 10:59 Uhr
Sollte ja nur ein hinweiß sein sich genau zu überlegen was man braucht. Wer auf htaccess und SEF-Urls verzichten kann, für den ist lighty super.
Ich wäre gerne bei lighty geblieben, aber ich brauche regeln die es in lighty leiter nicht gibt. Und lua war mir auch zu umständlich.
Clean-URLs mit lighttpd. So geht's:
am 28.05.2008 - 16:38 Uhr
Clean-URLs sind mit lighty seit 1.4.19 kein Problem.
Einige Drupal-spezifische Einstellungen in der lighttpd.conf:
# necessary for rewriting URLs
server.modules += ( "mod_magnet" )
# deny access for several file-extensions
url.access-deny = (
"~", ".engine", ".inc", ".info", ".install", ".module", ".profile", ".po", ".sh",
"sql", ".theme", ".tpl.php", ".xtmpl", "code-style.pl", "Entries", "Repository",
"Root", "Tag", "Template"
)
# we need only this
index-file.names = ( "index.php" )
# Drupal does the error handling
server.error-handler-404 = "/index.php"
# for clean urls
magnet.attract-physical-path-to = ( "/etc/lighttpd/drupal-rewrite.lua" )
Für Clean-URLs sind der erste (server.modules) und letzte Eintrag (magnet.attract-physical-path-to) zuständig. Mit url.access-deny lässt sich die Apache-FilesMatch-Regel in der .htaccess ersetzen.
Hier die drupal-rewrite.lua:
-- little helper function
function file_exists(path)
local attr = lighty.stat(path)
if (attr) then
return true
else
return false
end
end
function removePrefix(str, prefix)
return str:sub(1,#prefix+1) == prefix.."/" and str:sub(#prefix+2)
end
-- prefix without the trailing slash
local prefix = ''
-- the magic ;)
if (not file_exists(lighty.env["physical.path"])) then
-- file still missing. pass it to the fastcgi backend
request_uri = removePrefix(lighty.env["uri.path"], prefix)
if request_uri then
lighty.env["uri.path"] = prefix .. "/index.php"
local uriquery = lighty.env["uri.query"] or ""
lighty.env["uri.query"] = uriquery .. (uriquery ~= "" and "&" or "") .. "q=" .. request_uri
lighty.env["physical.rel-path"] = lighty.env["uri.path"]
lighty.env["request.orig-uri"] = lighty.env["request.uri"]
lighty.env["physical.path"] = lighty.env["physical.doc-root"] .. lighty.env["physical.rel-path"]
end
end
-- fallthrough will put it back into the lighty request loop
-- that means we get the 304 handling for free. ;)
Für alle Debianer: lighttpd 1.4.19 ist mittlerweile auch bei Etch angekommen. Selbermachen nicht mehr nötig. Das Magnet-Modul ist aber ein eigenes Paket, also:
server:~# aptitude install lighttpd lighttpd-mod-magnetEDIT: Das ist übrigens für ein reines lighty-Setup. Kein Indianer auf der Kiste nötig.
grandcat schrieb Ich
am 29.05.2008 - 13:16 Uhr
Ich verwende den "lighttpd" schon seit einem halben Jahr produktiv, ist echt wahnsinnig schnell, sowohl bei dynamischen, aber insbesondere bei statischen Inhalten sehr gut zu gebrauchen. Allerdings stockt momentan etwas die Weiterentwicklung, was ich persönlich etwas schade finde. Aber dies ist sicherlich nicht das Ende des schnellen HTTP-Servers.
Über was Schreiben wir hier? Geht es um einen Pentium III Server der entlastet werden soll oder um einen Dual Core? Wieviel Seiten sollen pro Sekunde ausgeliefert werden? Wenn es ein Dual Core wäre, dann ist die Absicht des TO nur dann sinnvoll wenn die zu bewältigende Arbeit in Spitzenzeiten etwa in der Grössenordnung von etwa 1000 Aufrufen/Sekunde liegt und das über Stunden. Wenn es nur 300 oder 400 wären (auch über Stunden), dann grinst sich der Dual Core bei der Auslieferung über einen Apachen noch einen ab.
Bevor ich so etwas anfange würde ich über load balancing nachdenken. Hier gibt es ja bereits jede Menge sehr gute Tutorials im www. Ich würde auch keinen lighttpd nehmen sondern einen zweiten Apachen, selbst wenn der Resourcenbedarf höher ist. Der lighttpd hat die Angewohnheit - gelegentlich - Selbstmord zu begehen. Das passiert bei einem Apachen nicht, der seine Anfragen parallel abarbeiten kann.
Alternativ würde ich nginx vorschlagen.
Hallo ich setze auch den
am 29.05.2008 - 18:07 Uhr
Hallo
ich setze auch den Lighty produktiv ein.
Die Lua Lösung für rewrite habe ich lange gesucht und auch umgesetzt.
Mit Debian Etch, Lighty,PHP 5.2.5, MySQL 5, und Memcache rennt Drupal richtig auch auf einen Virtuellen Servern.
Loadbalancing brauche ich zwar nicht, habe es aber trotzdem mal ausprobiert und auf einem 2. Vserver PHP als CGI und Memcache laufen lassen. Die Konfig ist ganz easy. Über die Last kann ich nicht viel sagen, das ich täglich nur 1000 Benutzer habe.
Auf jeden Fall ist die Lösung mit dem Lighty für kleine Budgets die ideale Lösung.