Názory k článku Memcached: zrychlete svůj web pomocí cache
-
"""
server {
location / {
set $memcached_key "$uri?$args";
memcached_pass localhost:11211;
default_type text/html;
error_page 404 @fallback;
}location @fallback {
proxy_pass http://www.root.cz;
}
}
"""Jde to pouzit jako nahrada squid cache proxy serveru, nebo jen jako cache pro webove aplikace?
-
Michal Kára (neregistrovaný)
Pokud to dobře chápu, tak takovéhle cachování uchovává všechny stránky bez ohledu na to, co říkají hlavičky v odpovědi. Takže v určitých situacích se to nahradit dá, ale pokud stejné URL může v závislosti na jiných proměnných vracet různé odpovědi, tak by to moc nefungovalo.
-
Kozzi (neregistrovaný)
tak jako string to vraci tusim do ted, coz zrovna u php nijak vetsinou nevadi, a to omezeni na 1MB je defaultni nastaveni, ale da se zmenit. Ale memcached je efektivni hlavne pro mensi data to znamena ze neni prilis vhodne to omezeni na 1MB nejak rapidne zvedat. Pokud je potreba cachovat obcas vetsi data a casteji mensi data, tak je lepsi mit memcached dvakrat, jednu pro mala data a druhou pro potencionalne velka data
-
No práve to pretypovanie nám výrazne vadilo. Prechádzali sme totiž z eAccelerator, ktorý ukončil podporu KEYS (tam všetko fungovalo tip-top) na niečo iné, čo bude dlhšiu dobu podporované. A práve to, že na niektorých distribúciach to vracalo string namiesto int a na niektorých to vracalo int, nás viedlo k tomu nájsť niečo alternatívne. Takže sme nakoniec urobili podporu aj pre REDIS, dokonca bol mierne rýchlejší ako memcached.
-
Kozzi (neregistrovaný)
jj REDIS je fajn, taky jsem o nem uvazoval, ale zatim nebyl cas zjistovat zda by byl rychlejsi. Na druhou stranu jsme si v jazyku D napsal v podstate vlastni alternativu memcached, ktera byla taky nekolika nasobne rychlejsi jak memcached, tak si rikam jestli ji casem nedokoncim a nevydam pod nejakou svobodnou licenci.
To stim typem je zvlastni, nejspis to souviselo s typem pouzite serializace, protoze pokud je to jednou opravdu int, tak standardni php serializer to prevede imho i s typem, takze by to melo fungovat ok.
-
Lao-c (neregistrovaný)
A neni to proste jen pouzitim jine ext?
http://code.google.com/p/memcached/wiki/PHPClientComparison
viz tabulka - posledni radek
Stores Numerics
pecl/memcache vs pecl/memcached
Converted to Strings vs Yes -
No co si pamatam, tak viem, ze memcached na debiane to convertoval na str a na gentoo to nerobil. Tie iste prikazy.
V kazdom pripade to povazujem za chybu a nie vlastnost. Pretoze ked do toho ulozim string, vrati sa mi string. Ked do toho ulozim pole, vrati sa mi pole. Ked tam dam zlozite pole, vrati sa mi zlozite pole. Ale ked do toho vlozim int, NEOCAKAVAM string, je to proti logike. Hlavne ked na inom systeme to funguje inak. -
moje testy v Drupalu7, pravda na windows serveru s IIS a php 5.3, vychazely tak ze bylo APC a wincache na podobne rychlosti, memcached a mongoDB cca 5x pomalejsi. Mongo mi kousek mene vytezovalo procak. nakonec jedu v mongo protoze ma vic moznosti(lze ho pouzivat konrektne v drupalu nejen na cache).
Zajimave je, ze jsem ted cetl clanek kde meli na centOS pomerne velky rozdil pri pouziti php-memcached vs php-memcache (D na konci, a jednalo se jen o php extension - pri pouziti memcacheD daemona bylo php-memcache bez D na konci vyrazne lepsi)
-
Kozzi (neregistrovaný)
S autorem clanku souhlasim, memcached je opravdu skvely nastroj, ktery je vhodny pro zlepseni vykonu webove aplikace. Od doby co jsme jej nasadili v praci nam klesla zatez ba web serverech i datbazich docela rapidne. Memcached se nam osvedcila i jako uloziste pro php session, takze pokud mate vykonnostni problemy mohu jen doporucit. Jedine na co je dat si pozor je, aby vase aplikace nebyla na memcached primo zavisla a jela i bez ni. Doporucuji si toto obcas overit, aby jste se jednoho dne nedivili :).
Jinak za tu dobu co memcached pouzivame jsme hodne kodu vylepsili a prepsali, takze kdyz jsem nedavno zkousel nasi aplikaci bez memcached, tak uz ten rozdil nebyl tak markantni jako drive, takze nakonec je to hodne i o tom jak kvalitni a rychly kod jste schopni psat.
Suma sumarum pouziti memcached je super vec, ale jeho pouziti neznamena ze neni potreba investovat cas do zlepseni vykonu samotne aplikace na urovni kodu.
-
Kozzi (neregistrovaný)
Dalsi vec co v pripade php webu hodne pomaha jsou akceleratory (XCache,EAccelerator,APC). V nasem pripade to dela opravdu velky rozdil, pri pouziti akceleratoru jedou nase servery na zatezi (systemload) okolo 1, pokud ale akcelerator neni zapnuty tak se zatez pohybuje okolo 30, protoze se pozadavky nestaci odbavovat vcas. Jinak co se tyce volby akceleratoru tak to je komplikovane, vsechny tri vyse zminovane podoavaji velmi podobne zrychleni, ale napriklad eaccelerator zatim ma potize s php 5.4 a s anonymnima funkcema, ale uz se zase zacal vyvijet, takze snad se to brzy opravi. APC skoro vubec nefunguje s PHP 5.4 a XCache ma s php 5.4 take nejake potize. Co se tyce starsich verzi PHP tak vsechny 3 akceleratory funguji ok.
Jinak nektere znich umoznuji take cachovat data, tak jako to dela memcached, ale jen na lokalnim stroji, coz nemusi byt pro vsechny pouzitelne.
-
Yenya (neregistrovaný)
Memcached používáme, akorát jsem narazil na jeden problém - potřeboval bych mít možnost zneplatnit všechny záznamy určitého typu. Což nejde, protože není cesta jak procházet například všechny nacachované položky. Nakonec jsem se rozhodl realizovat to tak, že mám speciální objekt s časovým razítkem, a při načtení skutečného objektu kontroluju jeho časové razítko proti tomu centrálnímu. A invalidaci řeším prostou aktualizací toho centrálního razítka.
Ale je to jeden request navíc v hot-path, namísto nějaké větší práce někde na pozadí.
-Yenya, http://www.fi.muni.cz/~kas/blog/
-
ono neni dulezite se na zacatku trapit s vyberem cache backend. dulezite je napsat si nejake cache-API (get, set, delete) do ktereho pak zmenou jednoho parametru configu napojim cokoliv pro co si dopisu podporu. abych pri zmene backendu nemusel prepisovat pul aplikace...
(treba v Drupalu jsem zjistil, ze APC je pro me na jednom projektu nepouzitelne protoze potrebuju jet tak abych se mohl pro updaty atp spolehnout na drush only. no php-CLI ma jinou cache nez php v apache takze z terminalu neumim smazat jednoduse nejaky polozky z cache kterou vidi web - to me u memcached nebo mongo nepotka)
(tento prispevek byl oznacen za spam protoze cache-api bez pomlcky obsahuje LEVNY anglicky :) )
-
franc (neregistrovaný)
Pokud se memcached spoji s nginx a vraci tedy stranky z cache, tak to je super, v podstate se nemusi dojit k tomu, ze dotaz probubla az napr. do PHP/db, ale mam dotaz jak tahle kombinace pozna (resp. nginx), ze uz data v memcached nejsou platna?
V pripade kdy memcached mam primo v aplikaci tak to chapu, ze pri zmene dat rovnou znevalidnim data v cache ale takto? Jak to vlastne obecne resi reverzni proxy, nejak pres http header?
Diky za info.
-
Franta (neregistrovaný)
Nginx to právě nijak nepozná a to je trochu na nic (maximálně pro hodně statické soubory, u kterých člověku nevadí, že musí ručně otočit nebo promazat memcache).
Bohužel tohle je obecný problém – často je totiž zjištění, zda se data změnila, stejně „drahé“ jako vytažení samotných dat.
Ano, v HTTP se to řeší přes hlavičky – buď zdrojový server předem deklaruje dobu trvanlivosti a pak ho proxy server už neotravuje, nebo ne (pro data, která se mohou kdykoli změnit) a pak se proxy server vždy ptá, zda je něco nového – do databáze nebo na disk u zdroje se tedy musí sáhnout, ale po síti se zbytečná data nepřenášejí.
Mezipaměť má tedy smysl ve chvíli, kdy potřebujeme šetřit síť, nebo když data procházejí nějakou složitější transformací – kterou můžeme ušetřit a pouze se podívat, zda se změnil soubor nebo záznamy v databázi (proti tomu zase jde fakt, že hodně obsahu je příliš komplexního a složeného z příliš mnoha různých částí a zdrojů, že všechny spolehlivě zkontrolovat vyjde stejně draho jako poskládat ten obsah kompletně).
-
ebik (neregistrovaný)
znevalidnit lze i data v memcachi pro nginx. Ale implementace takoveho znevalidneni asi bude vyzadovat stejne (nebo vice) prace jako implementace cache primo do aplikace. Jedina vyhoda je, ze vlastni aplikace se nespusti dokud jsou data platna. Nginx + memcached by mohlo byt dobre reseni pro cachovani statickych souboru: pri vhodne zvolene velikosti memcache budou nejpouzivanejsi soubory stale v pameti a nedojde ani k osahani fs zda se nezmenily, to muze byt vykonostni vyhoda. Dynamicke stranky bych tim asi nechachoval.
-
Memcache je celkem fajn, ale právě to, že je po restartu prázdný a jeho možnosti škálování, nás vedou k přechodu na Redis. Se škálování Redisu to zatím taky není úplně růžové (brzy snad ale bude Redis cluster), backupování na hdd má vyřené suprově, takže můžete vesele restartovat.
Výkonově taky vychází lépe než memcache a hlavně disponuje pokročilými typy - ružné sorted sety, pubsub logikou ...
Používat Memcache v době Redisu už nemá moc smysl. Redis dává více muziky a hraje rychleji : )
-
motyq (neregistrovaný)
Pouzivame misto klasicke memcache - membase (couchbase).
Prakticky to je clusterova memcache s tim ze mate ale vic nodes, takze pad jeden to nerozbije cele.
Funguje tam jak klasicky memcache rezim (restart nody = prijdete o to co na ni je) a membase/couchbase rezim.
V nem se nic nemeni na komunikaci s memcache, ale ma diskovy async backup - s tim, ze v pripade couchbase rezimu mate k disposici vice commandu nez tech 14 memcachich - napr nejake datasety/pole. Jako tresen na dortu pak mate k dispozici map/reduce tasky.
Kdyz uz je to v tom clusteru tak samozrejme mate moznost nastavit pocet replik jednoho klice atd...
Obycejnou memcache uz nemam snad nikde - toto ji plne nahradi.
Mam takovy pocit, ze to pise ten samy clovek co delal puvodni memcache.
ČLÁNKY DO MAILU