Abo
  1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › Rasanter Aufstieg für Lighty

viel Interessanter: r/s

  1. Thema

Neues Thema Ansicht wechseln


  1. viel Interessanter: r/s

    Autor: Cemil- 02.04.07 - 10:49

    Wir verwenden Lighty auf einigen High-Traffic-Websites von Kunden, und handeln damit mehr als 200mio requests am Tag.

    Die zwei Fragen nun: Wieviele Requests gibt es im Internet ingesamt? Wieviele davon handelt lighty? Wir werdens nie erfahren :)

    Cemil Degirmenci

  2. Re: viel Interessanter: r/s

    Autor: Steve2 02.04.07 - 10:57

    Ja und was sagt das? Wieviel Requests Lighty bei Dir handelt, ist doch für sich alleine noch keine Aussage... vielleicht stecken da 200 Server dahinter, und ein Request dauert 3 Minuten ;-)

    Interessant wäre, ob er mit identischen Ressourcen mehr Requests (bei gleicher oder besserer Geschwindigkeit) schafft als z.B. Apache. Ich hab mal vor einiger Zeit primitive Messungen mit statischen Files gemacht, aber Lighty war auch nicht schneller als Apache2 mit Threading (worker).

    > Wir verwenden Lighty auf einigen
    > High-Traffic-Websites von Kunden, und handeln
    > damit mehr als 200mio requests am Tag.

  3. Re: viel Interessanter: r/s

    Autor: BSDDaemon 02.04.07 - 11:09

    Cemil- schrieb:
    -------------------------------------------------------
    > Wir verwenden Lighty auf einigen
    > High-Traffic-Websites von Kunden, und handeln
    > damit mehr als 200mio requests am Tag.
    >
    > Die zwei Fragen nun: Wieviele Requests gibt es im
    > Internet ingesamt? Wieviele davon handelt lighty?
    > Wir werdens nie erfahren :)

    Für solche Sachen eignet sich Lighty schon... macht YouTube für die Video Auslieferung auch iirc. Aber wer mehr braucht und sich mit dem Apachen gut auskennt ist da meist besser bedient. Neben Lighty gibt es ja noch andere recht sczhnelle httpd.



    ----------------------------------------
    Suum cuique per me uti atque frui licet.
    ----------------------------------------
    Ein Betriebssystem ist immer nur so gut und sicher
    wie der Administrator der es verwaltet.

    Wie gut der Administrator jedoch seine Fähigkeiten
    ausspielen kann, legt das Betriebssystem fest.

  4. Re: viel Interessanter: r/s

    Autor: heavy lighty user 02.04.07 - 11:19

    Steve2 schrieb:
    -------------------------------------------------------

    > Interessant wäre, ob er mit identischen Ressourcen
    > mehr Requests (bei gleicher oder besserer
    > Geschwindigkeit) schafft als z.B. Apache. Ich hab
    > mal vor einiger Zeit primitive Messungen mit
    > statischen Files gemacht, aber Lighty war auch
    > nicht schneller als Apache2 mit Threading
    > (worker).


    Das kann ich nicht bestätigen. Nach der Umstellung diverser WebServer (die zig tausend Besucher / Tag bedienen) auf den lighty, haben unsere Systeme trotz permanent steigender Besucherzahlen Langeweile.
    Mit Apache2 brauchten wir vorher vor Aufregung jedenfalls keinen Kaffee - die Last war Adrenalin pur ;)

  5. Re: viel Interessanter: r/s

    Autor: screne 02.04.07 - 11:23

    Cemil- schrieb:
    -------------------------------------------------------
    > Wir verwenden Lighty auf einigen
    > High-Traffic-Websites von Kunden, und handeln
    > damit mehr als 200mio requests am Tag.

    Ihr handelt mit Requests? Interessantes Geschäftsmodell.

  6. Re: viel Interessanter: r/s

    Autor: Netspy 02.04.07 - 11:43

    heavy lighty user schrieb:
    -------------------------------------------------------
    >
    > Mit Apache2 brauchten wir vorher vor Aufregung
    > jedenfalls keinen Kaffee - die Last war Adrenalin
    > pur ;)

    Apache2 ist so gut, wie man ihn konfiguriert.

  7. Re: viel Interessanter: r/s

    Autor: Depp 02.04.07 - 12:00

    Netspy schrieb:
    -------------------------------------------------------
    > Apache2 ist so gut, wie man ihn konfiguriert.

    Konfigurationsarbeit ist auch dringend noetig. Einen Apache (v1 und 2) in der Default-Config (bei den meisten Distris) kann man leicht "anhalten" (dafuer reicht schon eine ISDN-Leitung beim Angreifer, egal wie dick der Apache angebunden ist). Und selbst etwas aufgebohrte Apaches kann man immernoch recht leicht plattmachen...

    lighttpd ist da _deutlich_ Widerstandsfaehiger.


  8. Re: viel Interessanter: r/s

    Autor: Netspy 02.04.07 - 12:53

    Depp schrieb:
    -------------------------------------------------------
    >
    > Und selbst etwas aufgebohrte Apaches kann
    > man immernoch recht leicht plattmachen...
    >
    > lighttpd ist da _deutlich_ Widerstandsfaehiger.

    Und das kannst du sicherlich mit Fakten unterlegen.

  9. Re: viel Interessanter: r/s

    Autor: Depp 02.04.07 - 12:59

    Netspy schrieb:
    -------------------------------------------------------
    > Und das kannst du sicherlich mit Fakten
    > unterlegen.

    Liegt am Apache-Prozessmodell (ein Thread/Prozess pro fd). Default-Config von apache ist i.A. max 150 connections. Mach also 150 connections auf, und bring diese zum Stillstand, _bevor_ der Apache mit der Bearbeitung fertig ist. Dann steht das Ding, und das sogar, ohne viele Pakete auszutauschen.

    Übungsaufgabe: Nenne mind. zwei Wege, die Verbindungen vor dem kritischen Zeitpunkt anzuhalten.

    Ein aehnlicher Effekt, der dir vielleicht eher bekannt ist, kommt von "langsamen Clients". Lass mal ein paar tausend Modem-User grosse Dateien saugen...


  10. Re: viel Interessanter: r/s

    Autor: BSDDaemon 02.04.07 - 13:08

    Depp schrieb:
    -------------------------------------------------------
    > Liegt am Apache-Prozessmodell (ein Thread/Prozess
    > pro fd). Default-Config von apache ist i.A. max
    > 150 connections. Mach also 150 connections auf,
    > und bring diese zum Stillstand, _bevor_ der Apache
    > mit der Bearbeitung fertig ist. Dann steht das
    > Ding, und das sogar, ohne viele Pakete
    > auszutauschen.

    Timeouts einstellen
    Maximale Requests pro Verbindung einstellen
    Maximale Anforderungen pro Verbindung


    Ja, man muss Apache auch schon konfigurieren können was nicht sonderlich schwer ist.


    ----------------------------------------
    Suum cuique per me uti atque frui licet.
    ----------------------------------------
    Ein Betriebssystem ist immer nur so gut und sicher
    wie der Administrator der es verwaltet.

    Wie gut der Administrator jedoch seine Fähigkeiten
    ausspielen kann, legt das Betriebssystem fest.

  11. Re: viel Interessanter: r/s

    Autor: Depp 02.04.07 - 13:10

    BSDDaemon schrieb:
    -------------------------------------------------------
    > Timeouts einstellen

    Hilft nur bei den trivialen Angriffen.

    > Maximale Requests pro Verbindung einstellen

    Hilft nicht, da ein Request reicht.

    > Maximale Anforderungen pro Verbindung

    Ist das nicht das gleiche?

    > Ja, man muss Apache auch schon konfigurieren
    > können was nicht sonderlich schwer ist.

    Zu schwer.

  12. Re: viel Interessanter: r/s

    Autor: Depp 02.04.07 - 13:13

    Helfen koennte, die Zahl der Verbindungen pro Client-IP zu limitieren. Hat apache so eine Einstellung inzwischen?

  13. Re: viel Interessanter: r/s

    Autor: BSDDaemon 02.04.07 - 13:14

    Depp schrieb:
    -------------------------------------------------------
    > Hilft nur bei den trivialen Angriffen.

    Es ist ein weiterer Schritt zu einer besseren und zuverlässigeren Performance.

    > Hilft nicht, da ein Request reicht.

    Wie sollte ein Request reichen? Der httpd stört sich nicht an hängnden Requests.

    > Ist das nicht das gleiche?

    Nein.

    > Zu schwer.

    Vielleicht für DAUs, aber die haben ja auch nichts an einer httpd Konfiguration zu suchen. Oder siehst du das anders? Apache braucht mehr Konfiguration und da sind andere kleine httpd sicher schlanker, einfacher und schneller zuverlässig einsetzbar. Dennoch fehlt es diesen httpds deutlich an Umfang und Möglichkeiten weswegen sie in der Hinsicht keine Alternative zum Apachen darstellen. Den Apachen hingegen kann man so reduzieren und anpassen, dass sie auch kleine schnelle httpds wie Lighty ersetzen könne.

    ----------------------------------------
    Suum cuique per me uti atque frui licet.
    ----------------------------------------
    Ein Betriebssystem ist immer nur so gut und sicher
    wie der Administrator der es verwaltet.

    Wie gut der Administrator jedoch seine Fähigkeiten
    ausspielen kann, legt das Betriebssystem fest.

  14. Re: viel Interessanter: r/s

    Autor: Depp 02.04.07 - 13:18

    BSDDaemon schrieb:
    -------------------------------------------------------
    > Wie sollte ein Request reichen? Der httpd stört
    > sich nicht an hängnden Requests.

    Eben doch. Genau darauf basieren solche Angriffe. Ein hängender Request belegt einen Prozess oder Thread - und davon gibt es nur endlich viele.

    Bei lighttp kann ein Prozess mehrere Verbindungen behandeln, deswegen stoeren hier haengende Verbindungen deutlich weniger.

  15. Re: viel Interessanter: r/s

    Autor: BSDDaemon 02.04.07 - 13:23

    Depp schrieb:
    -------------------------------------------------------
    > Eben doch. Genau darauf basieren solche Angriffe.
    > Ein hängender Request belegt einen Prozess oder
    > Thread - und davon gibt es nur endlich viele.

    Es gibt aber nur x Requestspro Verbindung. Also ist schon ein verteilter DDoS nötig. Und da ist schon recht viel nötig um einen größeren httpd lahmzulegen.




    ----------------------------------------
    Suum cuique per me uti atque frui licet.
    ----------------------------------------
    Ein Betriebssystem ist immer nur so gut und sicher
    wie der Administrator der es verwaltet.

    Wie gut der Administrator jedoch seine Fähigkeiten
    ausspielen kann, legt das Betriebssystem fest.

  16. Re: viel Interessanter: r/s

    Autor: Depp 02.04.07 - 13:26

    BSDDaemon schrieb:
    -------------------------------------------------------
    > Es gibt aber nur x Requestspro Verbindung. Also
    > ist schon ein verteilter DDoS nötig. Und da ist
    > schon recht viel nötig um einen größeren httpd
    > lahmzulegen.

    Bin mir nicht ganz sicher, was du unter Verbindung verstehst. Alle mir bekannten Apaches erlauben mir, beliebig viele (TCP-)Verbindungen parallel aufzubauen. Ueber jede TCP-Verbindungn brauche ich nur einen einzigen Request zu schicken und diesen anhalten. Eine Begrenzung der Requests/TCP-Verbindung hilft offensichtlich nicht.

  17. WIR grasen IHREN traffic ab

    Autor: erh 02.04.07 - 20:03

    > Ihr handelt mit Requests? Interessantes
    > Geschäftsmodell.

    sie brauchen gute nutzerzahlen um hohe kosten für werbeflächen zu erreichen ?

    10mio requests pro woche sind kein problem für uns! ;)

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Dataport, Hamburg, Altenholz bei Kiel
  2. Deloitte, Berlin, Düsseldorf, Hamburg
  3. Landratsamt Reutlingen, Reutlingen
  4. Landratsamt Breisgau-Hochschwarzwald, Freiburg im Breisgau

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. For Honor für 11,50€, Anno 1404 Königsedition für 3,74€, Anno 2070 Königsedition...
  2. (aktuell u. a. Cryorig Gehäuselüfter ab 7,49€, Sandisk Ultra 400-GB-microSDXC für 59,90€)
  3. (u. a. Total war - Three Kingdoms für 35,99€, Command & Conquer - The Ultimate Collection für 4...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Transport Fever 2 angespielt: Wachstum ist doch nicht alles
Transport Fever 2 angespielt
Wachstum ist doch nicht alles

Wesentlich mehr Umfang, bessere Übersicht dank neuer Benutzerführung und eine Kampagne mit 18 Missionen: Das Schweizer Entwicklerstudio Urban Games hat Golem.de das Aufbauspiel Transport Fever 2 vorgestellt - bei einer Bahnfahrt.
Von Achim Fehrenbach

  1. Mordhau angespielt Die mit dem Schwertknauf zuschlagen
  2. Bus Simulator angespielt Zwischen Bodenschwelle und Haltestelle
  3. Bright Memory angespielt Brachialer PC-Shooter aus China

Endpoint Security: IT-Sicherheit ist ein Cocktail mit vielen Zutaten
Endpoint Security
IT-Sicherheit ist ein Cocktail mit vielen Zutaten

Tausende Geräte in hundert verschiedenen Modellen mit Dutzenden unterschiedlichen Betriebssystemen. Das ist in großen Unternehmen Alltag und stellt alle, die für die IT-Sicherheit zuständig sind, vor Herausforderungen.
Von Anna Biselli

  1. Datendiebstahl Kundendaten zahlreicher deutscher Firmen offen im Netz
  2. Metro & Dish Tisch-Reservierung auf Google übernehmen
  3. Identitätsdiebstahl SIM-Dieb kommt zehn Jahre in Haft

In eigener Sache: Golem.de bietet Seminar zu TLS an
In eigener Sache
Golem.de bietet Seminar zu TLS an

Der Verschlüsselungsexperte und Golem.de-Redakteur Hanno Böck gibt einen Workshop zum wichtigsten Verschlüsselungsprotokoll im Netz. Am 24. und 25. September klärt er Admins, Pentester und IT-Sicherheitsexperten in Berlin über Funktionsweisen und Gefahren von TLS auf.

  1. In eigener Sache ITler und Board kommen zusammen
  2. In eigener Sache Herbsttermin für den Kubernetes-Workshop steht
  3. Golem Akademie Golem.de startet Angebote zur beruflichen Weiterbildung

  1. Uber XL: Größere Autos für Uber in Berlin
    Uber XL
    Größere Autos für Uber in Berlin

    Uber hat einen neuen Dienst für Gruppenfahrten in Berlin gestartet. Für Uber XL werden größere Fahrzeuge mit mehr Sitzplätzen eingesetzt.

  2. Zulassung: Mehr neue Elektroautos in Deutschland als in Norwegen
    Zulassung
    Mehr neue Elektroautos in Deutschland als in Norwegen

    Norwegen gilt als Land mit den meisten Elektroauto- und Plugin-Hybrid-Neuzulassungen. Im ersten Halbjahr 2019 hat Deutschland Norwegen allerdings überholt. Der Marktanteil von E-Autos in Norwegen bleibt aber höher.

  3. SpaceX: Brennendes Titan verursachte Explosion des Dragon
    SpaceX
    Brennendes Titan verursachte Explosion des Dragon

    Überraschendes Ergebnis der Unfalluntersuchung von SpaceX: Bei der Explosion des Dragon-Raumschiffs im April 2019 ist ein Rückschlagventil aus Titan in Brand geraten, als die Treibstofftanks unter Druck gesetzt wurden. Zuvor galt das Metall zusammen mit dem Treibstoff als ungefährlich.


  1. 07:54

  2. 07:36

  3. 07:25

  4. 17:07

  5. 17:02

  6. 15:07

  7. 14:52

  8. 14:37