TitanusEramius skrev:lath skrev:TitanusEramius skrev: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åndbreddeHvad 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
