Squid - Sinnvoll?

Ben.

Registered User
Hallo,

Ich spiele derzeit mit dem Gedanken den ein oder anderen Server mit deinem Squid-Proxy zu unterstützen. Ziel ist es dabei, die Unmengen an RAM besser auszunutzen.

Ich habe ein Tool namens ViCompress auf 32Bit-Systemen eingesetzt, auf 64Bit kompiliert es leider nicht (auch nicht mit Hilfe des Supports).

Nun habe ich mir überlegt Squid einzusetzen, habe allerdings mit Squid nur sehr wenig Erfahrung. Daher würde ich gerne von den erfahreneren Nutzern wissen, die Squid selbst im Einsatz haben/hatten, ob es Sinn macht, auf ein und derselben Maschine Squid vor einen Webserver zu schalten mit dem Ziel der Performance der Seiten zu verbessern.

Macht es Sinn oder nicht?

Falls ja, hat jemand ein wirklich einfaches Beispiel zur Hand, mit dem man den Accelerator-Mode testen kann? Die Beispielskonfigurationen die ich finden konnte laufen nicht, und bevor ich mich auf die Doku stürze, möchte ich ein paar Tests machen.

Wäre super wenn ihr mir da was zu sagen könntet.

Besten Dank,
Ben.
 
Der Squid ist typischerweise kein Reverse-Proxy (ich weiß jetzt grad nicht ob der sowas überhaupt kann) und selbst wenn was soll es bringen?
Loadbalance auf einen Server dahinter oder als Cache?

Das Loadbalancing ist wohl recht sinnbefreit und Caching Funktionen/Module gibts auch für die diversen Webserver genug.

Mag auch sein, dass ich dein Problem nicht richtig verstehe. Aber auf den ersten Blick scheint es nicht sinnvoll zu sein, da ein Squid dazwischen zu hängen. :)
 
Ja, das hab ich mir schon gedacht. Es macht wohl erst Sinn, wenn ich mehrere Server mit in den Verbund nehme.

Danke für deine Einschätzung, vermutlich musste ich es nur von jemandem hören :)
 
@Whistler: Die Sinnhaftigkeit ist aber dennoch nicht gegeben, oder wie sind deine Erfahrungswerte?
 
Das häng sehr von Deiner Web-Applikation ab.

Ein Caching Proxy macht vor allem dann Sinn, wenn der Content sonst jedesmal neu generiert würde - beispielsweise bei einem CMS, einem Wiki oder einem Forum.
Hier kann er einen extremen Unterschied machen, wenn er hilft hunderte SQL-Anfragen pro Seitenaufbau einzusparen.

Besser ist es alledings, dieses Caching die Applikation machen zu lassen. So generiert z.B. das SSF die Liste der neuesten Beiträge nicht bei jedem Aufruf, sondern nur ab einem bestimmten Alter der letzten Abfrage. Auch für andere "Problemkandidaten" wie z.B. Wordpress oder Zope gibt es passende Module.

Bei rein statischen Seiten auf derselben Maschine bringt ein Reverse Proxy gar nix - u.U. wird es sogar langsamer.
 
Konkret geht es um die Performanceverbesserung eines VBulletin-Forums. Ich hab mir VBulletin nicht soviel Erfahrung.

Die Performance ist nicht schlecht, aber ich möchte einfach das Maximale aus dem Teil rausholen, da im Winter die Besucherzahlen stark ansteigen werden.
 
Hallo Ben.!
Dann berichte doch mal, wie momentan die Hard- und Softwarekonfiguration aussieht. Welche Maßnahmen hast du bereits zur Performancesteigerung umgesetzt?

mfG
Thorsten
 
lighttpd läuft in Verbindung mit PHP 5.2.11 (FastCGI) und eAccelerator auf einem FreeBSD 7.2-p3.

mod_cache und mod_compress sind aktiviert (noch paar andere, aber die tragen weniger zur Performance bei).

mySQL dient als Datenbankbackend, welches auch performant läuft.

Das Hostsystem ist ein QuadCore mit 12GB RAM und 2x1.5 TB Festplatte (RAID1).

CPU-Auslastung und RAM-Auslastung ist im grünen Bereich, der RAM-Verbrauch könnte höher sein, aber ich taste mich da noch bissl vor um nix zu riskieren. Downtime ist sehr kritisch.

Ein Problem ist, dass die Startseite recht viele Grafiken enthält und das Template an sich nicht sonderlich optimiert ist (zuviele CSS/JS-Files etc.). Darauf habe ich allerdings keinen Einfluss. Ich kann nur das beste aus dem System rausholen.

In VBulletin ist eAccelerator als Cache-Engine aktiviert.

Hast du Vorschläge was ich noch tun könnte? Uns wird nur ein System zur Verfügung gestellt, für mehr wird kein Budget bewilligt, allerdings ist das im Moment auch nicht nötig.
 
Hallo!
Das ist ja schon eine ganze Menge! Mit wie vielen (simultanen) Benutzern rechnest du? Hast du dir bereits Gedanken zum kommenden vBulletin 4.0 gemacht?

Gibt es einen speziellen Grund, warum du eAccelerator einsetzt. Vom vBulletin Staff wird immer APC empfohlen und bevorzugt. Sind performancelastige Dinge wie vBSEO im Einsatz? Werden Anhänge im Dateisystem und nicht in der Datenbank gespeichert?

mfG
Thorsten
 
Mit wie vielen (simultanen) Benutzern rechnest du?
Ich rechne mit ca. 500 bis 700 simultanen.
Hast du dir bereits Gedanken zum kommenden vBulletin 4.0 gemacht?
Nein, auf die Software an sich habe ich keinen Einfluss. Ich kann mir auch vorstellen, dass es noch ein wenig dauert bis das upgegradet würde, da es "highly customized" ist und sich daher wohl eher schwierig gestaltet, aber ich hab da nix zu sagen.
Gibt es einen speziellen Grund, warum du eAccelerator einsetzt. Vom vBulletin Staff wird immer APC empfohlen und bevorzugt.
Ich habe in der Vergangenheit immer gute Erfahrungen mit eAccelerator gemacht. Der Umstieg auf APC ist denkbar, allerdings ist es so wie mit vielen Tools: Der eine schwört auf A der andere auf B, Vergleiche sagen mal dies mal das und nen Unterschied spürst du fast nicht. Evtl. probiere ich es mal, aber ich denke nicht, dass hier der merkliche Performanceschub zu erwarten ist.
Sind performancelastige Dinge wie vBSEO im Einsatz?
Nein, das Ding ist ein geschlossenes Board, SEO ist hier nicht angedacht.
Werden Anhänge im Dateisystem und nicht in der Datenbank gespeichert?
Das war der erste Schritt, so wurde die DB von 14 GB auf ca. 2 GB reduziert.

Aber ich seh schon, der nächste Schritt ist dann wohl ne GBit-Karte oder zwei oder drei :)
 
Ich hab jetzt noch ein wenig an den VBulletin-Einstellungen gedreht und mod_expire ausgeweitet.

Jetzt warte ich mal das Anwenderfeedback ab und werte in ein paar Tagen die mySQL-Statistiken nochmals aus, dann sind die Auswirkungen der aktuellen Änderungen sichtbar.

Für weitere Ratschläge bin ich dankbar. Wenn Varnish hier Sinn macht, schau ich mir das weiter an.

Insgesamt würde ich den RAM gerne mehr auslasten, aber so richtig voll wird er nicht :)
 
Für die die es interessiert:

Ich habe die Performance nochmals merklich steigern können, indem ich noch ein paar Einstellungsänderungen an VBulletin vorgenommen habe und den Webserver optimiert habe.

1) YUI aus externer Quelle laden
2) Keinen No-Cache-Header schicken
3) Expiry-Date für Media-Daten und CSS/JS gesetzt (auf "near future")
4) Datenbank-Cache noch etwas erhöht

Kunde sagt: "Rennt wie Sau".

Ich denke dann spar ich mir nen weiteren Zwischenschritt vorerst. Als nächstes sollen sich die Herrschaften mit Skriptpositionierung im Template beschäftigen (JS am Ende laden etc.).
 
Was bei VBulletin auch noch den Load reduziert ist das Entfernen der Redirect-Seiten nach Benutzereingaben bspw.

Aber übertreiben muss man es dann eigentlich nicht. Im Moment bin ich mit dem Performance-Gewinn zufrieden.
 
Back
Top