To, że trzeba keszować, i co trzeba keszować, a czego nie można to już wiemy. Wiemy też jak powinniśmy keszować. Mając tą wiedzę, przejdźmy do czynu!
Keszowanie to dość rozległy temat. Ten artykuł to druga część, obejmująca konfigurację Varnisha, i lighttpd by zmusić go do korzystania z Varnisha.
Keszować możemy na różne sposoby, bardziej lub mniej wydajnie.
Najpowszechniejsze metody keszowania to:
1. modyfikacja nagłówków http, kompresja po stronie httpd, kompresja php po stronie php
2. serwer keszujący, np. Varnish
3. keszowanie pehapa przez x-cache
4. keszowanie *sql wykorzystując np. memcache
5. keszowanie aplikacji webowych, np. wordpress
Co to za diabelstwo ja sie pytam?! Na jaką mi cholere kolejny badziew na moim zajebistym serwerze majnkrafta?!
Ze strony projektu dowiadujemy się, że:
Varnish Cache is a web application accelerator also known as a caching HTTP reverse proxy. You install it in front of any server that speaks HTTP and configure it to cache the
contents. Varnish Cache is really, really fast. It typically speeds up delivery with a factor of 300 – 1000x, depending on your architecture. A high level overview of what Varnish does can be
seen in the video attached to this web page
Nie po to tłuką młodym w szkołach angielski, żebym to tłumaczył. Zajmijmy się czymś ciekawszym. Implementacją ]:->
Nasza konfiguracja Varnisha będzie wyglądała tak:
1. Varnish słucha na pocie 80 z całego świata, i czeka aż ktoś będzie chciał odwiedzić naszą stronę
2. Gdy ktoś spyta Varnisha o stronę, Varnish odpyta serwer httpd(który słucha tylko na localhoście i innym porcie)
3. Varnish poda odpowie na prośbę contentem, jednocześnie ją sobie skeszuje
4. każde kolejne zapytanie o tą samą stronę będzie równoznaczne z BŁYSKAWICZNĄ odpowiedzią
Na co czekać? Do instalacji przystąp!
aptitude install varnish
Pozostała jeszcze kwestia kilku drobnostek. Są to:
Konfiguracje
Zmiana portu na którym nasłuchuje instancja lighttpd na:
server.port = 8080
Oraz przestawienie lighttpd w tryb nasłuchiwania wyłącznie na localhoście:
server.bind = "127.0.0.1"
/etc/default/varnish
START=yes NFILES=131072 MEMLOCK=82000 DAEMON_OPTS="-a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -u varnish -g varnish -t 300 -s malloc,256m"
oraz
nano /etc/varnish/default.vcl
# Default backend definition. Set this to point to your content server.
backend default {
.host = "127.0.0.1";
.port = "8080";
.connect_timeout = 60s;
.first_byte_timeout = 60s;
.between_bytes_timeout = 60s;
.max_connections = 800;
}
acl purge {
"127.0.0.1";
"localhost";
}
sub vcl_recv {
set req.grace = 2m;
# Set X-Forwarded-For header for logging in nginx
remove req.http.X-Forwarded-For;
set req.http.X-Forwarded-For = client.ip;
# Remove has_js and CloudFlare/Google Analytics __* cookies and statcounter is_unique
set req.http.Cookie = regsuball(req.http.Cookie, "(^|;s*)(_[_a-z]+|has_js|is_unique)=[^;]*", "");
# Remove a ";" prefix, if present.
set req.http.Cookie = regsub(req.http.Cookie, "^;s*", "");
# Either the admin pages or the login
if (req.url ~ "/wp-(login|admin|cron)") {
# Don't cache, pass to backend
return (pass);
}
# Remove the wp-settings-1 cookie
set req.http.Cookie = regsuball(req.http.Cookie, "wp-settings-1=[^;]+(; )?", "")
;
# Remove the wp-settings-time-1 cookie
set req.http.Cookie = regsuball(req.http.Cookie, "wp-settings-time-1=[^;]+(; )?"
, "");
# Remove the wp test cookie
set req.http.Cookie = regsuball(req.http.Cookie, "wordpress_test_cookie=[^;]+(; )?", "");
# Static content unique to the theme can be cached (so no user uploaded images)
# The reason I don't take the wp-content/uploads is because of cache size on bigger blogs
# that would fill up with all those files getting pushed into cache
if (req.url ~ "wp-content/themes/" && req.url ~ ".(css|js|png|gif|jp(e)?g)") {
unset req.http.cookie;
}
# Even if no cookies are present, I don't want my "uploads" to be cached due to their potential size
if (req.url ~ "/wp-content/uploads/") {
return (pass);
}
# any pages with captchas need to be excluded
if (req.url ~ "^/contact/" || req.url ~ "^/links/domains-for-sale/")
{
return(pass);
}
# Check the cookies for wordpress-specific items
if (req.http.Cookie ~ "wordpress_" || req.http.Cookie ~ "comment_") {
# A wordpress specific cookie has been set
return (pass);
}
# allow PURGE from localhost
if (req.request == "PURGE") {
if (!client.ip ~ purge) {
error 405 "Not allowed.";
}
return (lookup);
}
# Force lookup if the request is a no-cache request from the client
if (req.http.Cache-Control ~ "no-cache") {
return (pass);
}
# Try a cache-lookup
return (lookup);
}
sub vcl_fetch {
#set obj.grace = 5m;
set beresp.grace = 2m;
}
sub vcl_hit {
if (req.request == "PURGE") {
purge;
error 200 "Purged.";
}
}
sub vcl_miss {
if (req.request == "PURGE") {
purge;
error 200 "Purged.";
}
}
Opcja -s malloc,256m oznacza że dane trzymane będą w pamięci, a ich maksymalny rozmiar wynosił będzie 256MB.
Możemy to zmienić stosując opcję:
-s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,1G"
nakazując w ten sposób Varnishowi keszowanie do pliku w podanej lokalizacji, oraz ograniczając jego przestrzeń do 1 GB (całość zostanie od razu zajęta po wcieleniu w życie tej zmiany
w konfiguracji)
Paramter:
-t 120
Oznacza TTL(Time To Live), czyli czas życia skeszowanych zasobów. Trafne jego dobranie to klucz do sukcesu. 😉
Konfiguracje które podałem są absolutnie minimalne do poprawnego działania Varnisha(no, + kilka bajerów do bezpieczniejszego keszowania rzeczy związanych
z WordPressem). Pliki konfiguracyjne są precyzyjnie obkomentowane tak, by każdy z łatwością mógł dostosować je do swoich potrzeb. Nie mniej jednak te wyżej zamieszczone będą działać
poprawnie(jeżeli nie skopiecie łamania linii przy kopiowaniu 😉
Dla bezpieczeństwa, upewnijcie się, że w pliku
/etc/passwd
użytkownik spod którego uruchomiony jest Varnish ma przypisaną powłokę /bin/false.
Na sam koniec pozostaje włączyć logi w /etc/default/varnishlog i voila!
Teraz pozostaje nic innego jak czerpać profit ze stron zapierdalających jak dzikie króliki!