The Chaos Ruler & The Dead Poets Society

info

7 mai

Top 100 de supereroi ai IGN

Verifică-ți ceasul verificând lista IGN cu cele mai populare 100 de personaje de benzi desenate: personaje, nu ticăloși - deși Rick Grimes din „The Walking Dead” și Yorick Brown din „Y: The Last Man” sunt oameni destul de obișnuiți;)

Kaloyan 23:04 Comentarii dezactivate pentru Top 100 Super Heroes ai IGN

4 martie

Caching funky în WordPress + nginx/php-fpm fără pluginuri

Dacă mă întrebați dacă sunt împotrivă să faceți totul singur sau să folosiți soluțiile disponibile, răspunsul meu va fi, de obicei, că cel mai bine este să folosiți ceea ce este disponibil și să economisiți timp și efort pentru a face (și a menține) o soluție proprie . "Obișnuit." Iată o poveste de avertizare despre cum a încercat să respecte această regulă și a făcut contrariul.

O prefață.

Am acest proiect pentru animale de companie, care este de 10 site-uri WordPress pe un VPS de 512 MB. Fiecare dintre aceste site-uri are câteva mii de postări și câteva mii de etichete/categorii. Înainte nu era o problemă pentru WordPress să gestioneze astfel de site-uri, dar cu fiecare nouă versiune WordPress devine din ce în ce mai lent. Ultima configurație a fost pe o porțiune de 512 MB de la Slicehost, care la acea vreme (sfârșitul anului 2008) părea cea mai bună soluție.

Folosind APC.

Pentru a-l rula cât mai repede posibil, am implementat APC, deși orice alt cache opcode ar merge bine. „Proiectul” este un set de 10 site-uri WordPress. Din păcate, acest lucru l-a făcut să ruleze mai lent decât inițial. De ce? Imaginați-vă că aveți 2 site-uri, abc.com și xyz.net, ambele rulând cea mai recentă versiune WordPress, așa că aproape totul în interiorul lor este același - totul în afară de temele lor unice și propriul set de pluginuri. Acum, atunci când aceștia rulează pe aceeași mașină, APC va trebui să stocheze fișierele pentru ambele, de ex. /var/www/abc.com/html/wp-login.php și /var/www/xyz.net/html/wp-login.php - și acesta este același pentru orice alt fișier din distribuția WordPress. La început este evident că aceasta este doar o risipă de spațiu, deoarece acestea sunt identice. La al doilea aspect, totuși, vedeți dezavantajul mai rău: aceste fișiere identice vor ocupa de două ori mai mult spațiu. Acest lucru va face ca memoria APC să se epuizeze foarte repede și, din această cauză, scade creșterea performanței pe care ne așteptăm să o obținem din a avea o memorie cache opcode. Acum, în loc să aveți doar 2 site-uri, imaginați-vă că aveți 10 site-uri: copiile cache din APC au fost curățate înainte de a fi chiar lovite, deoarece spațiul din cache-ul bytecode nu era suficient.

Utilizarea APC cu WordPress asociat.

Soluția la problema de mai sus a fost să legați simbolic totul pentru fiecare site, cu excepția configurației din wp-config.php - în acest fel APC nu va trebui să se ocupe de copii duplicate ale acelorași fișiere. Pluginurile și temele sunt, de asemenea, plasate între ele. Iată ce ls -la se pare ca:

Cum va ajuta asta? Foarte simplu: nu mai există duplicate și APC funcționează doar cu un singur set de fișiere. A fost necesară o mică ajustare pentru ca pluginul wp-super-cache să funcționeze, dar pentru o vreme totul a fost în regulă.

Noua configurare.

Recent am mutat proiectul de la Slicehost la Linode: este mult mai accesibil - configurarea pe 32 de biți pentru aproape jumătate din bani (pentru 512 MB). Pentru noua configurație am decis să renunț la Apache și să încerc ceva nou - nginx + phpfpm. Nu a fost suficient și a decis să renunțe wp-super-cache și încercați w3-total-cache cu toate straturile diferite de creștere a performanței pe care le oferă. Linode face foarte ușor de implementat o configurare LEMP și, cu ajutorul unui prieten de-al meu, am fost gata să plec. Apoi am instalat w3-total-cache și problemele au început:

  • trebuie să îți faci propriile reguli de rescriere pentru nginx
  • „pagina cache” nu folosea numele de domeniu pentru site, așa că paginile cache greșite au apărut în locuri greșite, de ex. abc.com/2008/10/ a deschis pagina de pe xyz.net/2008/10/
  • performanța a fost degradată, nu îmbunătățită

Cheltuiesc cel mai bun din ultimele 2 zile pentru a încerca să găsesc o cale de a rezolva această problemă. Se pare că W3TC pregătește numele domeniului numai atunci când WordPress este o instalare WPMU/Multisite. Nu vreau să mă scufund în asta, așa că, după 30 de minute de gândire, am decis să renunț la W3TC și să fac o „pagină cache” (funky caching într-adevăr) pe cont propriu. După câteva ore am fost gata și funcționează ca un farmec. Funcționează cam așa wp-super-cache, dar fără toate setările și paginile de administrare - știu cum se comportă proiectele mele, așa că nu am avut nevoie de toate lucrurile pentru purificarea cache-ului la adăugarea de comentarii, schimbarea stărilor, scrierea de postări noi sau orice altceva. Am personalizat o parte din W3TC pentru curățarea fișierelor statice de pe disc, dar în loc să mă bazez pe pseudo-cron-ul WordPress am decis să folosesc în schimb crontab-ul VPS: și este foarte ușor - trebuie doar să apelați scriptul;)

Scenariul și modul de configurare personal ?

Mai întâi trebuie să activați WP_CACHE în fișierul dvs. wp-config.php, deoarece aceasta este cerința pentru ca WordPress să includă scriptul nostru. Scriptul se numește advanced-cache.php (WordPress l-a numit așa) și trebuie să fie plasat în interiorul/folderul wp-content. Puteți găsi regulile de rescriere pentru nginx în interiorul scriptului ca un comentariu (dacă vă întrebați ce înseamnă HB, aceasta este o abreviere pentru proiectul pentru animale de companie).

Deci, dracu 'W3TC;)

PS. Se pare că altcineva a găsit această soluție de link simbolic cu mult timp înaintea mea și este de fapt documentată pe Codex-ul WordPress:

3 decembrie

Sfârșitul blogului așa cum îl cunoaștem sau căutarea unui nou început

19 octombrie

Raportarea în carantină sau înregistrarea în carantină

Nu am mai scris de multă vreme pe blog, ca să nu repet banalul „No Time!”, Dar nu am cum - viața mea curge de la banalitate la banalitate în timp ce ne întrebăm cum să fim originali;) Oricum, astăzi am decis să încerc ceva nou și am publicat prima mea postare în limba engleză, în încercarea de a combina utilul cu plăcutul: sper că ceea ce este scris despre Logarea în carantină vă interesează;) accept orice critică.

De când ne-am trimis o fotografie pentru septembrie, o să „împrumut” una de pe Facebook;)

Înregistrare în carantină

Cu siguranță, în zilele noastre, toată lumea știe că proiectul dvs. PHP ar trebui dezvoltat cu raportarea erorilor setată pentru a raporta totul cu E_ALL | E_STRICT (cred că zilele neîncetate de freelance s-au încheiat). Când proiectul este implementat pe un server live, puteți seta raportarea erorilor să înregistreze numai erorile severe (erori fatale și excepții) sau îl puteți lăsa cu raportarea detaliată a erorilor. Deși nu eram un fan al acestuia din urmă, am apreciat cât de util este atunci când urmăresc erorile, deoarece există cu siguranță o notificare sau un avertisment pentru a vă sugera în direcția corectă. Este de două ori mai important dacă proiectul dvs. este o soluție SaaS și sunteți responsabil nu numai pentru dezvoltarea aplicației, ci și pentru găzduirea acesteia și punerea la dispoziția clienților dvs. În această situație, înregistrarea detaliată este la fel de neprețuită ca efectuarea copiilor de rezervă: probabil că în 95% din timp nu veți avea nevoie de ea, dar când „zâna dracului” vine să bată, este mai bine să fiți pregătiți.

Apropo de copiile de rezervă, înregistrarea detaliată probabil le împărtășește încă o caracteristică - spațiul uriaș pe care îl ocupă. Pentru o aplicație care funcționează fără hick-up-uri timp de câteva luni, volumul jurnalelor este de câteva ori mai mare decât restul datelor aplicației. Volumul datelor de înregistrare detaliate devine și mai mare atunci când sunt utilizate aplicații, plugin-uri sau suplimente terță parte, deoarece acestea nu respectă întotdeauna politica E_ALL | E_STRICT, iar unele dintre ele ar putea produce tone și tone de avertismente repetitive și notificări. În funcție de mediul de stocare pe care este stocată înregistrarea detaliată, ar putea provoca degradarea performanței în aplicație atunci când volumul său scade din proporții.

Aceasta este problema cu care m-am confruntat recent. Vreau ca aplicația să ruleze cât mai repede posibil, să nu fie împovărată de înregistrarea detaliată, dar totuși vreau să pot avea toate datele de care am nevoie pentru urmărirea erorilor și problemelor. Soluția cu care am venit se numește Înregistrare în carantină.

În general, vreau să păstrez toate datele necesare pentru urmărirea și remedierea problemelor. Deci, când tind să apară aceste „probleme”? Sunt sigur că împărtășiți aceleași observații ca și mine: problemele apar atunci când aplicația este implementată: când este instalată sau când este actualizată. Când începe să ruleze, remediați problemele care apar și, cu cât rulează mai mult, există mai puține șanse ca ceva să meargă spre sud. Oricum, asta nu este întotdeauna - asta este doar pentru majoritatea timpului: de obicei bug-urile își arată capul urât atunci când te aștepți mai puțin;) Deci, dacă ne putem aștepta la probleme cu o anumită probabilitate pentru o anumită perioadă de timp (de exemplu, după implementare), atunci să activăm înregistrarea detaliată numai pentru acel moment. Prin urmare, "Carantină";)

Carantina este momentul după actualizarea aplicației sau, cu alte cuvinte, timpul după introducerea presupuselor probleme. Până când aplicația se află în carantină, va utiliza înregistrări detaliate pentru a raporta tot ce se întâmplă. Odată ce carantina s-a încheiat, putem reduce înregistrarea la doar urgențele severe: erori și excepții neprinse. Este un compromis echitabil: primiți toate jurnalele detaliate pentru N zile (o săptămână) în timp ce vă aflați în carantină și apoi numai cele mai urâte lucruri;)

Pentru ca acest lucru să funcționeze după fiecare implementare, instalare sau actualizare, trebuie să puneți aplicația în carantină, unde alegeți ce perioadă se va potrivi nevoilor dvs. - în a mea sunt (așa cum s-a sugerat mai sus) 7 zile. Asta nu este tot: deși nu se află în carantină, se poate întâmpla o eroare sau o excepție neprinsă. Înregistrarea numai severă o va raporta, dar, în plus, va pune aplicația într-o stare de "Carantină autoimpusă" pentru M zile (2 de exemplu): în acest timp ne așteptăm ca eroarea/excepția să se repete, așa că facem din nou înregistrarea detaliată în timp ce ne aflăm în carantină.

Deci, asta este totul pentru înregistrarea în carantină. Nu vă voi deranja cu o implementare concretă, sunt sigur că puteți reuși să o faceți singur pentru raportarea erorilor. Eu însumi tocmai am implementat această caracteristică și voi vedea cum se comportă în următoarele câteva luni.