PHP+MySQL projektaiir didėlis lankomumas

Sergej 'ZaZa' KurakinKaunas PHP::Conf 2009

Projekto pradžia

• Gimsta įdėja. Panaudojame Apache+PHP ir MySQL. Gimsta projektas

• Pradedam nuo mažo tinklapio "Virtual Hosting" serveryje, pvz.:o http://www.serveriai.lt/o http://www.webzona.lt/o http://www.hostex.lt/o http://www.balt.net/

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

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ų

Persikėlimas į atskirą serverį

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į?

Persikeliame į galingesnį serverį

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?

MySQL atskirimas

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.

Munin, MySQL pavyzdys

Munin, MySQL pavyzdys 2

Munin, Memcached pavyzdys

Munin, atminties naudojimas

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.

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

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

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.

NGINX priešais Apache+PHP

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

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ą

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ų.

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

O kas jei viskas padėjo, bet neilgam?

Trečio sprendimo laikas Vėl ieškome priežasties

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.

Scale-UP

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.

Scale-OUT: rašymas

Scale-OUT: Skaitymas

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.

Sharded: paskirstymas lentelėmis

Sharded: paskirstymas atkarpomis

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ų.

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 identifikatoriusBLOB lauke saugomas „serialized“ (iš tikrųjų Python pickled) objektas

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

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

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

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

Apkrovimo paskirstymas su HTTP serveriu

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

Apkrovimo paskirstymas su TCP

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

Apkrovimo paskirstymas su DNS

Pabaigai

• Jus ne vieni, resursų apie apkrovimo paskirstymą yra pakankamai daug

• Nebijokite eksperimentuoti (bent šiltnamio sąlygomis)

• Universalių sprendimų nėra

Ačiū už dėmesį

Klausimai?