Weblabor

Szerintem nem jól, ha nagyobb lesz a kérések kiszolgálási ideje, mint a két kérés beérkezése közötti késleltetés, akkor elkezd nőni a várakozó kérések száma, és két dolog történhet: vagy úgy van bekonfigurálva a webszerver, hogy egyszerre csak X requestet szolgáljon ki (X tipikusan pár tíz), és a látogatók egy része elkezd 503-as hibaoldalakat kapni (és amikor lejön a hullámhegyről a szerver, akkor helyreál a normális működés, de az elveszett requestek már elvesztek), vagy nincs benne ilyen védelem, és akkor elfogy a memória, vagy más hasonló kellemetlenség történik, és jó eséllyel valami olyan állapotba kerül a szerver, amiből már nem tud magától felállni.

Persze ha nagyon rövid a hullámhegy (csak egy-két request idejéig tart), akkor nincs probléma egyik esetben sem.

Ha túl sok lesz a kérés, attól még ugyanúgy maradhat fájlrendszerben, csak szét kell osztani aloldalanként külön fájlokra, aztán meg ha már az sem elég, akkor be lehet tenni memóriába. Ez nem annyira nagy kunszt.

Inkább az érdekelne, hogy miért kell már a kérés elején lockolni az etag fájlt módosításra, és csak a végén módosítani. Gyakorlati haszna szerintem ennek egyáltalán nincs. Tegyük fel, hogy a tranzakció commit megvolt, de az etag fájl még nem frissült, és ilyenkor jön egy get a szerver felé. Ilyenkor az előző etaggel kapja meg a kérés a friss adatot. Maximum a következő kéréskor újra lekéri ugyanazt az adatot csak akkor már a friss etag-el, vagy ha kesselve volt az adat, akkor úgy veszi, hogy még nem módosult. Ha nem get, hanem mondjuk post kérés jön, akkor az etag annak a szempontjából tök lényegtelen, mert azt nem kesseljük. Szóval összességében szerintem nem kell teljes kérésre lockolni, elég csak arra a néhány mikroszekundumra lockolni a rendszert, amíg a fájl írása megtörténik, vagy esetleg arra a pár milliszekundumra, amíg a commit lemegy az adatbázisban, ha már tényleg alaposak akarunk lenni... Szóval az 5 req/sec helyett simán lehet az akár 1000 req/sec is...