Løbende statistik for serveren

[NickyThomassen]

Nu runder forummet snart 5 måneders jubilæum på den nye server, og i den forbindelse må lidt statistik vist være på plads.

Allerførst, selvfølgelig, er statistik jo roden til alt ondt.

Desuden har vi ikke et 100% klart overblik over hvordan hjemmesiden bliver brugt, kun hvordan webserveren bliver brugt. Grunden er, at det ikke er webserveren, som vi besøgende opretter forbindelse til, men derimod en cacheserver. Modsat webserveren, så belaster cacheserveren systemet en hel del mindre, men den fører ikke besøgslog. Derimod holder den styr på hvor mange procent af de indkomne forbindelser den kan betjene, og det ligger ret stabilt på 28% over en måned.

varnish_hit_rate-month.png (24.15 KiB) Vist 452 gange

Så det korte af det lange er, at alle besøgstal skal have lagt 28% oveni. Alternativt kunne man kigge på Google Analytics (det er et webmaster-værktøj som Google stiller til rådighed), men alle som aktivt blokerer reklamer og/eller JavaScript (alt efter metode), tæller ikke med i deres statistik. Derfor holder jeg mig til vores egne tal.

Ok, nok indledning, frem med tallene

I gennemsnit tager webserveren 25.000 hits i døgnet, hvilket giver cirka 22.500 sidevisninger. Med 28% lagt til, så bliver det 32.000 hits i døgnet, som serveren samlet set betjener. Det ligger beslag på cirka 15% af CPU'en og 60% af RAM'ene, imens at det forbruger cirka 7,5 gigabyte båndbredde om måneden.

CPU'en er en single core på 1,6 gigahertz, og der er 1024 megabyte ram uden swap til rådighed.

Udbyderen rapporterer, at serveren forbruger cirka 9,1 gigabyte båndbredde per løbende måned, hvilket passer ret godt med de 28% ekstra.

Timen 20-21 topper med 6.4% af de besøgende i gennemsnit i døgnet, med timen 4-5, på kun 2,3%.

Den fil som viser et indlæg, er suverænt den fil der bliver læst flest gange. I gennemsnit står den for 38,3% af indholdet som bliver vist, med andenpladsen på kun 8,8%. Størrelsesmæssigt står den ene fil for 50% af båndbredden.

Webserveren rapporterer at svarkoden "200, OK" er blevet brugt 526.000 gange fra d.01/2 - 23/02, med alle andre svarkoder 70.000 gange. Det giver et forhold på 7,5 til 1. Billedet er dog lidt skævt, da cacheserveren kun kan håndtere svarkoder som er OK. Er svarkoden noget andet, så sender den aben videre til webserveren.

Ifølge oplysninger givet af de besøgendes browser, så kommer 71,5% direkte til siden, hvilket indikerer at et bogmærke er blevet brugt, eller at sidens adresse er blevet tastet direkte ind i adresselinien. Google står kun for 0,7% af henvisningerne til siden, hvor søgeordet "Ubuntu" har den største frekvens på 8,7%. Det er dog et tal forbundet med noget usikkerhed, da en henvisningen til forsiden har en høj chance for ikke at tælle med i statistikken.

Cirka 1790 forskellige sider og indlæg, bliver vist om måneden.

Siden bliver besøgt af cirka 315 forskellige computere om måneden, omend det er et tal forbundet med en vis usikkerhed. Jeg analyserer ikke den geografiske oprindelse af et besøg, da det dels belaster serveren (unødigt), og dels ikke er ret nøjagtigt.

Databasen tager cirka 435 hits i minuttet i gennemsnit; 290 af dem, er cachehits. Det svarer i runde tal til, at hver 3 hit kræver en forbindelse til databasen.

[AJenbo]

Kan den heller ikke cache 304?

Vil mange af cache hit ik' være på billeder og andre elementer til siden?

[NickyThomassen]

Jeg er skyldig i at glemme at undersøge cache af 304, men jeg har lavet en oldgræker på problemet, og en cache af de fleste 304 er nok ikke mulig. Klienten spørger serveren om filerne er blevet ændret, men de fleste af klienterne for UbuntuDK er logget ind, så de sender cookies med forespørgelsen, hvilket får Varnish til at passere den videre til Apache.

Det gør bare et subdomæne til statisk indhold endnu vigtigere, hvis Varnish' cache skal vokse.

Jo, for vi stripper cookies af filtyperne png, gif, jpg, swf, css og js, så det er mest dem, og sikkert også noget af Wordpress (så længe at den besøgende ikke har fået sat cookies).

[AJenbo]

Tænker de kan have en vis betydning for mængden af data der bliver sendt.

[NickyThomassen]

Jeg ved ikke helt. Af de 70.000 andre svarkoder end OK, der var de 20.000 af dem 304. Men det kan godt være at jeg ikke ved nok om dem, og hvordan http i det hele taget virker.

Umiddelbart tror jeg at det eneste vi kan gøre, det er at undgå 304. På den anden side, 20.000 ud af 596.000 er kun 3,4%, så spørgsmålet er hvor meget det kan betale sig at kigge på det?

Som jeg ser det, så er det cookies i forbindelse med statisk indhold som er problemet (for Varnish). Når 70% af de besøgende er direct requests, så er det sikkert gengangere, som sikkert er logget ind, eller har været det. Når en besøgendes browser fx spørger om billedet
https://ubuntudanmark.dk/wp-content/uploads/2012/12/59310_4772328981691_285580906_n.jpg
er udløbet, så er der 70% (eller mere) chance for at en cookie følger med, og så passere Varnish forspørgelsen.

I loggen fra igår er der 22.352 linier hvor ordet 200 indgår, og 1084 linier hvor ordet 304 indgår, men næst efter at kigge manuelt i loggen, så ved jeg ikke hvordan man kunne undersøge om der er en sammenhæng imellem indhold og 304.

Kode: Vælg alt

titanus@ubuntudk:/var/log/apache2$ grep -cw 200 access.2013.02.24.log
22352
titanus@ubuntudk:/var/log/apache2$ grep -cw 304 access.2013.02.24.log
1084
titanus@ubuntudk:/var/log/apache2$ grep -w 304 access.2013.02.24.log | grep -c jpg
0
titanus@ubuntudk:/var/log/apache2$ grep -w 304 access.2013.02.24.log | grep -c png
0
titanus@ubuntudk:/var/log/apache2$ grep -w 304 access.2013.02.24.log | grep -c js
314
titanus@ubuntudk:/var/log/apache2$ grep -w 304 access.2013.02.24.log | grep -c css
52


[AJenbo]

304 er den mest optimale måde at servere indhold, så det er ikke noget vi skal afskaffe.

[NickyThomassen]

Ah, se dét giver mening