- Joined
- Oct 24, 2003
- Messages
- 11,481
- Points
- 325
Am 6. Februar 2011 wurde Debian Squeeze veröffentlicht, die nächste Version des von uns eingesetzten Betriebssystems Debian. Nachdem am 19. März 2011 die erste Aktualisierung von Debian Squeeze erschien, welche hauptsächlich Sicherheitslücken des Stable-Releases schließt und sich bislang keine gravierenden Probleme ergeben haben, werden wir in den nächsten Wochen das Betriebssystems unseres Servers erneuern.
Einen genauen Termin können wir derzeit noch nicht nennen, da ich noch eine Diplomprüfung vor mir habe und mich inmitten meines Umzuges befinde. Sobald ein Termin feststeht werden wir diesen seperat ankündigen.
Im Rahmen dieses Umzuges werden wir ebenso unseren Webserver erneuern, um die Leistungsfähigkeit des Webserver weiter zu erhöhen und entsprechend der großartigen finanziellen Unterstützung das meiste aus unserem Server zu holen.
Im Folgenden eine unvollständige Auflistung über den Verlauf der Verbesserungen des Webservers.
Die neue Struktur wird wie folgt aussehen:
Insbesondere möchte ich den Webbeschleuniger hervorheben, da dieser eine generelle Neuerung darstellt. Sofern die angeforderte Seite noch nicht gespeichert wurde (die statische HTML-Darstellung), wird diese angefordert (Miss) und durchläuft den auch jetzt schon gängigen Server-Prozess für PHP-Dateien. Nachdem die Ausgabe berechnet wurde und sie zur schnelleren Übertragung mit gzip gepackt wurde, wird sie an den Webbeschleuniger übergeben, damit dieser die Ausgabe abspeichern kann (Store) und sie danach an den Nutzer schickt (Hit). Sollte nun ein weiterer Nutzer die gleiche Anfrage senden, so wird diese sofort zurückgesandt, da sie bereits abgespeichert ist (Hit) und der gesamte Berechnungsanteil inkl. Datenbank-Abfragen entfällt.
Benchmarks haben gezeigt, dass somit die Verarbeitungsgeschwindigkeit um das 500-1000 Fache erhöht werden kann, wobei sich ein solch hoher Nutzen natürlich auch erst bei einer entsprechenden Auslastung zeigt und er sogar noch höher liegen kann. Gerade bei sehr hohen Auslastungsszenarien, welche den Server bislang in die Knie zwingen können, kann ein Webbeschleuniger die Auslastung auf ein normales Niveau senken.
Webbeschleuniger sind jedoch kein Wunderwerk. Auf der einen Seite benötigt man eine gewisse Grundauslastung, damit die zusätzliche Verarbeitungszeit, welche durch einen Webbeschleuniger ausgelöst wird, nicht höher liegt als der Nutzen. Diese ist seit längerer Zeit im United-Forum gegeben. Des Weiteren können nur die Seiten beschleunigt werden, welche nicht von speziellen Nutzereinstellungen abhängen, welche nicht durch das HTTP-Protokoll ersichtlich sind (GET/POST-Request, Cookies, etc. sind Ok; Spezielle Benutzereinstellungen in der Datenbank nicht.).
Somit wirkt der Webbeschleuniger in erster Linie nur für Gäste und Suchmaschinen, was jedoch schon eine bedeutende Leistungsverbesserung darstellt.
Fragen und Anregungen zum Wechsel könnt ihr am bsten hier stellen.
Euer UF-Team
Einen genauen Termin können wir derzeit noch nicht nennen, da ich noch eine Diplomprüfung vor mir habe und mich inmitten meines Umzuges befinde. Sobald ein Termin feststeht werden wir diesen seperat ankündigen.
Im Rahmen dieses Umzuges werden wir ebenso unseren Webserver erneuern, um die Leistungsfähigkeit des Webserver weiter zu erhöhen und entsprechend der großartigen finanziellen Unterstützung das meiste aus unserem Server zu holen.
Im Folgenden eine unvollständige Auflistung über den Verlauf der Verbesserungen des Webservers.
[TABLE=head] | Vergangenheit | Gegenwart | Zukunft
Betriebssystem | SUSE | Debian | Debian
Webserver | Apache | Apache | Ngnix
Webserver-Konfigurationstool | Plesk | |
Webbeschleuniger | | | Varnish
OP-Code-Cache | eAccelerator | XCache | APC
Object Cache | eAccelerator | XCache | APC
Datenbank | MySQL | MySQL | MariaDB
[/TABLE]
Betriebssystem | SUSE | Debian | Debian
Webserver | Apache | Apache | Ngnix
Webserver-Konfigurationstool | Plesk | |
Webbeschleuniger | | | Varnish
OP-Code-Cache | eAccelerator | XCache | APC
Object Cache | eAccelerator | XCache | APC
Datenbank | MySQL | MySQL | MariaDB
[/TABLE]
Die neue Struktur wird wie folgt aussehen:
Insbesondere möchte ich den Webbeschleuniger hervorheben, da dieser eine generelle Neuerung darstellt. Sofern die angeforderte Seite noch nicht gespeichert wurde (die statische HTML-Darstellung), wird diese angefordert (Miss) und durchläuft den auch jetzt schon gängigen Server-Prozess für PHP-Dateien. Nachdem die Ausgabe berechnet wurde und sie zur schnelleren Übertragung mit gzip gepackt wurde, wird sie an den Webbeschleuniger übergeben, damit dieser die Ausgabe abspeichern kann (Store) und sie danach an den Nutzer schickt (Hit). Sollte nun ein weiterer Nutzer die gleiche Anfrage senden, so wird diese sofort zurückgesandt, da sie bereits abgespeichert ist (Hit) und der gesamte Berechnungsanteil inkl. Datenbank-Abfragen entfällt.
Benchmarks haben gezeigt, dass somit die Verarbeitungsgeschwindigkeit um das 500-1000 Fache erhöht werden kann, wobei sich ein solch hoher Nutzen natürlich auch erst bei einer entsprechenden Auslastung zeigt und er sogar noch höher liegen kann. Gerade bei sehr hohen Auslastungsszenarien, welche den Server bislang in die Knie zwingen können, kann ein Webbeschleuniger die Auslastung auf ein normales Niveau senken.
Webbeschleuniger sind jedoch kein Wunderwerk. Auf der einen Seite benötigt man eine gewisse Grundauslastung, damit die zusätzliche Verarbeitungszeit, welche durch einen Webbeschleuniger ausgelöst wird, nicht höher liegt als der Nutzen. Diese ist seit längerer Zeit im United-Forum gegeben. Des Weiteren können nur die Seiten beschleunigt werden, welche nicht von speziellen Nutzereinstellungen abhängen, welche nicht durch das HTTP-Protokoll ersichtlich sind (GET/POST-Request, Cookies, etc. sind Ok; Spezielle Benutzereinstellungen in der Datenbank nicht.).
Somit wirkt der Webbeschleuniger in erster Linie nur für Gäste und Suchmaschinen, was jedoch schon eine bedeutende Leistungsverbesserung darstellt.
Fragen und Anregungen zum Wechsel könnt ihr am bsten hier stellen.
Euer UF-Team
