Trennen von statischen / hochgeladenen Inhalten von der Site

7

Ich habe eine Website, auf der ich eine große Anzahl von Benutzern erwarte. Ich habe gehört, dass es eine gute Idee ist, Benutzerinhalte (hochgeladene Bilder) zu trennen und sie auf einem separaten statischen Server zu platzieren, auf dem lighttpd den Inhalt bereitstellen würde. Dies soll die Anfragen erheblich beschleunigen.

Meine Frage ist:

Wie viel Verbesserung kann ich davon erwarten?
Wie wird es gemacht? Benutzer auf meiner Website laden Dateien hoch, aber wie automatisiere ich dann den Übertragungsprozess? Was ist die beste Vorgehensweise? Rsync?
Irgendwelche anderen Tipps? Ideen? Ich würde mich sehr über Ihre Beiträge freuen.

— user7562
quelle

2

Sorgen Sie sich später um Rsync - jetzt können Sie alles auf einer Box erledigen.

Ihre Hauptdomain befindet sich http://www.example.com/in dieser Domain, in der Sie Cookies bereitstellen (lecker!).

Das Nicht-WWW leitet zu den oben genannten weiter.

Ihre statische Domain ist http://static.example.com/und auf dieser Domain werden keine Cookies oder andere Header-Elemente bereitgestellt, die nicht wirklich benötigt werden. Setzen Sie dort js + css komprimiert und Bilder unkomprimiert. Stellen Sie alles, was auf statisch bereitgestellt wird, so ein, dass es für den öffentlichen Cache geeignet ist und ein Ablaufdatum für einige Zeit in der Zukunft hat.

Richten Sie nun Ihre Domains so ein, dass sie auf dieselbe Stelle im Dateisystem verweisen. Wenn Sie also test.jpg wirklich laden möchten, können Sie von beiden Stellen genau dieselbe Datei abrufen. Tun Sie dies mit den Einstellungen von httpd.conf und zwei Einträgen für virtuelle Server.

Wenn Ihr Datenverkehr große Ausmaße annimmt, können Sie Ihren statischen Inhaltsserver in eine andere Box migrieren und den gesamten Dokumentstamm in die neue Box synchronisieren. Ein Cron-Job kann eingerichtet werden, um dies etwa alle 5 Minuten zu tun, und der 404 der Statik kann zum WWW umleiten, um alle Ressourcen abzurufen, die noch nicht synchronisiert wurden.

— ʍǝɥʇɐɯ
quelle

Toller Rat! 404 zum Umschreiben auf den Ursprungsserver zu haben, ist eine geniale Idee! Vielen Dank für den Rat!

— user7562

Ich habe ein paar Fragen, was genau meinst du mit komprimiertem js / css? Ist das eine Webserver-Einstellung oder komprimiere ich sie selbst? Warum nicht Bilder komprimieren?

— user7562

Bilder sind bereits komprimiert - JPEG usw. Sie können sie nicht mehr komprimieren, als sie bereits sind, wenn Sie sie im laufenden Betrieb bereitstellen. Aus diesem Grund müssen sie nicht doppelt komprimiert werden. Ihre js-Javascript- und CSS-Stylesheets sind im Wesentlichen Textdateien mit vielen Leerzeichen. Diese Ressourcen werden mit 'gzip' (dem normalerweise von Apache verwendeten Komprimierungsalgorithmus) sehr gut komprimiert.

— 25.

1

Der Geschwindigkeitsunterschied hängt von vielen Variablen ab. Stellen Sie sich das so vor: Jedes Mal, wenn ein Benutzer eine Seite / ein Bild anfordert, muss der Prozessor des Servers diese Anforderung bearbeiten, das angeforderte Element in den RAM werfen und es dann bereitstellen.

Durch das Trennen von statischen Inhalten entfernen Sie Videos mit großen Bildern und andere Inhalte aus der Warteschlange der Seitenanforderungen an Ihren Prozessor, damit er Seiten so schnell wie möglich verteilen kann, ohne sich um Bilder / Videos / große Inhalte zu kümmern.

Worauf es ankommt, ist Ihre Prozessorgeschwindigkeit, Ihr RAM und Ihre Bandbreite.

Wenn Sie dies tun, weisen Sie Ihren statischen Server einer Subdomain zu, die nicht domänenübergreifendes Scripting ermöglicht. Wenn es sich nur um Bilder handelt, die Sie nur mit der Web-Adresse verknüpfen können, oder wenn Sie mehr über Cross-Server-Scripting lesen können, ist Apache so konzipiert, dass es verdammt einfach ist.

Es gibt eine SO-Frage, die hier ziemlich ähnlich ist: https://stackoverflow.com/q/913208/500959

— Gemeinschaft
quelle