Redis Storage + Redis Journal + Redis Session Handler – Kdyby/Redis

Good job :-)

ad. Composer: není lepší nechat minimum-stability na výchozím stable a nastavit dev jen u rozšíření?

{
    "require":{
        "kdyby/redis-extension": "@dev"
    }
}

V pohodě se to nainstaluje.

$ composer install
Installing dependencies
  - Installing nette/nette (v2.0.3)
    Downloading: 100%

  - Installing kdyby/redis-extension (dev-master)
    Cloning f96355461fc439ef11fe1c977d8f3ec630de014a

Writing lock file
Generating autoload files

Super! Tak to můžu smazat https://github.com/…edis-storage :)

Editoval honzajavorek (19. 7. 2012 11:32)

@**martinit**: To je v panelu, to se može :)

testoval si redis cache aj pri paralelnom pristupe?

use case:

5 forknutych procesov cita aj zapisuje do cache.

momentalne pouzivam cache storage zalozenu na predise, ale v poslednom case dostavam vela errorov, cim menej forkov je naraz tym menej a naopak.

myslis, ze tvoje riesenie by tento problem eliminovalo?

Image not found?

slo by mat zvlast db pre storage a zvlast pre session?

Jak to myslíš? Redis je key-value storage, který je, řekl bych, poměrně osvědčený. Jede v RAMce, takže je superrychlá a oproti memcache(d) má spoustu funkcí navíc, hlavně co se týče práce s klíči. Samozřejmě ti tu RAMku vyžere, pokud ji budeš plnit co to jde. Pokud bys tím chtěl ale nahradit klasickou SQL full-featured db, tak na to to samozřejmě není. Záleží, na co to potřebuješ, což platí u všeho a u NoSQL/key-value databází tuplem.

no, len tak vymyslam.

napr kvoli pagodaboxu, kde je free redis cache 10mb ale mozes ic mat viac.

alebo kvoli cachovaniu len nejakych urcitych dat, mohol by som spravit flush db bez toho, aby sa zmazali sessiony a tak.

To se mi vůbec nelíbí, to bych raději udělal nějaký StorageChain, JournalChain.

LeonardoCA napsal(a):

Možná by byla zajimavá podpora pro fallback, když redis neběží.
https://gist.github.com/4008177

Mně se to, cos stvořil taky nelíbí, raději takto: https://gist.github.com/4009199#…
Nicméně mnohem vhodnější je nechat aplikaci spadnout. Pokud totiž redis využíváš k ukládání sessions, stane se následující:

1. Redis běží, uživatel se přihlásí.
2. Redis spadne, uživatel je bez ohlášení odhlášen.
3. Redis neběží, uživatel se přihlásí.
4. Redis opět běží, uživatel je odhlášen.

   Ve výsledku akorát nežádoucím způsobem obtěžuješ uživatele.

Díky za názory.

Podle mně by to chtělo mít spadnutí cashe nějak ošetřené, přijde mi to lepší než nechat web běžet bez kešování. A už vůbec se mi nelíbí varianta nechat web spadnout úplně. (Půjde o web s vysokou nárazovou návštěvností.)

Odhlašování uživatelů

• dalo by se ošetřit nějakou automatickou replikací session. /pro současný projekt neřeším, bude se přihlašovat jen admin/

Možná by se spíš mělo řešit zabezpečení toho aby redis běžel než to řešit na úrovni aplikace. Přemýšlím, co má smysl…

Mám ještě pár poznatků z testování před pár dny, u kterých jsem nedospěl k závěru jak to dořešit.

Při testování cashování se mi stávalo, že při prvním použití zůstala aplikace viset na 4 minuty. Viselo to na volání, pokud dobře vzpomínám lRem při získávání tagů. funkce se volala 2× a myslím si že se to zaseklo na fread. Odpovídá to nastavení default_socket_timeout, které mám na lokále na 120s. 2× = 4min. Timeout true mi vracela funkce stream_get_meta_data.

Timeout, který se volá při nastavení connect není ve skutečnosti timeout, ale jde o počet pokusů o navázání connection. Timeout se dá nadstavit přes stream_set_timeout, ale nejsem si jist nakolik funguje, ačkoli to vypadalo že funguje. Celé api okolo streams a socket je trochu zmatené.

Díval jsem se na pár more advanced implementací na githubu a tam v některých případech využívají stream_select které zahrnuje nastavení timeoutu.

K věci. Na timeout to vypadává, když se RedisJournal pokouší přečíst tagy, když ještě žádné tagy v redisu nejsou. Přijde mi že spolu dobře nespolupracuje volání stream_get_line a následně fread. Zkoušel jsem stejné commandy přes redis-cli a vracelo to odpověď string ‚(empty …)‘ Ačkoli to vrátí data a response se naparsuje správně, tak to visí po dobu nastaveného timeoutu, ale nepřišel jsem na to proč. (je možné že to už nepopisuju úplně přešně) Měl jsem nastavené expiraci cashe a session na 30min a testoval jsem to na pár blocích v šabloně. Vše fungovalo správně ale po uplynutí timeoutu (expirace cashe) to při prvním otevření aplikace viselo 4 minuty…

Ještě dvě věci ve kterých nemám úplně jasno a mohly by s tím souviset.

• extension si handler ukládá do session, která je v redisu – co se stane když session expiruje a redis tam hledá svůj handler.
• debugoval jsem celou sestavenou message na redis a některé se při dumpu vypisují odřádkované a některé v jednom řádku. A zrovna na nich to možná jen shodou okolností viselo.

@Hosiplan: nemám z toho všeho závěr, jen píšu poznatky, kdyby tě něco napadlo. Jde o nějaký bug, který se projeví jen za výše popsaných okolností. (ještě jsem nezkoumal jestli to náhodou nesouvisí s nastavením localhostu jak někde píšeš, nicméně si myslím, 1. že timeout by stálo za to mít možnost nastavit i kdyby to bylo jen přímo přes nastavení ini_set default_socket_timeout a 2. by k tomu timeoutu nemělo dojít)

Editoval LeonardoCA (9. 11. 2012 3:21)

ok, díky- Otestuju to asi přes víkend, ale pořádně se ke cashování dostanu až za týden.

Editoval LeonardoCA (9. 11. 2012 18:17)

Bezva. A co říkáš na ten timeout? Přeci jen k němu může dojít z externích důvodů a aby aplikace nevisela několik minut, ale vyhodila alespoň 500stovku, tak by ho to chtělo mít nastavitelný.

To jsem přehlíd. Good job.

Co je to za dotaz? Jak to voláš?

K tomu stream_set_timeout jsem nekde cetl poznamku, ze ve skutecnosti nedela nic jineho nez ze nastavi timeout na true pro funkci stream_get_meta_data. Anglicky rozumim, ale co melo byt touhle vetou receno nerozumim. Proto jsem psal vyse, ze nevim jak to funguje. Porad mi prijde ze fread tak jak ho pouzivas zpusobuje ten problem, asi bych ten buffer zkusil cist nejak jinak. Ale divne je, ze tobe se to predpokladam takto nechova.

Editoval LeonardoCA (10. 11. 2012 19:20)

to musim nasimulovat v cistem sandboxu, na projektu mam NDA, zkusim to pripravit zitra

Nestíhám, do konce týdne to snad vyjde.

První request

Druhý request

redis 127.0.0.1:6379> info
# Server
redis_version:2.6.6
redis_mode:standalone
os:Linux 2.6.38-12-generic x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.5.2
tcp_port:6379
uptime_in_seconds:469
uptime_in_days:0
lru_clock:1209719

Chybu bych hledal v síti, dns, nebo v nečem mezi PHP a Redisem…

Povedlo se někomu objevit příčinu, proč to těch 20 s čeká? Na jednom projektu jsem teď Redis Storage použil (mimochodem díky za publikování, až to rozběhnu, tak to bude paráda!) a chová se mi to taky divně. Na jednom stroji, kde je Ubuntu 12.04 (Redis z distribuce, verze 2.2.12, ale chová se to stejně, i když to nastavím na Redis 2.4.15 na Debianu – viz dále), každý požadavek do Redisu trvá tolik, kolik nastavím do „timeout“ (config.neon – common → redis → timeout). Na druhým stroji, kde je Debian 6.0.6 (Redis z backports – verze 2.4.15), se to chová stejně, jako popisuje LeonardoCA – tzn. proběhne pět dotazů a pátý trvá 20 s.

https://dl.dropbox.com/…/redis-1.png

Další už proběhl rychle.

https://dl.dropbox.com/…/redis-2.png

A teď jsem to zkusil reloadnout ještě jednou a výsledek je takový, že DebugBar sice ukazuje celkový čas 66,6 ms, ale na zobrazení stránky jsem čekal stejně těch cca 20 s.

https://dl.dropbox.com/…/redis-3.png

Promazal jsem komplet cache, smazal data v Redisu – první reload trval stejně jako předtím (teď už 16 dotazů, exec vždy trvá 20 s, ostatní pár micros), další reloady už trvají vždy jen pár stovek micros. Předtím to načítání (redis-3.png) „tuhlo“ ve chvíli, kdy se stránka už začala vykreslovat a načítání se zaseklo v místě výpisu cachovaného obsahu (somechached content). Pokud to teď chci dostat do stavu, kdy to takhle dlouho čeká, tak stačí smazat /temp/cache/_Nette.FileTemplate a dostanu se zase do redis-1.png.

Pro testování jsem použil redis-test.zip, co odkazoval LeonardoCA.

Teď jsem pro jistotu ještě kontroloval – mám verzi knihovny z commitu c9c595740456d2b08f4817adb2609f90be8884e8, tzn. měla by to být poslední verze master větve. Ještě si s tím budu hrát…

Něco s tím zkusím udělat :) https://github.com/…rk/issues/54 Díky za report!