Startseite
  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche
Startseite › Forum › Drupalcenter.de › Tipps & Tricks ›

Server entlasten mit lighttpd

Eingetragen von Alexander Langer (3416)
am 08.02.2008 - 12:24 Uhr in
  • Tipps & Tricks

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 ;)

‹ Service Links Modul für Deutsche Bookmark Services: Yigg, Taggle, Mister Wong, Linkarena Drupal auf USB Stick - funktioniert ›
  • Anmelden oder Registrieren um Kommentare zu schreiben

Vorsicht mit lighttpd.

Eingetragen von Paradise (29)
am 09.02.2008 - 07: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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Wer spricht and dieser

Eingetragen von Alexander Langer (3416)
am 09.02.2008 - 13: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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Ich verwende den "lighttpd"

Eingetragen von grandcat (83)
am 09.02.2008 - 13: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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Sollte ja nur ein hinweiß

Eingetragen von Paradise (29)
am 10.02.2008 - 11: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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Clean-URLs mit lighttpd. So geht's:

Eingetragen von guidot@drupal.org (13)
am 28.05.2008 - 17: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-magnet

EDIT: Das ist übrigens für ein reines lighty-Setup. Kein Indianer auf der Kiste nötig.

  • Anmelden oder Registrieren um Kommentare zu schreiben

grandcat schrieb Ich

Eingetragen von ratdog (17)
am 29.05.2008 - 14:16 Uhr
grandcat schrieb

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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Hallo ich setze auch den

Eingetragen von bennos (32)
am 29.05.2008 - 19: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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Benutzeranmeldung

  • Registrieren
  • Neues Passwort anfordern

Aktive Forenthemen

  • Probleme mit der darstellun der ogg:image Tags.
  • Hi!
  • [gelöst]Abhängigkeiten zweier oder mehrerer Inhaltstypen
  • Lokale Entwicklungsumgebung auf Windows
  • Drupalcenter tot?
  • Drupal-Forks und ihre Schwächen/Stärken
  • Was kann ich gegen ständige Blutergüsse tun?
  • Mir gefällt die Drupal Symfony und deren Composer
  • Mir ist da was aufgefallen ;)
  • Matomo Installation
  • Verständnisfrage private_files in Drupal
  • [gelöst] Drupal 7 Forum Beitrag mit Bilder einstellen
Weiter

Neue Kommentare

  • Kontextfilter und Relationen sind der richtige Ansatz
    vor 15 Stunden 34 Minuten
  • Zusatzfragen
    vor 1 Tag 16 Stunden
  • DDEV verwaltet Container, sowohl Docker als auch andere
    vor 1 Tag 17 Stunden
  • Entwicklungsumgebung ist nicht nur Server
    vor 1 Tag 17 Stunden
  • Danke
    vor 3 Tagen 10 Minuten
  • [gelöst] Danke!
    vor 3 Tagen 15 Minuten
  • Ja natürlich tun wir dass.
    vor 3 Tagen 18 Stunden
  • Drupal.de verweist aufs Drupal Center
    vor 3 Tagen 20 Stunden
  • Und falls du auf grüne
    vor 3 Tagen 20 Stunden
  • Danke euch beiden, das bringt
    vor 3 Tagen 20 Stunden

Statistik

Beiträge im Forum: 250047
Registrierte User: 20363

Neue User:

  • LilliNELP
  • Wavermype
  • Shify

» Alle User anzeigen

User nach Punkten sortiert:
wla9456
stBorchert6003
quiptime4972
Tobias Bähr4019
bv3924
ronald3855
md3717
Thoor3678
Alexander Langer3416
Exterior2903
» User nach Punkten
Zur Zeit sind 1 Benutzer und 10 Gäste online.

Benutzer online

  • SportSaarlandToday

Hauptmenü

  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche

Quicklinks I

  • Infos
  • Drupal Showcase
  • Installation
  • Update
  • Forum
  • Team
  • Verhaltensregeln

Quicklinks II

  • Drupal Jobs
  • FAQ
  • Drupal-Kochbuch
  • Best Practice - Drupal Sites - Guidelines
  • Drupal How To's

Quicklinks III

  • Tipps & Tricks
  • Drupal Theme System
  • Theme Handbuch
  • Leitfaden zur Entwicklung von Modulen

RSS & Twitter

  • Drupal Planet deutsch
  • RSS Feed News
  • RSS Feed Planet
  • Twitter Drupalcenter
Drupalcenter Team | Impressum & Datenschutz | Kontakt
Angetrieben von Drupal | Drupal is a registered trademark of Dries Buytaert.
Drupal Initiative - Drupal Association