De teknisk detaljer om foreningens nye server

[NickyThomassen]

Jeg kunne forestille mig, at en tråd om foreningens nye server kunne være meget sjov at have. Jeg ville i hvert fald være nysgerrig efter detaljer, hvis ikke det var fordi, at jeg har været med til at sætte den op

Serveren er en VPS, som er hostet hos det svenske firma GleSYS, og som er koblet op til et Tier 1 net. Selve løsningen er ret standard, og pt. betaler vi ~185kr./måneden for

• 1 processorkerne på 1.6ghz
• 1gb ram
• 5gb diskplads på VPS'en som inkluderer nattelig backup, og roterring til et andet datacenter, hvor VPS'en kan bringes online, hvis det skulle blive nødvendigt
• 50gb båndbredde pr. løbende måned, hvilket sikkert ikke er nok. Yderligere 50gb koster 10kr./måneden fladt
• 10gb FTP-lagerplads til backup, som er uden nattelig backup, hvorfor det kun koster 1kr. pr. gb/måneden

Alle værdierne er garanteret minimum, og der er ikke noget med burst, eller andet i den retning.

På softwaresiden har vi valgt Debian 64bit som OS, mest fordi GleSYS hoster VPS'en med en Debian-kernel. Vi prøvede først med Ubuntu, men det spillede ikke så godt, så det opgav vi. Af programmer har vi

• Standard LAMP med Apache, MySQL og både PHP og Perl
• Varnish cacheserver som bl.a. beskytter Apache mod overbelastning
• Postfix mailserver med greylisting og blackholes
• Dovecot til IMAP-service og godkendelse
• postfixAdmin til at håndtere mailadresser
• SquirrelMail og Roundcube som webmail
• Wordpress til alt undtagen forummet, som er drevet af phpBB
• APC PHP-cache og WP Super Cache
• Munin Node og Webalizer til statistik
• Et omfattende shell-script til automatisk backup

Plus det løse, som OpenSSL, NTP og den slags.

Serveren har kun kørt hjemmesiden i 24 timer, men indtil videre ser det hele ud til at virke. CPU'en ligger på omkring 10%, ram på 50-60%, harddisken er 40% brugt og FTP-drevet ligger vist på 10%. Man skal købe i 10gbs intervaller på FTP-drevet, så vi har lidt mere plads der, end vi pt. har brug for.

Log-filerne har ikke rapporteret noget, og statistikken siger at serveren har ekspederet 6500 forbindelser, i tidsrummet 1500-0400. Så vidt jeg husker, så ser Webalizer en forbindelse som de forespørgsler der skal til at vise en samlet side, men jeg er ikke helt sikker.

[Kurt Christensen]

(he he jeg troede i havde købt en fysisk maskine der stod i klubhuset)

[lath]

Haves også en krypteret backup kopi hos sysadmin?

Bare for alle tilfældes skyld.

/Lars

[NickyThomassen]

(he he jeg troede i havde købt en fysisk maskine der stod i klubhuset)

Det kunne det også sagtens have været

Men som sådan er vi ret spredte i landet, så vi har ikke nogen lokaler i foreningen.

[NickyThomassen]

Haves også en krypteret backup kopi hos sysadmin?

Én ting er sikkert, vi har lært en del om at ligge for mange æg i en kurv. Jeg har faktisk tidligere i dag taget en kopi af backuppen, og gemt den af vejen på min stationære.

Det pakkede dump af de 100.000+ indlæg fylder næsten 30mb.

[Jimmyfj]

Hvilke problemer gjorde, at I valgte at bruge Debian som ny server? De Ubuntu-servere, jeg har arbejdet med synes jeg da er lige til. Men, det kunne være interessant at høre om nogle af Ubuntu-problemerne.

[AJenbo]

Jeg tror mest det handlede om at tune ramforbrug og at vores host kun tilbuder Ubuntu med en ædre udgave af Linux kernen end hvad normalt er.

Selve maskin kravende er jo ikke store og med en SSD kunne siden sikker køres på en Pentium M fra start 2000'erne. Den store fordel af at have den hos en udbyder er at der ikke er en person der skal være ansvarlig for at holde den fysiske del kørende samt at internet forbindelsen er af høj kvalitet både inden og uden for landet grænser.

[lath]

Haves også en krypteret backup kopi hos sysadmin?

Én ting er sikkert, vi har lært en del om at ligge for mange æg i en kurv. Jeg har faktisk tidligere i dag taget en kopi af backuppen, og gemt den af vejen på min stationære.

Det pakkede dump af de 100.000+ indlæg fylder næsten 30mb.

Kun 30 MB?
Det var ikke så meget, hvis vi nu siger xz komprimeringsalgoritme er det nok en 10x større i dekomprimeret tilstand, det vil sige at 300 MB er nok ikke helt forkert.
Jeg tænker ikke at de 100.000+ indlæg er 100.000+ filer, for så ædes der en hel del ekstra diskplads med nogle bytes der ikke bliver brugt i en sektor.



Jeg har sådan en crazy ide om at lave sådan noget som phpbb3 med Ada 2012: http://www.ada2012.org/ , dvs at den version af phpbb3 ville køre som rå maskinkode, og ikke i PHP.
Jeg har set nogen lave noget lignende med C++, som gik fra at kunne håndtere 40 forespørgsler per sekund i PHP til ca 1220 forespørgsler per sekund i maskinkode (oversat til maskinkode fra C++).

En hurtig udregning viser at det er performance forøgelse på intet mindre end 3050%.

Ikke nok med at den kunne håndtere så mange forespørgsler, dens RAM forbrug var også markant lavere, og man kunne egentlig godt have alle 100.000+ indlæg cachet i RAM.
Det er måske noget overkill, men man kan med fordel have de mest aktive blogindlæg i RAM (man styrer hvilke indlæg man ikke vil cache med samme algoritme som bruge i mikroprocessorens cache, den hedder LRU - Least Resently Used: http://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used).

Udover caching har jeg nogle utraditionelle idéer, som mest går ud på at oversætte blog indlæg til Ada 2012 kildekode og så oversætte dem til et plugin, som er et softwarebibliotek der laves ved runtime (=imens programmet kører) ved at kalde Ada compileren. Stadig på runtime kan man så inkludere (og ekskludere) sådan et softwarebibliotek dynamisk fra programmet.

Det smarte ved oversættelse og compilering af indlæg er at indlæg er i et format som ikke på nogen måde skal behandles. Skal man ikke bruge indlægget længere kan man på runtime koble softwarebiblioteket af programmet, hvorved man så frigiver den virtuelle RAM som det softwarebibliotek optog. Er der kun 1 kopi i virtuel RAM vil den underliggende kopi i fysisk RAM (måske) også blive fjernet. Måske fordi det blandt andet afgøres af kernen på baggrund af blandt andet mængden af fri fysisk RAM.
Bedst af alt: Bruges det samme indlæg (software bibliotek, som bor en lib*.so fil) af mere end 1 program, så er der kun 1 kopi i fysisk RAM, men flere kopier i virtuel RAM.

/Lars

[Jimmyfj]

Jeg tror mest det handlede om at tune ramforbrug og at vores host kun tilbuder Ubuntu med en ædre udgave af Linux kernen end hvad normalt er.

Selve maskin kravende er jo ikke store og med en SSD kunne siden sikker køres på en Pentium M fra start 2000'erne. Den store fordel af at have den hos en udbyder er at der ikke er en person der skal være ansvarlig for at holde den fysiske del kørende samt at internet forbindelsen er af høj kvalitet både inden og uden for landet grænser.

Det forstår jeg godt. Sært at de som hotel ikke holder deres software opdateret.

Men alligevel kunne det jo være en hjælp til fællesskabet, hvis I smed en fejlrapport på forum, så vi, der arbejder med Ubuntu-servere får et lille forspring. Jeg ved ikke, at dømme ud fra det du skriver, Anders, så kan det godt blive en lang affære at liste de ting, Ubuntu ikke formåede i forhold til Debian X86_64, som jeg selv sidder på i skrivende stund. Hvor gammel er den kerne, de udbyder? Blot for at være nysgerrig.

[AJenbo]

På arbejde køre vi med en hostet server hvor vi har installeret Ubuntu 12.04, så der er ikke noget teknisk galt med at bruge Ubuntu som en server. For mig har den helt store forskel været at jeg på Debian skal skrive:
sudo invoke-rc.d apache2 restart
og på ubuntu er det
sudo service apache 2 restart
Når vi taler servere.

Grunden til at de køre med en ældre kerne er at de køre en speciel form for VPS hvor man har en enkelt kerne der køre flere systemet. På den måde bruger man meget mindre ram og CPU og VPS'en yder bedre. Samt at man kan tildele mere RAM og processer kerner til serverne uden at skulle genstarte. Begrænsningen er så at flere brugere må finde sig i at køre med den samme kerne. Jeg husker det ikke helt tydeligt men jeg tror kernen var den fra Ubuntu 10.04, hvilket jo stadig er undersøttet. På det tidspunkt kørte vi også med under 512MB ram til systemet hvilet viste sig ikke at være nok.

[NickyThomassen]

Det forstår jeg godt. Sært at de som hotel ikke holder deres software opdateret.

En 'uname -a' på foreningens VPS giver

Kode: Vælg alt

Linux ubuntudk 2.6.32-042stab055.10 #1 SMP Thu May 10 15:38:32 MSD 2012 x86_64 GNU/Linux


Den kernel version er Debians stabile Squeeze-kernel som udkom 2011-02, omend denne her er en smule custom, hvilket ikke er så underligt, når den driver et OpenVZ-miljø. 2.6.32 delen er Debian, imens 042stab055.10 er custom delen. Debian opdaterer ikke deres kernels, de patcher dem i stedet, så man bruger den samme kernel i hele systemets levetid.

Mit bud er at GleSYS hoster deres VPS på en Debian vært, og at den vært følger Debians stabile cyklus. Det betyder at deres software faktisk er opdateret, omend det jo ikke er en optimal løsning (til at hoste Ubuntu på). Som AJ skrev, så husker jeg også Ubuntu-problemerne som noget der lå udenfor Ubuntus kontrol, men jeg kan desværre heller ikke huske de præcise problemer.

Ved første øjekast giver det vel meget god mening, at det giver problemer at kører Ubuntu med en Debian kernel, og jeg tror heller ikke at Ubuntu Server skulle være dårligere end Debian på nogen måde.

På trods af de mangler som GleSYS har, så er jeg på det personlige plan ganske godt tilfreds med dem som hosting udbyder. Jeg havde brugt dem privat i 6 måneder op til at foreningen oprettede sin VPS hos dem, så jeg var klar over manglerne, da jeg forslog at bruge dem. Jeg syntes alligevel at 100% oppetid i de 6 måneder, god og hurtig support (som svarer i weekenden) og et godt kontrolpanel opvejer de andre mangler.

Ellers tilbyder de også Xen som visualisering, men det præsentere bare en række andre problemer. Tilgengæld kører ens VPS med sin egen kernel, og man har dermed 100% frie hænder, ligesom hvis man kørte hardware.

[NickyThomassen]

Det pakkede dump af de 100.000+ indlæg fylder næsten 30mb.

Kun 30 MB?
Det var ikke så meget, hvis vi nu siger xz komprimeringsalgoritme er det nok en 10x større i dekomprimeret tilstand, det vil sige at 300 MB er nok ikke helt forkert.
Jeg tænker ikke at de 100.000+ indlæg er 100.000+ filer, for så ædes der en hel del ekstra diskplads med nogle bytes der ikke bliver brugt i en sektor.

Helt præcis så fylder det gunzippede arkiv 37.8mb, og som databasedump er det så 136.5mb. Det er rent tekst, for uploadede billeder osv. ligger på filsystemet.

Det ser ud til at MySQL ligger hver database i hver sin mappe, og så ligger hver tabel i hver sin fil, for ellers vil jeg give dig ret i at spildpladsen ved 100.000+ små filer ville være relativ stor. På filsystemet fylder tabellen med indlæggende faktisk 280mb, men det er så inklusiv et søgeregister og noget søgecache.

Nu når serveren har kørt en uges tid, så begynder loggen at give nogle hints til hvordan hjemmesiden som helhed bliver brugt. En ting jeg selv er overrasket over er

urls.png (14.79 KiB) Vist 452 gange

Så 40% af tiden hjemmesiden bliver brugt, der viser den et indlæg. Det må jo igen betyde at selv små ændringer i viewtopic.php vil kunne gøre en forskel. Filen er 1889 linier lang, fylder 73.6kb og står for 60% af den forbrugte båndbredde.

Problemet hvis man optimerer en fil som viewtopic.php, bliver at man selv hænger på at patche den med jævne mellemrum, så man skal virkelig have lyst til det. Men for ***** hvor kunne det betyde meget for sådan en side her hvis den kørte som maskinkode, ingen tvivl om det.

Men findes der ikke fortolkere som kan PHP --> C++ ?
For så kunne man vel i princippet fortolke PHP-koden til C++ første gang den skal bruges, og så gemme den som en cache i fx 24 eller 72 timer.

[lath]

Det pakkede dump af de 100.000+ indlæg fylder næsten 30mb.

Kun 30 MB?
Det var ikke så meget, hvis vi nu siger xz komprimeringsalgoritme er det nok en 10x større i dekomprimeret tilstand, det vil sige at 300 MB er nok ikke helt forkert.
Jeg tænker ikke at de 100.000+ indlæg er 100.000+ filer, for så ædes der en hel del ekstra diskplads med nogle bytes der ikke bliver brugt i en sektor.

Helt præcis så fylder det gunzippede arkiv 37.8mb, og som databasedump er det så 136.5mb. Det er rent tekst, for uploadede billeder osv. ligger på filsystemet.

Det ser ud til at MySQL ligger hver database i hver sin mappe, og så ligger hver tabel i hver sin fil, for ellers vil jeg give dig ret i at spildpladsen ved 100.000+ små filer ville være relativ stor. På filsystemet fylder tabellen med indlæggende faktisk 280mb, men det er så inklusiv et søgeregister og noget søgecache.

Nu når serveren har kørt en uges tid, så begynder loggen at give nogle hints til hvordan hjemmesiden som helhed bliver brugt. En ting jeg selv er overrasket over er

urls.png

Så 40% af tiden hjemmesiden bliver brugt, der viser den et indlæg. Det må jo igen betyde at selv små ændringer i viewtopic.php vil kunne gøre en forskel. Filen er 1889 linier lang, fylder 73.6kb og står for 60% af den forbrugte båndbredde.

Problemet hvis man optimerer en fil som viewtopic.php, bliver at man selv hænger på at patche den med jævne mellemrum, så man skal virkelig have lyst til det. Men for ***** hvor kunne det betyde meget for sådan en side her hvis den kørte som maskinkode, ingen tvivl om det.

Men findes der ikke fortolkere som kan PHP --> C++ ?
For så kunne man vel i princippet fortolke PHP-koden til C++ første gang den skal bruges, og så gemme den som en cache i fx 24 eller 72 timer.

Den her slags statistik synes jeg naturligvis er interessant, for det betyder at der er mulighed at indkassere nogle markante forbedringer i performance og brug af ressourcer.

Der findes faktisk en oversætter der kan PHP --> C++.
Den hedder "HipHop for PHP" - er Open Source, og er lavet af Facebook: http://www.facebook.com/note.php?note_id=10150415177928920, der har brug for at udnytte deres servere optimalt, da de skal servicere 1. mia. brugere.

Såvidt jeg husker kan den kun udføre en delmængde af PHP, men du kan da altid prøve at køre PHP scriptet igennem "HipHop for PHP" og se hvad oversætteren siger til PHP koden.
Går det godt kan du tage C++ koden igennem en C++ compiler, der producerer x86-64 (64-bit) kode.
Du skal næsten helt sikkert linke mod nogle biblioteker (lib*.so filer).
Er du heldig generer den selv et configure/en makefile script, er du meget heldig så kalder HipHop for PHP selv C++ compileren med de rigtige argumenter og efterlader måske et CGI/FastCGI program, der direkte kan snakke med Apache.
Du slipper dog mulig nok uden om at fortælle HipHop noget om database opsætningen.

Båndbredde
Hvad angår båndbredden så skal vi nok hen til det det semantiske web før der bliver mindre.
Tænk:
Programmer bruger RESTfull webservices til at hente de rå data, og programmet renderer det så for brugeren.
Man kunne f.eks lave det sådan at programmet ved at det snakker med et PHPbb3 forum, og for de andre sider her på vores website er det så Wordpress at den snakker med.
Dermed behøver webserverne kunne at sende informationen, og ikke også generere HTML.

Jeg har studeret hvordan jeg kunne lave web scraping af information fra Wired Science bloggen Rocketshop, og så meget som 60% af HTMLen er støj. Dvs. hvis de sendete kun de nødvendige informationer ville det kun fylde (1-0,6) af 137 KB = 54,8 KB.
Fra et andet projekt ved jeg at markup sprogene har et markant overhead på ca 400% i forhold til binært indkodede data kan kan de 54,8 KB så reduceres til : 54,8 x 0,2 = 10,96 KB

Vi er altså ned på omkring 10/125 (=8 %) af de 137 KB vi startede med.

Mere ekstrem optimering.
Bliver vi mere ekstreme begynder webservices kun at sende det der er ændret og nyt.

Teknikken er så at man sender noget der hedder en hashsum af en tekst (1 per indlæg i en tråd).
Har serveren en anden hashsum for et indlæg end den der blev modtaget fra klienten, så har klienten en gammel kopi og skal derfor have en opdatering af den hashede tekst. Er de hashes derimod ens, kan serveren nøjes med at fortælle klienten at den kopi den har ikke er ændret og derfor skal vises for brugeren.
Sender klienten ikke en hashsum for et indlæg, som serveren har i en tråd (liste) af indlæg, så betyder det derimod at klienten ikke kender til at der er kommet et nyt indlæg i tråden, så de(t) indlæg sendes også med, så klienten er opdateret.

Nu kommer det bedste: En hashsum fylder meget lidt - vi snakker max 64 bytes ved SHA-512, uanset hvor langt (eller kort) et indlæg er.
Det betyder at alle indlæg-hashes for en tråd, som sendes fra klienten til serveren kan indkodes som en PDU (data) i en enkelt HTTP POST fast-transfer IP pakke.

/Lars

[lath]

Læs lige den her GitHub side, det ser ud til at der er klar-til-brug pakker for Ubuntu 12.04
https://github.com/facebook/hiphop-php/wiki

Ok, så har jeg lige læst noget spændende:

Over the past few months we've worked with the Drupal, MediaWiki, phpBB, and WordPress teams to get their software running under HipHop.
This really means helping them remove some dynamic code and fixing bugs found by the compiler.

Fra http://www.facebook.com/note.php?note_id=416880943919

Der er dog en gut her der er kritisk over for HipHop her: http://sevalapsha.wordpress.com/2010/02/03/is-facebook-php-hiphop-bullshit/
Han skriver at C++ (det er rent faktisk maskinkode) generelt er 300x til 500x hurtigere end PHP, så facebooks reduktion på kun 50% burde i stedet være en reduktion på imellem 70 % og 99%.

/Lars

[AJenbo]

Optimering kan være en svære størrelse at have med at gøre. Sender man ændrede indlæg et af gangen kan det være langsommere end at sende dem alle samlet. Hvor meget man får ud af det kommer også an på hvor meget folks browser holder i sin cache.

Vi brugere allerede hash (etag) til at cache en stor del af sidens indhold, hvilket nok også er grunden til at forum posts er den der bruger den største data mængede. Tekst indhold gzip'es også inden det sends hvilket giver en betydelig besparing på data mængende.

Hvor meget spild data der er i HTML kan svinge meget fra side til side. Det er ikke noget jeg har brugt det store ressource på da jeg helere ville have at koden er let at ved vedligeholde i forhold til upstream.

HipHop er bestemt interasant. Den normale måde at accelere php på er ved at holde byte code i ram (gør vi på den nye server). HipHop skulle gerne kunne klar det med et mindre ram forbrug, men hvis programmet skal loades ved hver visning kan det jo koste en del på hastigheden, det samme gælder hvis det er et CGI script vs Apache modul. FastCGI burde dog være noget nær lige så hurtigt. Kritikerens punkt med at 50% er hvad man får med traditionel acceleration tager muligvis heller ikke højde for om denne allerede var i effekt for de 100%, og det kommer også and på hvilken type arbejde siden hovedsaligt står for da ikke alle funktioner er lige langsomme/hurtige.