On Tue, 9 Oct 2018 at 13:43, Alex 'CAVE' Cernat <[email protected]> wrote:
> On 09-Oct-18 2:27 PM, Catalin Muresan wrote: > > > > Both the key and file name in a cache are a result of applying the MD5 > > function to the proxied URL. > > > > Deci lookup se face cind esti pe location-ul respectiv si URL-ul e > > disponibil > > Din surse > > > https://github.com/nginx/nginx/blob/master/src/http/modules/ngx_http_fastcgi_module.c > > se pare totusi ca face hash pe url si pe header. > aici cel mai bine te joci cu fastcgi_cache_key si nu o lasi default, ca > sa se plieze fix pe ce ai nevoie; bine, fiind md5 intotdeauna exista o > mica sansa de coliziune, dar deja intram in filosofii ... > ma uit pe documentatie si la default value e trasa bara, si nu am > incercat niciodata valoarea default, intotdeauna o setez (inclusiv la > proxy cache) > Nu e o idee buna sa pui un cache zone comun din alt motiv: > > > > A minute after the start the special “cache loader” process is activated. > > It loads information about previously cached data stored on file system > > into a cache zone. The loading is also done in iterations. During one > > iteration no more than loader_files items are loaded (by default, 100). > > Besides, the duration of one iteration is limited by the loader_threshold > > parameter (by default, 200 milliseconds). Between iterations, a pause > > configured by the loader_sleep parameter (by default, 50 milliseconds) is > > made. > aici ca mi-ai ridicat mingea la fileu, inca o intrebare de si mai mare > baraj: considerand un cache gigantic, unde dureaza sa incarce toate > cheile, oare ce se intampla cu o cerere care este cache-uita pe disk, > dar cheia nu a ajuns in memorie inca (cache loaderul nu a terminat inca) > ? o verifica pe disc sau direct face cererea la backend ? > o sa incerc sa ma uit si eu prin surse, sa vad daca inteleg ce se > intampla pe acolo; gogu' nu stie sa raspunda si se pare ca doar eu am > intrebari filosofice de genul :-D > presupun ca e un fastpath prin in-memory keys si un slowpath unde se uita pe disk si un cache-miss path unde il trimite la CGI. parerea mea e ca e mai bine sa faci "microcache" (in memorie, pentru CGI-uri si varnish global in fata la un webserver, se comporta mai bine si ai accesul la chestii care sunt doar in nginxplus. > > pentru fiecare cache nginx tine in memorie keys > > > > In addition, all active keys and information about data are stored in a > > shared memory zone, whose name and size are configured by the keys_zone > > parameter. One megabyte zone can store about 8 thousand keys. > vorbeam de cazuri mai mult sau mai putin ipotetice unde chiar s-ar putea > beneficia de cache-uri comune, nu de aplicatii total diferite unde numai > prin prisma separarii aplicatiilor cache-ul comun nu are ce cauta - > existand riscul chiar si ipotetic sa servesc un cache dintr-o alta > aplicatie (parerea mea) > Daca ai probleme de genul asta (cache cross apps, etc) atunci probabil ca solutia corecta e alta, adica sa implementezi caching in toate layerele: DB(proxysql), APP(memcache), Webserver(fastcgi_cache), HTTP(varnish). Ramin la opinia mea initiala ca daca faci cache-uri in acelasi director o sa manince prea multa memorie ca sa incarce cheile care nu o sa fie folosite vreodata. > > Alex > > > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
