PHP+MySQL projektai ir didėlis lankomumas

1. Sergej 'ZaZa' Kurakin Kaunas PHP::Conf 2009 PHP+MySQL projektaiir didėlis lankomumas

2. Projekto pradžia • Gimsta įdėja. Panaudojame Apache+PHP ir MySQL. Gimsta projektas • Pradedam nuo mažo tinklapio "Virtual Hosting" serveryje, pvz.: • http://www.serveriai.lt/ • http://www.webzona.lt/ • http://www.hostex.lt/ • http://www.balt.net/

3. Projekto gyvavimas Projektas tampa populiaresnis ir jam "neužtenka" resursų, nes jame tuo pat metu lankosi labai daug žmonių • SlashDot efektas: Apie Jūsų projektą parašo koks populiarus dienraštis ar keli populiarūs blogai ir vienų metų ateina lankytojų lavina • Teikiat labai populiarias/unikalias paslaugas

4. Pirmas sprendimas • Persikeliame į nuosavą galingą serverį: 2 procesorius (8 branduoliai), 3 talpius ir greitus standžius diskus, 8GiB atminties • Projektas tampa populiaresnis ir jam vėl "neužtenka" resursų - vieno turimo serverio, ir priežastis ta pati - tuo pat metu lankosi dar daugiau žmonių

5. Persikėlimas į atskirą serverį

6. Ką dar galime padaryti? Pradėti kažką keisti tinklapyje/serveryje: • riboti prisijungimų skaičių • mažinti funkcionalumo/galimybių skaičių • optimizuoti kodą • pirkti papildomas serverio dalis: atmintį, kietus diskus Pirkti dar galingesnį serverį?

7. Persikeliame į galingesnį serverį

8. Antras sprendimas • Atskiriame Apache+PHP ir MySQL. MySQL perkeliame į naują serverį • Darom "Pimp MySQL" jei tai galime/norime - tam reikia žinių ir laiko, resursų šia tema internete yra daug • Tuo metų projektas gali (ir turi) populiarėti, pritraukdamas vis daugiau lankytojų. Ką galima daryti?

9. MySQL atskirimas

10. 7 kart matuojam, 1 kartą keičiam Prieš bet kokį pakeitimą reikia įsitikinti, kad jis yra būtinas ir išspręs iškilusią (ar gręsiančią) problemą, todėl serverių veikimą turi stebėti ne tik serverio administratorius. Be to, tam reikia turėti atitinkamus įrankius (ne tik iostat, vmstat, netstat). Mes naudojame programinę įrangą Munin (http://munin.projects.linpro.no/). Gražūs ir informatyvūs grafikai. Didelis, palaikomas per įskiepius, programinės įrangos sąrašas.

11. Munin, MySQL pavyzdys

12. Munin, MySQL pavyzdys 2

13. Munin, Memcached pavyzdys

14. Munin, atminties naudojimas

15. Optimizuoti viską ką galime • Patikrinti SQL užklausas ir INDEX naudojimą - ar nėra nereikalingų INDEX, ar visos SQL naudoja INDEX • Patikrinkite, ar MySQL išnaudoja "Query Cache"  • Patikrinam MySQL "slow query" ir jas stengiamės panaikinti • Panaudoti PHP kodo optimizavimo/podėliavimo sprendimus:eAccelerator, XCache, ionCube, Zend Platform Kartais šio gali pakakti. Ypač jei kodą kūrė nepatyrę programuotojai arba kodas yra kelių metų senumo.

16. Apie ką turėtų prabilti "Client-Side" guru • Optimizuokite JavaScript failus su Yahoo UI Compressor bet ne su "packer" (eval(function(p,a,c,k,e,r)...)‏ • Optimizuokite CSS failų kiekį • Naudokite HTTP protokolo galimybę suspausti turinį (tik atsargiai su Microsoft Internet Explorer)‏ • Nustatykite teisingas cache/podėlio kliento pusėje HTTP antraštes • Išnaudokite CDN, jei to reikia, bet būkite atsargūs

17. Keičiame Apache+PHP Apache+PHP (mod_php) kartais yra per "brangus" resursų atžvilgiu: • Vartoja daug atminties kai to nereikia, pvz.: statiniai failai • Nevisada išnaudoja visas OS savybes • Lėtokas • "Reverse proxy" atsirado per vėlai • Turi "problemą" su adresais ir "reverse proxy" režimu

18. Keičiame Apache+PHP į ... Galime pasinaudoti Squid, bet tai pareikalaus dar vieno serverio. Todėl dažnais "prieš" Apache pastatomas NGINX arba Lighttpd. Jie sukonfigūruoti taip, kad visas statinis turinys (CSS, JavaScript, paveiksliukai) būtų aptarnaujamas jų pagalba, o visos PHP rinkmenos perduodamos į Apache+mod_php. Apache perkeliamas į 127.0.0.1 adresą, NGINX/Lighttpd veikia kaip "reverce proxy". Jei aš neklystu lrytas.lt naudoja būtent tokią konfigūraciją. Kitas būdas - naudojamas PHP su FastCGI ir Apache arba NGINX arba Lighttpd.

19. NGINX priešais Apache+PHP

20. Kas yra blogai su PHP FastCGI Standartinis PHP FastCGI: • Neturi "log" rinkmenos • Neturi "pid" rinkmenos • Dažniausiai reikia specialaus paleidimo, kurį turi Lighttpd arba Perl/sh skriptas • Problematiška padaryti "chroot" • Negali gražiai (angl. graceful) restartuoti Todėl mes naudojame PHP-FPM http://www.php-fpm.com, kuris išsprendžia dalį problemų. Bet, kadangi tai yra tik "patch", kyla problemų su PECL paketais - juos yra sunku sukompiliuoti "static" būdu

21. Apache pakeitimas Kadangi visur naudojame PHP FactCGI, Apache tampa kaip ir nebereikalingas. Dažniausiai jį keičia į NGINX (Lighttpd). Nepatogumai: • Nėra .htaccess failų palaikymo (nors iš tiesų tai yra pliusas)‏ • Skirtinga konfigūracinio failo sintaksė Pliusai: • Naudoja mažiau atminties • Naudoja mažiau CPU • Ypatingas statinių failų palaikymas  • Buvo kuriami atsižvelgiant iš karto į našumą

22. Cache / Podėlis Dažnai yra duomenys, kurie yra atnaujinami žymiai rečiau nei nuskaitomi, o jų nuskaitymui naudojamos sudėtingos SQL užklausos ar skaičiavimai. Tam, kad juos kiekvieną kartą nepergeneruoti, duomenis galima sudėti į podėlį - laikiną saugyklą, iš kurios jie yra pasiekiami žymiai greičiau. Į podėlį galima sudėlioti tam tikras puslapio dalis ar net visą puslapį. Podėlį galima specialiai atnaujinti tam, kad duomenys jame nepasentų ir vartotojas nieko nepajustų.

23. Cache / Podėlis Populiarios podėliavimo sistemos: • APC - Alternative PHP Cache • Memcached • Shared Memory • Failai • Elementarūs serialized() duomenys • HTML kodo dalis • PHP kodo dalis

24. O kas jei viskas padėjo, bet neilgam? Trečio sprendimo laikas Vėl ieškome priežasties

25. Neužtenka vieno MySQL serverio? Scale-up! Perkam galingesnį serverį: daugiau atminties, daugiau galingesnių procesorių (branduolių), pasirenkame greitesnius diskus arba RAID technologiją. Taip, kartais tai atsiperka. Mums atsipirko.

26. Scale-UP

27. Neužtenka vieno MySQL serverio? Scale-out! Nusiperkant bent dar 2 serverius, įdiegėte MySQL ir sukonfigūruojate viską taip, kad vyktų duomenų replikacija iš seno MySQL serverio (master) į naujus MySQL serverius (slave). Jūsų projektas viska irgi turi rašyti į seną MySQL serverį (master), o skaityti iš naujų dviejų (slave), tarp jų tolygiai paskirstydamas apkrovimą. Tokioje konfigūracijoje jus visada galite pridėti dar vieną naują MySQL serverį skaitymui (slave). Dėja, pačiam išbandyti realiame projekte neteko, nors buvau pasiruošęs.

28. Scale-OUT: rašymas

29. Scale-OUT: Skaitymas

30. Neužtenka vieno MySQL serverio? Shard! Vienas iš tamsiausių ir sudėtingiausių būdų. Per kelis MySQL serverius paskirstoma MySQL duomenų bazė (remiantis lentelėmis, data, atkarpomis). Pamirštama apie beveik visas SQL kalbos galimybes (jokių TRIGER, jokių JOIN) ir viskas daroma PHP pusėje. Tokias sistemas sudėtingiau palaikyti ar vystyti. Gan įdomus būdas, kurį irgi teko išbandyti. Patariu naudoti tik jei visi kiti būdai jums netinka.

31. Sharded: paskirstymas lentelėmis

32. Sharded: paskirstymas atkarpomis

33. Neužtenka vieno MySQL serverio? Cluster... Nieko čia neišmanau ir neteko bandyti. Skaitykite: http://www.mysql.com/products/database/cluster/ Labai labai labai noriu išbandyti. Žinau projektą kur to labai labai labai reikia, bet, kol kas nėra techninių galimybių.

34. Neužtenka vieno MySQL serverio? Sukurk savo... FriendFeed.com turi savo duomenų bazę, sukurta naudojant MySQL lenteles iš 2 laukų: ID ir BLOB lauko ID yra unikalus įrašo identifikatorius BLOB lauke saugomas „serialized“ (iš tikrųjų Python pickled) objektas

35. Dar apie MySQL Labai mėgsta atmintį. Pasistenkite, kad atminties užtektų: • Operacinei sistemai • Visai MySQL bazei į atmintį sukelti • MySQL užklausų podėliui (Query Cache)‏ • Ir dar būtų atsargų Stebėkite, ar užtenka disko resursų, ar neatsitinka taip, kad sistemos procesai ilgai laukia savo eilės išnaudoti standųjį diską Darykite atsargines kopijas

36. Neužtenka vieno serverio su PHP? Nieko nuostabaus, čia irgi būna karšta. Priklausomai nuo naudojamų PHP plėtinių (extensions) vykdomosios PHP rinkmenos dydis gali būti labai skirtingas.  Kiekvienai užklausai apdoroti reikia skirti tiek atminties, kiek reikalauja vykdomoji PHP rinkmena plius tai, ką mes ten suprogramavome. Net jei vykdomoji PHP rinkmena su įkrautais plėtiniais (extensions) bus 25MB o skriptas dar sunaudos 1MB esant 50 užklausų vienu metu tai bus 1300MB

37. Sprendimai Galingesnį serverį nusipirkti gali visi, todėl žiūrėkime giliau... • Galime įdiegti Apache+PHP(mod_php) į kelis serverius ir NGINX/Lighttpd pagalba tarp jų paskirstyti apkrovimą • FastCGI gali būti iškeltas į kelis papildomus serverius tarp jų paskirstant apkrovimą NGINX/Lighttpd pagalba • Galime sukurti daug sub-domenų ir daryti redirektus (one.lt principas) • Pasiimam kelis serverius su bet kuria HTTP tarnyba ir PHP ir tarp jų paskirstome apkrovimą DNS tarnybos pagalba

38. Apkrovimo paskirstymas su HTTP serveriu • Bet kada galima pridėti naują serverį į apkrovimo paskirstymo grandį (backend) arba jį pašalinti • Apkrovimo paskirstymo serveris seka klaidas ir bando jas ištaisyti • Silpniausia dalis yra Apkrovimo paskirstymo serveris • Nevisai prasmingai naudojami resursai apkrovimo paskirstymo grandyje

39. Apkrovimo paskirstymas su HTTP serveriu

40. Apkrovimo paskirstymas su TCP • Bet kada galima pridėti naują serverį į apkrovimo paskirstymo grandį (backend) arba jį pašalinti • Apkrovimo paskirstymo serveris seka klaidas ir bando jas ištaisyti • Silpniausia dalis yra Apkrovimo paskirstymo serveris • Prasmingiau išnaudojami resursai apkrovimo paskirstymo grandyje, kadangi ten yra tik PHP

41. Apkrovimo paskirstymas su TCP

42. Apkrovimo paskirstymas su DNS • Bet kada galima tik pridėti naują serverį į apkrovimo paskirstymo grandį (backend)‏ • Apkrovimo paskirstymo serveris gali sekti klaidas, bet klaidų pašalinimas nėra toks sklandus • Nepamirškime, kad yra trečios šalies kešuojantys DNS serveriai, kurių nevaldome

43. Apkrovimo paskirstymas su DNS

44. Pabaigai • Jus ne vieni, resursų apie apkrovimo paskirstymą yra pakankamai daug • Nebijokite eksperimentuoti (bent šiltnamio sąlygomis)‏ • Universalių sprendimų nėra

45. Klausimai? Ačiū už dėmesį