Website Performance - Erfahrungen mit 103bees.com (III)
Post-Serie über meine Erfahrungen mit 103bees.com - heute zur Optimierung der Website Performance.
Eine Website super zu promoten - am besten mit einem viralen Kickstart wie es mit 103bees.com gelang - ist eine Sache. Die andere, dann auch entsprechend zu liefern (Englisch: ‘Walk your talk’). Denn die beste Promotion nützt nichts, wenn tausende Besucher auf eine Site wollen, aber nichts zu sehen bekommen, weil der Webserver nicht ‘ausliefert’.
Mit einer mangelnden Performance, resp. langen Lade- und Antwortzeiten einer Website kann man sich locker die ganze Mühe in der Erstellung und der Promotion zunichte machen. Das ist mir mit 103bees stellenweise fast ‘gelungen’: ich musste Neuanmeldungen sperren und die Ladezeiten gewisser Abfragen wurden je länger desto unerträglicher. Kurz: alles, was User nicht mögen. Und der Alptraum jedes Webmaster.
Diese Zeiten sind zum Glück für 103bees (vorerst) vorbei. Die Auswertungen performen im Vergleich zu vorher in Lichtgeschwindigkeit, ich konnte eben die Anmeldungen wieder öffnen und werde in Kürze die endlos lange Mailingliste davon in Kenntnis setzen. Wieviele potentielle User ich durch die Performance-bedingte Pause verloren habe, will ich gar nicht wissen.
Folgende Massnahmen haben die Lage entspannt:
- Wechsel auf einen Dedicated Server: AMD Opteron 146 Prozessor, 2G RAM, 2x 120GB SCSI Harddisks mit RAID1, Debian Linux-Distribution mit Apache 2.0 Webserver. Zu haben für ca. 100 EUR pro Monat.
- Optimierung der PHP-Skripte hinsichtlich Ausführungszeiten, Festplatten-Zugriffe und Memory-Verbrauch.
- Optimierung der Konfiguration des MySQL Datenbank-Server (die Standard-Konfiguration gesteht dem MySQL-Daemon zuwenig Ressourcen zu).
- Optimierung der MySQL Tabellenstruktur. Am meisten Performance-Gewinn brachte die geeignete Wahl von Indizes. Zu Beginn verzeihte mir der DB-Server ja noch Patzer im Tabellen-Design, bei mehreren Millionen Einträgen in einer Tabelle jedoch nicht mehr…
Der Apache 2.0 (mit Prefork-Modul) brauchte entgegen meinen Erwartungen keine weitere Optimierung der Server-Konfiguration, da die ganze Zeit über der MySQL-Server den Bottleneck bildete.
Eine gute Seite kann ich der Übung für mich trotz einer Menge Ärger abgewinnen: ein grosses Plus an Know-How. Ich gebe übrigens gerne Auskunft auf Fragen in den Kommentaren. Es muss ja nicht jeder alle Fehler eines Hosting-Greenhorns selbst wiederholen…
Hat Dir der Beitrag gefallen? Abonniere Webgreenhorn kostenlos!
Ähnliche Posts, die von Interesse sein könnten:
Trackback von Chuchichäschtli - Made in Switzerland
6. September 2006 von Markus Merz
MySQL: Indizes müssen ins RAM passen. Entsprechende Beobachtung und Einstellung per MySQL Admin tool ist ein Muss. Besser doppeltes RAM
Tip: tmpfs für /tmp (oder auch andere Partitionen). /tmp läuft als RAMdisk und lagert nur bei echtem Bedarf aus. Dazu gibt es einen Superartikel bei IBM.
S.a.
http://de.wikipedia.org/wiki/Dateisystem
http://www.google.de/search?q=tmpfs
http://www-128.ibm.com/developerworks/opensource/library/l-fs3.html
6. September 2006 von Webgreenhorn
Im Moment überwache ich die Performance des Apache mit ‘mod_status’, den MySQL-Server mit ‘phpMyAdmin’ und das Gesamtsystem mit dem Linux-Command ‘top’. Bin aber neben einem Web- auch ein Sysadmingreenhorn, macht Ihr’s anders? Welche Tools verwendet Ihr?
7. September 2006 von Markus Merz
Kannst Du online auf Deinen MySQL Server? Also per SHH Tunnel oder womöglich (igitt) direkt?
Falls ja, dann gibt es sehr schicke MySQL admin Programme.
Falls Nein, dann eben nicht
Du solltest Deinen Provider mal fragen, was sie Dir an MySQL Performance Überwachung und Auswertung geben können.
4. Oktober 2006 von mh166
Also zur Lösung des Problems mit den gleichzeitigen Requests scheint mir der Webserver lighttpd eine sehr gute Lösung. Dieser ist einfach zu konfigurieren und ist -nach eigenen Angaben- wesentlich schneller und Lastverträglicher gegenüber gleichzeitigen Requests.
Ich persönlich hab zwar aufgrund des geringen Bedarfs nur shared hosting und mein Provider läuft mit Apache. Jedoch meine ich, dass es für dich sicher eine lohnende Alternative sein könnte, angesichts der vielen Zugriffe.
mfg, mh166
11. Oktober 2006 von Webgreenhorn
Momentan läuft alles rund mit massig Performance-Reserven, v.a. in Bezug auf Anzahl gleichzeitiger Requests. Auf lighttpd bin ich im Zuge meiner Recherchen auch gestossen, wollte aber die Konfiguration mit dem Apache 2.0 erst mal testen.
Ich konnte einiges rausholen mit einer geeigneten Konfiguration betreffend Child-Prozessen des Apache.