Dorim să urmărim efectul folosirii Varnish față de accesarea directă a unui server web. Vom folosi utilitarul httperf pentru a evalua comportamentul accesului web folosind Varnish sau fără Varnish.

Pe mașina virtuală varnish (accesibilă folosind ssh -l root 192.168.0.3) este instalat Varnish. Este configurat să asculte conexiuni pe portul 80, lucru pe care îl putem verifica folosind comanda:

root@varnish:~# netstat -tlpn | grep varnish
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      2366/varnishd
tcp        0      0 127.0.0.1:6082          0.0.0.0:*               LISTEN      2364/varnishd
tcp6       0      0 :::80                   :::*                    LISTEN      2366/varnishd
tcp6       0      0 ::1:6082                :::*                    LISTEN      2364/varnishd

Portul 6082 este portul de administrare. Configurația aferentă se găsește în fișierul /etc/default/varnish. Putem folosi un editor/viewer sau comanda de mai jos pentru a investiga configurația:

root@varnish:~# grep -A 4 DAEMON_OPTS /etc/default/varnish | grep -v '^#'
--
--
DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,256m"
--
--

Pentru a urmări utilitatea folosirii Varnish, vrem să ne conectăm la un server pe legătură directă și prin intermediul Varnish. Alegem serverul ocw.cs.pub.ro. Pentru aceasta, serviciul Varnish a fost configurat să folosească pe post de back end ocw.cs.pub.ro. Putem consulta această configurație în fișierul /etc/varnish/default.vcl folosind un editor/viewer sau comanda de mai jos:

root@varnish:~# grep -A 3 'backend default' /etc/varnish/default.vcl 
backend default {
    .host = "ocw.cs.pub.ro";
    .port = "80";
}

Configurația de mai sus înseamnă că pentru cererile venite către serviciul Varnish se vor realiza cereri mai departe către serverul ocw.cs.pub.ro. Cererile vor fi cache-urite astfel încât viitoare cereri vor fi servite direct din cache.

Evaluarea o vom face de pe sistemul gazdă (mjolnir). Pentru acesta va trebui să configurăm sistemul astfel încât cererile către ocw.cs.pub.ro să ajungă la mașina virtuală varnish. Pentru aceasta, folosiți un editor și adăugați în fișierul /etc/hosts linia:

192.168.0.3	ocw.cs.pub.ro

Cu linia de mai sus, cererile către ocw.cs.pub.ro vor ajunge la mașina virtulă varnish. Putem verifica acest lucru folosind comanda:

student@mjolnir:~$ ping ocw.cs.pub.ro
PING ocw.cs.pub.ro (192.168.0.3) 56(84) bytes of data.
64 bytes from ocw.cs.pub.ro (192.168.0.3): icmp_seq=1 ttl=64 time=0.361 ms
^C

Pentru început puteți să vă conectați din browserul de pe stația gazdă (mjolnir) și să accesați URL-ul aferent: http://ocw.cs.pub.ro. O să vedeți că primul acces durează mai mult dar viitoarele accese ale aceleiași pagini sunt mai rapide.

Pentru a evalua acest lucru, instalați utilitarul httperf pe stația gazdă folosind comanda:

student@mjolnir:~$ sudo apt-get install httperf

Apoi măsurați conexiunile realizate pentru pagina de la URL-ul http://ocw.cs.pub.ro folosidn comanda:

student@mjolnir:~$ httperf --server=ocw.cs.pub.ro --wsess=2000,10,2 --rate 300 --timeout 5

Observați în output informații precum Connection rate, Request rate, Net I/O.

Ca să comparăm trebuie să ne conectăm în mod direct la serverul ocw.cs.pub.ro. Pentru acesta ștergeți (sau comentați) linia adăugată anterior în fișierul /etc/hosts și rulați din nou comanda httperf de mai sus. Observați diferențele parametrilor și, astfel, utilitatea folosirii Varnish ca accelerator pentru conexiuni web.

Ne propunem să configurăm Varnish ca front-end pentru un server web configurat de noi. Pentru aceasta vom configura instanța Varnish de pe mașina virtuală varnish ca front end pentru serverul web de pe mașina virtuală web și apoi vom face măsurători.

Pentru început, configurați instanța Varnish de pe mașina virtuală varnish să folosească pe post de back end serviciul web de pe mașina virtuală web.

root@varnish:~# service varnish restart

Pentru a testa conectați-vă din browser-ul de pe stația gazdă la adresa serverului Varnish: http://192.168.0.3/. Dacă totul a mers cum trebuie va apărea o pagină cu mesajul Say hello to my little friend!.

Același mesaj poate fi accesat direct de la serverul web: http://192.168.0.2/, doar că nu va mai trece prin serverul Varnish.

Pentru a măsura durata transferului cu și fără Varnish, folosiți httperf pe stația gazdă (mjolnir) pentru a descărca un fișier dintre cele accesibile la adresa http://192.168.0.3/data/ (sau http://192.168.0.2/data/); de indicat este să folosiți fișierul 10M.dat de dimesiunea cea mai mare. Folosiți conectarea la ambele servere (cu și fără suport Varnish) pentru a face diferența.

În timpul în care rulați httperf urmăriți folosind htop încărcarea pe cele două mașini virtuale. Observați încărcarea serverului Varnish atunci când acesta este folosit, sau a serverului Apache la conexiunile directe.

Observati diferența de Request rate între conexiunea directă la serverul web și conexiunea prin intermediul serverului Varnish.

Ca să urmărim starea serviciului Varnish dispunem de câteva utilitare de analiză și monitorizare a acestuia. Acestea sunt, respectiv, varnishlog, varnishstat și varnishhist.

Toate afișează informații despre serviciul Varnish din momentul rulării comenzii, nu și dinainte.

Comanda varnishlog afișează informații despre conexiunile realizate la serviciul Varnish. Rulați comanda varnishlog și apoi realizați conexiuni la serviciu. Urmăriți informații despre aceste conexiuni în output-ul comenzii. Informațiile afișate sunt bogate; putem să filtrăm din acestea. De exemplu, dacă rulăm comanda

# varnishlog -O -i RxURL

va fi afișat doar URL de receive (ceea ce i-a fost solicitat serviciului Varnish).

Comanda varnishstat afișează informații despre starea serviciului. Output-ul ocupă un ecran și este actualizat periodic. Porniți comanda, realizați conexiuni către serviciul Varnish și urmăriți actualizarea output-ului. Urmăriți linia Hitrate ratio.

Comanda varnishhist afișează o histogramă a timpului de servire a cererilor. Pe partea orizontală sunt prezentați timpii de servire, la scară logaritmică. Accesele care nu ajung în cache apar cu # (diez) iar cele care ajung în cache apar cu | (pipe). Realizați mai multe conexiuni diferite (de exemplu la cele trei fișiere de dimensiuni diferite) și observați output-ul afișat de comandă. Observați că este foarte mic timpul de servire din cache față de cel de servire inițială, prin interogarea serverului web.

Folosiți comanda varnishlog pentru a afișa doar cererile către fișierul /data/100k.dat.

Vrem să vedem cum se comportă cache-ul în Varnish. Intrările în Varnish sunt cache-uite pentru o perioadă de timp înainte să expire. După expirarea timpului respectiv, se realizează o nouă cerere către serverul web pentru obținerea din nou a paginii.

Timpul de viață al cache-ului este dat de o variabilă TTL internă a Varnish. Valoarea sa este în mod implicit configurată la 120 de secunde. Putem determina acest lucru prin intermediul comenzii:

root@varnish:~# varnishadm param.show default_ttl

Valorea implicită, afișată de comanda de mai sus este 120 de secunde. Această valoare poate fi configurată în fișierul /etc/default/varnish; este vorba de directiva VARNISH_TTL.

Ca să urmărim expirarea cache-ului, vom folosi comanda varnishlog în forma de mai jos:

root@varnish:~# varnishlog -i VCL_Call

Apoi facem cereri către fișierele cu extensia .dat menționate în exercițiul anterior.

Observăm că apare un mesaj ce conține cuvântul miss atunci când informația nu se găsește în cache, și apoi un mesaj ce conține cuvântul hit când informația este în cache. După 120 de secunde cache-ul va expira și atunci un acces va genera un miss.

După ce ați generat un mesaj miss pe fișierul 100k.dat, adică informația nu era, dar acum este, în cache, rescrieți fișierul pe serverul web, în directorul /var/www/data/100k.dat folosind comanda:

root@web:/var/www/html/data# dd if=/dev/urandom of=100k.dat bs=100k count=1

Apoi accesați din nou fișierul și urmăriți output-ul comenzii varnishlog. Veți observa că fișierul a fost obținut din cache. Până când cache-ul nu expiră orice modificare a fișierului nu va fi vizibilă în cache.

Pentru a preveni rămânerea în cache a unui obiect dat, se poate folosi purging sau banning. După ce au ajuns în cache fișierele cu extensia .dat, faceți ban acelor fișiere pentru a fi recitite de pe server.

Pentru a realiza configurări în Varnish se folosește sintaxa VCL (Varnish Configuration Language). Aceasta permite încărcarea dinamică de configurații într-o instanța Varnish în rulare.

Folosind fișierul de configurare /etc/varnish/default.vcl, configurați un TTL de 1 oră pentru fișierele din directorul /data/ servite de Varnish. Celelalte fișiere/pagini servite vor folosi valoarea implicită a TTL-ului (de 120 de secunde).

Așteptați 3-4 minute după primul acces la o pagină din directorul /data/ și apoi reaccesați-o. O configurație corectă va înseamna un hit în pagină (cache-ul de o oră nu va fi expirat).

Dorim ca serviciul Varnish să accelereze accesul web atât către serverul web din mașina virtuală web cât și către ocw.cs.pub.ro. Pentru aceasta trebuie să fie configurate două back end-uri.

Configurați cele două back end-uri astfel încât dacă URL-ul începe cu /courses/ să fie servit de back end-ul de ocw.cs.pub.ro, altfel să fie servit de back end-ul mașinii virtuale web.

Dorim să facem load balancing (denumit și directors în Varnish). Înainte de această configurare, opriți mașina virtuală web și creați o copie a imaginii web.qcow2 într-un alt fișier, de exemplu web-copy.qcow2. Apoi editați scriptul xlr8-start-kvm pentru a porni o nouă mașina web, cu altă adresă IP. Această mașină web este al doilea back end.

Configurați Varnish pe mașina virtuală varnish să folosească cele două servere web de pe celelalte două mașini virtuale în load balancing de tip round robin.

Nginx este un server web care poate îndeplini un rol de reverse proxy and cache server la fel ca Varnish. Instalați și configurați Nginx pe stația varnish.

De pe stația gazdă (mjolnir) folosiți utilitarul httperf pentru a măsură performanța Nginx ca reverse proxy față de Varnish.

Configurați Squid ca forward proxy pe mașina virtuală web și apoi configurați browserul local să folosească Squid ca proxy.

Pentru verificare, accesați din browser anumite adrese și urmăriți fișierul de jurnalizare al Squid: /var/log/squid3/access.log.