old.kaloyan.info

A Káosz uralkodó és a Holt költők társasága

Május 7

Az IGN legjobb 100 szuperhőse

Ellenőrizze az óráját az IGN 100 legnépszerűbb képregény-karakterének listáján: karakterek, nem gazemberek - bár Rick Grimes a "The Walking Dead" -ből és Yorick Brown az "Y: Az utolsó ember" -ből meglehetősen hétköznapi emberek;)

Kaloyan 23:04 Megjegyzések kikapcsolva az IGN Top 100 szuperhőséről

Március 4

Funky gyorsítótár a WordPress + nginx/php-fpm-ben pluginek nélkül

Ha azt kérdezi tőlem, hogy ellenzem-e mindent, ha mindent megteszek, vagy a rendelkezésre álló megoldásokat használom, a válaszom általában az lesz, hogy a legjobb, ha felhasználjuk a rendelkezésre álló lehetőségeket, és időt és erőfeszítést spórolunk magunknak egy saját megoldás elkészítésére (és fenntartására). . "Általában." Itt egy figyelmeztető mese arról, hogyan próbálta betartani ezt a szabályt, és az ellenkezőjét tette.

Egy előszó.

Van egy kisállat projektem, amely 10 WordPress webhely egy 512 MB VPS-en. Mindegyik webhely több ezer bejegyzéssel és néhány ezer címkével/kategóriával rendelkezik. Régebben nem okozott problémát a WordPress az ilyen oldalak kezelésében, de a WordPress minden egyes új verzióval egyre lassabban halad. Az utolsó konfiguráció a Slicehost 512 MB-os szeletén volt, amely akkor (2008 végén) a legjobb megoldásnak tűnt.

Az APC használata.

A lehető leggyorsabb futtatásához telepítettem az APC-t, bár bármely más opcode gyorsítótár jól működne. A "projekt" 10 WordPress-webhelyből áll. Sajnos ez lassabban futott, mint eredetileg. Miért? Képzelje el, hogy van 2 webhelyünk, az abc.com és az xyz.net, amelyek egyaránt a legfrissebb WordPress-t futtatják, így szinte minden bennük ugyanaz - minden, kivéve a saját egyedi témáikat és a saját beépülő moduljukat. Most, amikor az ugyanazon a gépen futnak, az APC-nek mindkettőjük számára el kell tárolniuk a fájlokat, pl. /var/www/abc.com/html/wp-login.php és /var/www/xyz.net/html/wp-login.php - és ez megegyezik a WordPress disztribúció minden más fájljával. Eleinte nyilvánvaló, hogy ez csak helykidobás, mivel azok megegyeznek. Második pillantásra azonban a rosszabb hátrányt látja: ezek az azonos fájlok kétszer annyi helyet foglalnak el. Ez az APC memóriájának nagyon gyors kimerülését eredményezi, és emiatt csökken a teljesítménynövekedés, amelyet várhatóan kapunk egy opcode gyorsítótár használatával. Most ahelyett, hogy csak 2 webhely lenne, képzelje el, hogy 10 webhelye van: az APC-ben lévő gyorsítótárban tárolt példányokat megtisztították, mielőtt még eltalálták volna őket, mert a bájtkód gyorsítótárban a hely nem volt elég.

Az APC használata a linkelt WordPress alkalmazással.

A fenti probléma megoldása az volt, hogy minden webhelyet szinkronizálni kellett, kivéve a wp-config.php-ből származó konfigurációt - ily módon az APC-nek nem kell ugyanazon fájlok másolatával foglalkoznia. A beépülő modulok és a témák szintén egymás között vannak. Itt van, amit a ls -la úgy néz ki, mint a:

Hogy fog ez segíteni? Nagyon egyszerű: nincs több másolat, és az APC csak egy fájlkészlettel működik. A wp-super-cache plugin működéséhez szükség volt egy kis csípésre, de egy ideig minden rendben volt.

Az új beállítás.

Nemrég a Slicehostról a Linode-ra költöztettem a projektet: sokkal megfizethetőbb - 32 bites beállítás a pénz majdnem feléhez (512 MB-ért). Az új beállításnál úgy döntöttem, hogy elárasztom az Apache-t, és megpróbálok valami újat nginx + phpfpm. Ez nem volt elég, és úgy döntött, hogy elárasztja wp-super-cache és próbáld ki a w3-total-cache fájlt a teljesítménynövelés minden különféle rétegével, amelyet kínál. A Linode nagyon megkönnyíti a LEMP-telepítés telepítését, és egy barátom némi segítségével készen állok az indulásra. Aztán telepítettem w3-total-cache és a problémák elkezdődtek:

• meg kell csinálnod a saját átírási szabályaidat nginx
• az "oldal gyorsítótár" nem a domain nevet használta a webhelyhez, ezért a rossz gyorsítótárazott oldalak rossz helyeken jelentek meg, pl. abc.com/2008/10/ megnyitotta az oldalt az xyz.net/2008/10/ oldalról
• a teljesítmény romlott, nem javult

Az elmúlt 2 nap legjobbjait arra fordítom, hogy megpróbáljam megtalálni a módját ennek a problémának. Úgy tűnik, hogy a W3TC csak akkor készíti elő a domain nevet, ha a WordPress WPMU/Multisite telepítés. Nem akarok belemerülni ebbe, így 30 perc múlva úgy gondoltam, hogy eldöntöttem a W3TC-t, és egyedül elvégeztem az "oldal gyorsítótárát" (a funky gyorsítótárazását). Több óra múlva készen álltam, és varázslatként működik. Nagyjából úgy működik, mint wp-super-cache, de minden beállítás és admin oldal nélkül - tudom, hogyan viselkednek a projektjeim, így nem volt szükségem mindenre a gyorsítótár kiürítéséhez a megjegyzések hozzáadásakor, az állapotok megváltoztatásában, az új bejegyzések írásában vagy bármi másban. A W3TC egy részét a lemezen lévő statikus fájlok tisztítására testreszabtam, de a WordPress ál-cronjára támaszkodva inkább a VPS crontab-ot használtam: és ez nagyon egyszerű - csak meg kell hívnod a szkriptet;)

---