ugrás a tartalomhoz

Sessionmentes weboldalak

janoszen · 2016. Nov. 1. (K), 02.45
Sessionmentes weboldalak

Az elmúlt hetekben érdekes koncepcióval játszottam. Mi lenne, ha nem lenne munkamenetünk, vagy ismertebb nevén sessionünk? Lehetne-e modern weboldalt készíteni? Működnének-e az elvárt funkciók? Mennyire lenne nehéz fejleszteni?

Miért?

Ezen a ponton joggal gondolkozol el, hogy vajon elgurult-e a gyógyszerem, hogy egy ilyen alapvető technológiát ki akarok dobni? De nézzük, hogy mi is az a session.

A weboldalak a HTTP alapjain nyugszanak. Egy kérés, egy válasz. Ha egy erőforrást el akarunk érni, intézünk egy kérést a szerverhez, amire válaszként megkapunk egy HTML dokumentumot. Vagy egy képet. Vagy egy videót.

A probléma ott van, hogy a szerver nem tudja ezeket a lekérdezéseket egymáshoz kapcsolni. Nem tudja azt, hogy aki az előző lekérdezésben a helyes jelszót küldte, az ugyanaz az ember, aki most a szupertitkos fájlokhoz hozzá szeretne férni.

Na ezt a problémát oldja meg a session. Az első válasszal küldünk a böngészőnek egy sütit, benne egy azonosítóval, amit az innentől minden újabb kéréssel visszaküld. Szerveroldalon ehhez az azonosítóhoz rendeljük azokat az adatokat, amik ahhoz a sessionhöz, ahhoz a munkamenethez tartoznak.

Ez elméletben szép és jó, azonban egy igen csúnya probléma van vele. A programozó.

Az olyan környezetek, mint a PHP ugyanis nemcsak automatizálják a folyamatot, de transzparensen lemezre is szerializálják az azonosítóhoz rendelt adatokat, ami igen kényelmes gyorstárazási lehetőséget kínál, amely ráadásul egy-egy felhasználóra egyedi. Vagyis bejelentkezéskor szépen betöltjük az egész user objektumot, majd eltároljuk a sessionben. És ha már ott tartunk, az összes megrendelését is. És a session fájl csak nő, és nő, és nő.

Amellett, hogy rengeteg helyet foglal a diszken, komoly logikai problémákat is okozhat a sessionök ilyen jellegű használata. Hiszen mi történik, ha a felhasználó egy másik eszközről is bejelentkezik, teszem azt a telefonjáról, és onnan módosítja az adatait?

Mindjárt nem lesznek aktuálisak a sessionben gyorstárazott adatok, és mindenféle érdekes problémák lépnek fel, amiket ráadásul nehéz lenyomozni.

Vagy mondok kacifántosabbat. Mi történik akkor, ha egy felhasználó párhuzamosan két lekérdezést indít?

Amint látható, mindkét folyamat betölti a session adatokat, majd mindkettő elkezd dolgozni a saját feladatán. A feldolgozás végeztével mindkettő visszaírja a sessiont a fájlba vagy adatbázisba. Vegyük észre azonban, hogy a második lekérdezés felülírja az első által végzett módosításokat. Például a PHP alapértelmezett munkamenet-kezelője ezt elkerülendő zárolja az adatokat, és egyszerre csak egy folyamatnak biztosít hozzáférést a sessionhöz, ami nem skálázódik túl jól. Egy elosztott rendszeren, ahol a zárolás nem jöhet szóba, az egy az egyben kiolvasott és viszaírt adattömeg folyamatos ütközésekhez fog vezetni.

A sessionökkel önmagában nincs baj. A probléma akkor keletkezik, amikor elkezdjük használni a legtöbb webes környezet által hozzájuk felkínált amorf adattároló zsákot. Vagyis például PHP-ban a $SESSION-t. Nézzük tehát az alternatívákat.

Bejelentkezés

Hogyan valósítanánk meg a felhasználói bejelentkezést sessionök nélkül?

A válaszhoz ihletet merítünk az OAuth protokollból. Amikor a felhasználó bejelentkezik felhasználónévvel és jelszóval, kiadunk egy egyedi azonosítót. Egy tokent. Munkamenet-azonosító helyett ezt tároljuk el a sütiben.

Amikor a felhasználó egy olyan oldalra téved, ahol a felhasználói adataira van szükség, a süti kiolvasásra kerül, és a token alapján betöltjük a felhasználó adatait az adatbázisból.

Vagyis minden lekérdezésre kénytelenek vagyunk az auth tokent ellenőrizni. Elsőre azt sejtenénk, hogy ez nagyon nem hatékony, de ha jobban belegondolunk, a sessionöket ugyanúgy be kellett tölteni. Annyi a különbség, hogy most nem egy hatalmas amorf adathalmazt próbálunk kiszedni az adatbázisból, hanem egy nagyonis konkrét céllal nyúlunk hozzá. Az eredmény az, hogy ehhez a célhoz tudunk megfelelő adatbázist választani és optimalizálni.

Sőt mi több, mégegy nagyon fontos lehetőség nyílik meg előttünk. Mivel az auth tokeneket a felhasználóhoz kötötten tároljuk, lehetőségünk nyílik a felhasználó aktív tokenjeit kilistázni, hasonlóan mint ahogy a Facebook is csinálja.

Űrlapok kezelése

A sessionök másik gyakori felhasználása a különböző űrlapokba írt értékek megőrzése, például többoldalas űrlapok esetén.

Természetesen erre is van megoldás, hiszen a sessionök helyett minden további nélkül tárolhatjuk sütikben is a felhasználótól kapott adatokat. Gondoljunk bele, semmi olyan nincs benne, amit a felhasználó ne tudna! A böngésző által rendelkezésünkre bocsájtott 4 kB erre bőségesen elegendő. Ha ennél több adatot kell megadni egy űrlapban, akkor egyébként is javasolt egyfajta autosave funkció implementálása.

Állapot megőrzése

Sokan a munkameneteket arra is használják, hogy megőrizzenek bizonyos állapotot. Például azt, hogy melyik lépésnél tartott a felhasználó a regisztrációs folyamatban. Ezt a technikát személy szerint kerülendőnek tartom, hiszen a felhasználó egy vissza gomb megnyomásával semmissé teheti a jól kigondolt állapoti logikánkat.

Helyette azt javaslom, hogy minden lépés rendelkezzen önálló címmel, és egyedileg ellenőrizze, hogy aktuális-e még a kitöltése. Ha nem, automatikusan ugorjon a következőre. Ez megkerüli a session problémáját és a felhasználói élményt is javítja, mert működni fog a vissza gomb.

Ellenérvek

Noha a fenti elképzelést a gyakorlatban is teszteltem, és meglepően jól működik, vannak ellenérvek. A legnagyobb talán az, hogy ezt a fajta működést egyetlen általam ismert űrlapkezelő programkönyvtár sem támogatja. Azaz szinte nulláról kell lefejleszteni mindent, vagy meglehetősen sokat kell módosítani a meglevő szoftvereken.

Ezen felül érdemes figyelemmel kísérni a sütiket tartalmazó fejléc méretét is. Ha sok űrlapunk van, könnyen túlnőheti a webszerveren beállított maximális méretet, ami fura hibákat eredményezhet.

Jelen állapotában ezt a technikát nem tudom javasolni általános felhasználásra. Olyan esetekben mint az enyém, ahol egy egyedi szoftverplatformon kell dolgozni, és esélytelen a külső könyvtárak használata, viszont érdemes megfontolni az alkalmazását.

Összegzés

Ha jobban belegondolunk, ez a megoldás is egyfajta session, amit részben a felhasználói adatok közé, részben pedig a kliensoldalra helyezünk. Csak éppen szépen, strukturáltan tároljuk az adatokat, a jellegüknek megfelelő helyen, nem egyetlen amorf zsákban, amibe az égegyadta világon mindent bele lehet tenni. Ugyanezt az elvet kellene követni a többi adattervezési feladatnál is. Ezzel elérjük azt, hogy az esetleges hibák sokkal lokalizáltabbak, könyebben felderíthetőek, és a teljesítményen is javíthatunk.

 
janoszen arcképe
janoszen
Pásztor János a fejlesztés és az üzemeltetés témakörével is foglalkozik, igyekszik az egyikben szerzett tapasztalatokat a másikba is átültetni. A Weblaboron kívül Facebookon ,Twitteren, a Refaktor Magazinon és a Refactor Zone-on publikál.
1

+1

szabo.b.gabor · 2016. Nov. 1. (K), 10.12
hiánypótló cikk (: abszolút egyetértek. tényleg csak annyi fontos, hogy ki csinálja amit éppen csinál, amire egy token bőven elég.

én mondjuk cookie-ban nem tárolnék form adatokat, sőt leginkább semmit sem, lévén mindig utaznak mindenhova, meg a csrf-re figyelni miatta. ez a token is menjen egy speckó headerben, aztán viszonlátásra. ok, kényelmi szempontból maradhat egy másolat cookieban is, de ne a cookie-ból olvassuk ki szerver oldalon.

adattárolásra meg ott van a javascript, localstorage, meg biztos van más is..
2

Ez így van

janoszen · 2016. Nov. 1. (K), 10.34
Ha belegondolsz, a sütikben levő adat pont annyira megbízhatatlan, mint az űrlapból jövő. Vagyis szerver oldalon pont ugyanúgy kell kezelni a kettőt. Az előnye az, hogy szerver oldalról írható-olvasható, nem kell hozzá JS.

CSRF ellen meg szépen lehet védekezni egy httpOnly CSRF token sütivel.
3

Süti

Poetro · 2016. Nov. 1. (K), 11.45
Szerintem a süti is teljesen felesleges. Sokkal hatékonyabb lehet a tokent sessionStorage-ban tárolni, és csak a kéréseknek elküldeni, amelyeknek szüksége van erre. A sütik túl nagyok, és túl sok kérés megkapja őket (minden kérés az adott szerveren, ami beleesik a süti hatókörébe).
4

Akár

janoszen · 2016. Nov. 1. (K), 12.04
A süti hatókörét azért lehet korlátozni ha optimalizálni akarsz. Azon a setupon ahol ezt a technikát használon, az összed static asset külön aldomainen van.

Persze ha a backendet csak API-ként használod, akár a sessionStorage is jó lehet.
5

Ahol pedig én használok SSO-t

Poetro · 2016. Nov. 1. (K), 12.16
Ahol pedig én használok SSO-t (ahogy mindenhol az utóbbi 3 évben), az mind SPA volt, és mindenhol a backend csak API-ként volt használva. Az, hogy a token hogyan került a szerver oldalra, teljesen változó volt. Volt hogy sessionStorage, volt ahol süti, és volt ahol szerver oldali session volt (és egyik sem PHP).
6

Nekem hiányérzetem van, nem

inf3rno · 2016. Nov. 1. (K), 19.43
Nekem hiányérzetem van, nem igazán lett kifejtve, hogy mi az a token ebben a kontextusban. Illetve az sem lett kifejtve, hogy abból adódnak a konkurrenciával kapcsolatos gondok, hogy a kliens állapotát a szerveren próbáljuk kezelni.
7

Nehéz

janoszen · 2016. Nov. 1. (K), 20.03
Azért, mert baromi nehéz általánosan leírni a problémákat. A session egy hatalmas zsák és bármilyen verselyhelyzet adatvesztéshez vezethet, függetlenül attól, hog a kliens állapotát próbálod tárolni, "csak" cacheled-e az adatokat, vagy egyéb feladatokra használod.

A cikk mondanivalója inkább az, hogy a session feladatköreit szét kéne szabdalni, apróbb, kezelhetőbb részekre vágni, és ha lehet, a versenyhelyzetektől mentesíteni. (A lockolás az én szememben nem játszik, mert egy bizonyos méret fölött lehetetlen.)
8

Hát ezzel egyet tudok érteni.

inf3rno · 2016. Nov. 1. (K), 20.35
Hát ezzel egyet tudok érteni. Ha valaki úgy is dönt, hogy kell neki a hagyományos session, akkor is érdemes minimumra redukálni a tartalmát, és a kevésbé életbevágó dolgokat, mondjuk az űrlapok tartalmát inkább kliens oldalon tárolni. Bizonyos esetekben ha állapotmentes kommunikáció kell, akkor meg szerver oldali session helyett lehet tokenezni.
67

érdeklődés

cenya · Ápr. 11. (K), 22.50
Azt írod hogy a session egy hatalmas zsák amit nehéz kezelni mert bármit beledobhatsz. Mi lenne akkor hogyha ezt a zsákot elrejteném magam elől mint fejlesztő és egy adott osztály statikus tulajdonságaként szerepelne az adott session elem. Pl egy user osztálynak lenne egy private static $current tulajdonsága kapna egy get és set metódust a set serializálná az adott osztály egy példányát a változóba a get unserializalna. Lehet kicsit bonyolult viszont szeparálva lehetne kezelni a $_Session ben tarolt adatokat.
68

Nem oldja meg

janoszen · Ápr. 12. (Sze), 07.46
Nem oldja meg az eredeti problemat, miszerint beletehetsz barmit, barmilyen mennyisegben. Csak a jozan paraszti esz szab hatart annak hogy mennyi adatot tarolsz benne es mennyire csapod arcon magad egy versenyhelyzetnel. Az atlag fejleszto pont nulla masodpercig gondolkodik azon hogy esetleg valamit nem sessionben kellene tarolni.

Azt, hogy OOP kornyezetben ezt hogyan kellene kezelni fel sem merem hozni, mert akkor ez a thread honapokig nem er veget.
9

Ha kliens oldalon tarolod az

csongor@halmai.hu · 2016. Nov. 23. (Sze), 08.14
Ha kliens oldalon tarolod az adatokat, akkor is lehet problema. Ha pl. telefonnal a kezemben hasznalom az asztali gepet, akkor a ket eszkoz lokalisan tarol valami kulonbozot, aminek elobb-utobb a szerverre kell kerulnie, es akkor utkozni fognak.
10

Ütközés?

Poetro · 2016. Nov. 23. (Sze), 10.38
Miért lenne ütközés? Kettő munkameneted van, amiben két különböző dolgot csinálsz. Ha például egy bevásárlókosárról van szó, akkor lehet, hogy két kosarad van.
11

State

janoszen · 2016. Nov. 23. (Sze), 12.57
Igen, ha allapotod van, akkor ez problema. A cel az, hogy ne legyen allapot, es a session elso szamu kisertes valamilyen allapot letrehozasara.

A cel az, hogy ne legyen ilyen jellegu allapotod, hanem pl. a kosar tartalmat ne a sessionben, hanem a DB-ben tarold, userhez kotve. Igy mindket keszuleken ugyanazt latod.
12

Tehát - ha jól értem - adott

visuall · 2016. Dec. 10. (Szo), 17.35
Tehát - ha jól értem - adott egy (backend -> )tokenkiadó szerver + a kiszolgáló. Tegyük fel, hogy szeretnék egy ilyet írni. Alapvetően milyen technológiák állnak rendelkezésre a webes interfész kiszolgálásához?
Beépíthetjük közvetlenül a PHP-ba a token kiadását, de annak lefolyása a többi folyamattól független lesz - speciális esetben kell a lockolás, ami nem megfelelő. Van a node.js, amellyel egy socketen keresztül beszélgethetünk.
Mi más van még?
(ui.: hogy vélekednek ma már a CGI-alapú futtatásról?)
13

Nem

janoszen · 2016. Dec. 11. (V), 12.02
Ennek nem feltetlenul kell kulon szerveren lennie, lehet az alkalmazasodon belul is. A lenyeg egy logikai kulonbseg a sessionben valo tarolashoz kepest. Ajanlom figyelmedbe az Entity-Boundary-Interactor tervezesi mintat, azzal igen konnyen megvalosithato egy ilyen struktura.
14

Ránéztem a cikkedre

visuall · 2016. Dec. 12. (H), 22.18
Ránéztem a cikkedre (https://www.refaktor.hu/tiszta-kod-8-resz-egy-tiszta-kod-blog-kezdetei/), és el kell mondanom, hogy profi munka lett!
Hasonló következtetésekre jutottam, mikor a saját OO-alapú blogomat terveztem, de ez sokkal összeszedettebbé rakta eme gondolataimat. A TDD-alapú fejlesztést figyelgettem, de nem nagyon fogott meg. Pedig egy nagyon hasznos dolog: kiszűri a következtethetetlen részeket.
Na, meg is jött a hangulatom egy saját oldal elkészítéséhez! Ezer köszönet! :)
15

BDD-t nézegessed, szerintem

inf3rno · 2016. Dec. 13. (K), 13.10
BDD-t nézegessed, szerintem az sokkal emberközelibb, ha jól csinálják, mint a TDD, bár kevésbé alapos.
17

vitatkoznék :)

Pepita · 2016. Dec. 18. (V), 17.44
TDD is simán ember közeli, ha valóban jól csinálod.
Van egy terved (mondom van, nem fejben, hanem le írva :) ), ez alapján írsz egy első tesztet, ami a legelső valamit fogja vizsgálni.
Futtatod.
Hoppá, el szállt, nincs is olyan class. :-D
Hát létre hozod a class valamit.
Megint futtatod.
Hoppá, nincs az a metódus. :)
Csinálsz neki.
...
A mellett, hogy tök mókás, egyrészt duplán figyelsz a kódod minőségére, másrészt a későbbiekben ha változtatni kell, meg véd egy csomó bug lehetőségtől.
18

Szerintem nem jött át. A

inf3rno · 2016. Dec. 19. (H), 00.48
Szerintem nem jött át. A TDD-t csak programozó érti, a BDD-t meg laikus is. Nagyjából ennyi a különbség. Ezek után nem hinném, hogy a TDD ember közeli lesz valaha is, más absztrakciós szinten van...
19

jogos

Pepita · 2016. Dec. 19. (H), 00.51
Én értettem félre.
16

Ha

janoszen · 2016. Dec. 14. (Sze), 14.52
Ha motivaltalak uj dolgok tanulasara, akkor elertem a celomat. :)
20

Bár koránt sem értek annyira

Oregon · 2016. Dec. 31. (Szo), 18.18
Bár koránt sem értek annyira ehhez, mint te janaszen, de nálam régóta ez a megoldás a session-ben:
user_id;
hash('sha512', $data);
// $data = 3-4 adat a kliens gépéről + só, mint pl.: ip, böngésző neve, OS, etc...
// session lopás miatt raktam ezt bele


Ezenkívül minden db-ből érkezik, így az alap problémát kiváltó okok nem merülnek fel nálam.
21

Session ID

janoszen · Jan. 1. (V), 12.12
Remelem nem a session ID-t generalod igy.
22

dehogy!!!! Vagy ez vicc volt?

Oregon · Jan. 1. (V), 18.19
dehogy!!!! Vagy ez vicc volt?

Ez két változó a session-ben.
23

De miert is?

janoszen · Jan. 2. (H), 13.49
De akkor miert is csinalsz ilyet? Azert, hogy azonositsd hogy ugyanarrol a bongeszorol jon-e? Az IP ugye valtozhat, kulons keppen mobil keszulekeknel amik wifirol mobil halozatra ugranak es vissza. A bongeszo user agent stringje szinten valtozhat ha upgradel. A Chrome pl. silent upgradekkel rendelkezik, eleg idegesito ha emiatt kiloggolodik az ember.

Es mindez hogyan kapcsolodik ahhoz a problemahoz hogy a session-oknek igen komoly problemaja a lockolas szuksegessege?
24

Úgy értem a probléma abból

Oregon · Jan. 2. (H), 14.09
Úgy értem a probléma abból van, hogy változtatható adatokat raksz a session-be. Rosszul értelmeztem?

A második megoldást céges inetrneten logó privát rendszerhez használom és elfogadható az esetleges killoggolás.
25

Nem

janoszen · Jan. 2. (H), 16.36
A problema ket reszbol all:

1. ha ket lekerdezes jon parhuzamosan, lockolas nelkul elveszhetnek a valtozasok, mert a masodik lekerdezes mentese felulirja az elsot.

2. a session nagyon kinalja magat allapot bevezetesehez. Hogy csak egy trivialis peldat mondjak, sokan az arukosarat a sessionbe rakjak, pedig semmi keresnivaloja nincs ott.
26

1. Épp ezért tartom

Oregon · Jan. 2. (H), 19.21
1. Épp ezért tartom minimálisan a sessions-t.
2. Ettől én is kivagyok. Az általam fejlesztett webes alkalmazások akár egy számlázó is, folytatható egy másik gépen ugyanonnan ahol abbahagyta a folyamatot felhasználó.
27

Ilyet ne

lolka_bolka · Jan. 5. (Cs), 16.23
Vagyis bejelentkezéskor szépen betöltjük az egész user objektumot, majd eltároljuk a sessionben. És ha már ott tartunk, az összes megrendelését is.

Ilyet nem csinálunk. Volt erről egy izgalmas thread a stackoverflow-n.

A felhasználó azonosítóját tároljuk el max, és ha kell, akkor példányosítjuk a Usert.
28

Mi akalyoz meg benne?

janoszen · Jan. 17. (K), 15.47
De mi akadalyoz meg benne? Sok fejleszto a legkisebb ellenallas iranyaba megy, es a Session nagyon kis ellenallast nyujt az ellen hogy abban minden szemetet eltaroljunk.
29

Kérdések

Hidvégi Gábor · Már. 19. (V), 20.11
Most olvastam újra az írást, és lenne pár kérdésem.

Vagyis bejelentkezéskor szépen betöltjük az egész user objektumot, majd eltároljuk a sessionben. És ha már ott tartunk, az összes megrendelését is. És a session fájl csak nő, és nő, és nő.
És mi van akkor, ha sok helyet foglal a lemezen? Mi van, ha van elég tárhely? Egyben ott van egy nagy adathalmaz a memóriában, amiből gyorsan kiolvasod az adatokat – inkább indítsunk el n darab lekérdezést az adatbázisból, ami összeszedi ezeket egyesével?

Hiszen mi történik, ha a felhasználó egy másik eszközről is bejelentkezik, teszem azt a telefonjáról, és onnan módosítja az adatait?
Ennek elég nagy biztonsági kockázata van – én például nem tartom túl jó ötletnek a többszörös bejelentkezést, nem is alkalmazom.

Mi történik akkor, ha egy felhasználó párhuzamosan két lekérdezést indít?
A felhasználó csak ne indítgasson párhuzamosan lekérdezéseket. A PHP beépített zárolása megbízhatóan működik, de vajon egy átlag (PHP) programozó meg tudja-e valósítani ugyanolyan minőségben?

Lehet választani:
1, írok egy logikát a szerveroldalon, ami megvizsgálja, hogy az adott kérés futtatható-e párhuzamosan, és ez vagy sikerül, vagy pedig nem, az alkalmazás bonyolultságától függően.

2, úgy írom meg a kódot, hogy mindig zárol, és akkor ugyanott vagyok, mint a PHP beépített munkamenetkezelése.

lehetőségünk nyílik a felhasználó aktív tokenjeit kilistázni, hasonlóan mint ahogy a Facebook is csinálja
Nem tudom, mennyire szabad a Facebook-ból kiindulni. Ez egy olyan szolgáltatás, amire a felhasználók állandóan be vannak jelentkezve, és gyakorlatilag nulla értékű tartalmat generálnak.

Egy magára valamit is adó vállalatnál nem engedhetik meg maguknak, hogy mindig benn legyünk, és véletlenül érzékeny adatok kikerüljenek, szóval itt nem fontos a felhasználók kényelme.

Például a PHP alapértelmezett munkamenet-kezelője ezt elkerülendő zárolja az adatokat, és egyszerre csak egy folyamatnak biztosít hozzáférést a sessionhöz, ami nem skálázódik túl jól.
Skálázódás – nagyon divatos szó, de jó lenne tudni, hányakat is érint ez a dolog. Azok az emberek is a Weblaborról tájékozódnak, akik ilyen problémával küzdenek?
30

Valaszok

janoszen · Már. 19. (V), 20.40
Azt hiszem, nem irtam le eleg erthetoen hogy mit probaltam mondani. A sessionok nem (csak) a funkcionalis problemak miatt okoznak gondot, hanem pl. azert is, mert architekturalisan osszekeveredik egy csomo minden. Cacheles, azonositas, stb. mind-mind egy globalisan tarolodik.

Hogy valaszoljak a kerdeseidre:

És mi van akkor, ha sok helyet foglal a lemezen? Mi van, ha van elég tárhely? Egyben ott van egy nagy adathalmaz a memóriában, amiből gyorsan kiolvasod az adatokat – inkább indítsunk el n darab lekérdezést az adatbázisból, ami összeszedi ezeket egyesével?


Ez esetben implementalhatsz disk cachelest, de ez egy jol korulhatarolhato feladat, nem kell osszekeverni egy halom mas feladattal.

Ennek elég nagy biztonsági kockázata van – én például nem tartom túl jó ötletnek a többszörös bejelentkezést, nem is alkalmazom.


Marmint ugy erted hogy nalad nem lehet tobb eszkozrol bejelentkezni ugyanarra a weboldalra?

A felhasználó csak ne indítgasson párhuzamosan lekérdezéseket. A PHP beépített zárolása megbízhatóan működik, de vajon egy átlag (PHP) programozó meg tudja-e valósítani ugyanolyan minőségben?


A zarolas a PHP-ban akkor mukodik, ha olyan filerendszeren vagy ami tamogatja a lockolast. Abban a pillanatban hogy pl. lockolas nelkuli NFS-en vagy, vagy atallsz DB alapu session menedzsmentre, azonnal elveszted a lockolast. Tehat abban a pillanatban hogy tulnosz egy szerveren, szembesulni fogsz a problemaval.

Lehet választani:
1, írok egy logikát a szerveroldalon, ami megvizsgálja, hogy az adott kérés futtatható-e párhuzamosan, és ez vagy sikerül, vagy pedig nem, az alkalmazás bonyolultságától függően.

2, úgy írom meg a kódot, hogy mindig zárol, és akkor ugyanott vagyok, mint a PHP beépített munkamenetkezelése.


Az elsot nem egeszen latom hogy hogyan tudod megvalositani. A PHP architekturaja olyan hogy nem latod azt hogy milyen keresek futnak parhuzamosan. Ha jon egy AJAX request, vagy a favicon.ico hianya veletlenul rafut a PHP fajlodra, maris lehet egy parhuzamos keresed.

Skálázódás – nagyon divatos szó, de jó lenne tudni, hányakat is érint ez a dolog. Azok az emberek is a Weblaborról tájékozódnak, akik ilyen problémával küzdenek?


Barkit aki egy szervernel tobbon fut.
31

Alapvetően igazad van,

Hidvégi Gábor · Már. 20. (H), 10.23
Alapvetően igazad van, célszerű minél kevesebb dolgot tartani a munkamenetben, hogy a kezelése minél kevesebb időt vegyen igénybe.

Nem látok abban problémát, hogy a munkamenetet cache-ként használjam, amíg van elég erőforrás. A mi esetünkben ez akár több megabájtot is jelenthet, ekkora adatmennyiségnek az olvasása-írása ezredmásodpercekben mérhető (az írás úgyis késleltetve történik). Ettől függetlenül elgondolkoztam azon, hogy a statikus részeket (amely a teljes adatmennyiség túlnyomó része) kiteszem egy külön fájlba, így legalább ennek az írását megspóroljuk.

Marmint ugy erted hogy nalad nem lehet tobb eszkozrol bejelentkezni ugyanarra a weboldalra?
Egy felhasználó csak egyszer jelentkezhet be egy böngészőből.
32

Munkamenet

janoszen · Már. 20. (H), 12.48
Nem a munkamenet file irasa/olvasasa a problema, hanem a lockolas. Ha a munkamenetet hasznaod mindenre, azzal predesztinalod hogy soha nem lehet tobb mint egy parhuzamos request, ami adott esetben problema lehet. Kis oldalaknal nyilvan nem, de nagyobbaknal, ahol esetleg a frontend developer kemenyen AJAXol ossze vissza, okozhat meglepeteseket. Plane, ha valamelyik alulkepzett backend "fejleszto" nem latja at a konzekvenziakat es atcsapja MySQL backendre a sessionoket.

Lehet sessionoket hasznalni, de nekem az a tapasztalatom, hogy csapatos fejlesztesben mindig elokerul valaki aki nem egeszen erti hogy egesz pontosan hogyna mukodik, es honapokkal kesobb elkezdenek elojonni a versenyhelyzetek es a random 500-as hibak.

Egyebkent ez lazan kapcsolodik.
33

Párhuzamosság

Hidvégi Gábor · Már. 20. (H), 14.38
A párhuzamosság kemény dolog, a hardveroldalon legalábbis évtizedek óta foglalkoznak vele, és máig nincs egyértelmű megoldás a problémára, ott is előfordulhatnak versenyhelyzetek. Pedig a legnagyobb koponyák dolgoznak rajta, miből gondolod, hogy ezt egy PHP scripthuszár fogja most hirtelen abszolválni?

Kis oldalaknal nyilvan nem, de nagyobbaknal, ahol esetleg a frontend developer kemenyen AJAXol ossze vissza
Bocsánat, de miért a farok csóválja a kutyát? Értem én, hogy mostanában ez a divat, Angular meg React, SPA a kliensen – és mi az eredmény? Elindít n darab kérést, ha szerencséje van, egyszerre kimennek, ha nincs, mert a felhasználónak két évnél idősebb a telefonja, és már nem kap rá frissítést, és várakozhat, amíg minden adat egyesével becsorog. Tipikus példája ennek az Erste lakossági netbankja, ahol megelégeltem, hogy az Ext.js-re alapuló frontendjük húsz másodperc alatt töltődik be, mobilon harminc, csináltam magamnak egy saját felületet, ahol mindez megvan öt másodperc alatt. Vagy ugyanilyen tipikus példa a Facebook, ami máig használhatatlan mobilon, mert konkrétan tízszer annyi DOM elemet használnak, mint ami szükséges, meg a sok párhuzamos kérés végtelenül lelassítja a felületet.

Ez az egész teljesen irracionális. Teljesen mindegy, hogy tokeneket és/vagy süteményeket használunk, azokat n kérésnél n-szer kell szerveroldalon authentikálni, akár párhuzamos, akár nem. Aztán ez kliensoldalon is bonyolultabb kódhoz vezet, ráadásul, mivel a javascript egy soros nyelv, ígyis-úgyis csak egymás után tudod ezeket az adatokat megjeleníteni, azaz pontosan ott vagy, ahol a part szakad.

Ezzel szemben, ha egy kérés megy el, ami minden adatot összeszed, és azokat egyszerre adja vissza, azonnal spóroltál a betöltési időn és a kliensoldal is egyszerűbb lesz.

Tehát ha a párhuzamosság mind a szerver-, mind pedig a kliensoldalon csak problémákat okoz, akkor minek erőltetni? Én teljességgel ellene vagyok, a felhasználó is maradjon nyugton, ne kattintgasson addig össze-vissza, amíg az adott tranzakció el nem készült, főleg, ha pénzügyekről van szó. Én a magam részéről már SJAX-ot használok mindenhol.

Úgyhogy szerintem nagyon is hasznos a zárolás miatt a munkamenet, legalább nem nekem kell leprogramoznom, hanem megcsinálták és kitesztelték helyettem.
34

Igen

janoszen · Már. 20. (H), 14.44
Igen, sok esetben a farok csovalja a kutyat ha kozepes meretu csapatban / cegben dolgozol. Nincs penz / igeny kulon architektre, a featurenek viszont el kell keszulnie.

Ami a lockolast illeti, ez rendben lenne, ha a PHP session doksi nem promotalna orrba-szajba hogy milyen jo SQL/Memcache/stb backendet hasznalni sessionokre. Mindossze ezen az oldalon irjak emlites szintjen a zarolast. Azt sehol nem irja (FIXME) hogy ha nem a default file-alapu session handlert, akkor bizony nem kapsz lockolast. Kulonos keppen nem a custom session handlers doksiban.

Szoval ha Te egy szerveren boldog vagy a sessionokkel, akkor hajra, csak ha egyszer egy alkalmazasod tulno ezen, akkor gondolj vissza erre a threadre.
35

Több szerver

Hidvégi Gábor · Már. 20. (H), 15.35
Ha minden jól megy, hamarosan bővítenünk kell, bár először nyilvánvalóan az adatbázisokat tesszük külön, az a legegyszerűbb. A PHP FPM módban fut, azaz azt is szét lehet osztani több szerverre, a felhasználókat így könnyen tudjuk shardolni.

Mondom, alapvetően jót írsz, és ennek hatására én például biztosan fogok egy-két dolgot változtatni, de amire az érveket hozod, én azt nem látom olyan nagy problémának - aztán majd kiderül.
36

Zárolás

Hidvégi Gábor · Már. 23. (Cs), 11.01
Ami a lockolast illeti, ez rendben lenne, ha a PHP session doksi nem promotalna orrba-szajba hogy milyen jo SQL/Memcache/stb backendet hasznalni sessionokre
Átolvastam a php dokumentációját, de sehol nem találkoztam azzal, hogy kifejezetten promótálnák a saját munkamenetkezelők írását, ezt csak mint lehetőség említik meg.

A fenti cikkedben te sem említed közvetlenül, hogy a tokenes megoldással a zárolást magunknak kellmegoldani, márpedig anélkül lyukra szaladhat az egyszeri programozó. A szövegből pedig csak közvetve derül ki, hogy ez az egész szimbólumos varázslás leginkább több szerveres környezetben érdekes:
Például a PHP alapértelmezett munkamenet-kezelője ezt elkerülendő zárolja az adatokat, és egyszerre csak egy folyamatnak biztosít hozzáférést a sessionhöz, ami nem skálázódik túl jól. Egy elosztott rendszeren, ahol a zárolás nem jöhet szóba, az egy az egyben kiolvasott és viszaírt adattömeg folyamatos ütközésekhez fog vezetni.
37

Inkabb

janoszen · Már. 24. (P), 21.53
Nezd, Te atlatod hogy a session mikor jo, mikor nem, es milyen hatulutoi vannak. A mezei fejleszto nem. Eleg sok olyan alkalmazast lattam mar, ahol gyk. mindenre sessiont hasznaltak a t. fejlesztok, aztan jol meglepodtek amikor egy szep napon jott a versenyhelyzet. Raadasul $SESSION valtozon keresztul szolitottak meg, hogy meg veletlenul se lehessen elfedni a logikat.

Nekem ez a bajom az egesszel: van egy hatalmas zsakod ami azt igeri hogy tomb tarolast biztosit tobb requesten keresztul. A fejleszto nincs rakenyszeritve hogy elgondolkozzon azon, hogy ez hol fogja arcon vagni.
38

Vajon megoldható, hogy

inf3rno · Már. 25. (Szo), 07.29
Vajon megoldható, hogy megmaradjon a session, és a concurrency se okozzon gondot? A zsák helyett mi lenne a jobb megoldás?
39

Meg

janoszen · Már. 25. (Szo), 14.02
A session itt ket reszbol all. 1. egy egyedi azonosito, ami a felhasznalot azonositja. 2. egy adattarolo. Ha kidobod az adattarolod, marad egy egyedi azonositod.

Jatsszunk el a gondolattal: van egy egyedi azonosito, amit szerver oldalon is tarolunk. Ha ugy tartja kedvunk, akkor ehhez adatokat is kothetunk. Ezek jellemzoen a kovetkezo kategoriakba esnek:

1. felhasznalo azonositas
2. urlapok tartalma es az ehhez kapcsolodo hibauzenetek
3. felugro uzenetek oldalvaltasok kozott (flash messagek)
4. allapotok (pl. arukosar)
5. session-level cache

Felhasznalo azonositas

Ha a felhasznalo bejelentkezik, hozzakotjuk a felhasznalo objektumat a sessionhoz vagy tokenhez. Ha kijelentkezik, toroljuk. Igen am, de itt erdemes arra figyelni, hogy a biztonsagi best practicek azt javasoljak, hogy valtoztasd meg a session azonositot be- es kilepeskor. Vagyis itt mar serul az, hogy a munkamenettol fuggetlen a mukodes.

Nekem jobban bejott az a modszer, hogy belepeskor a felhasznalo kap egy auth tokent es az sutiben tarolodik. Minden olyan muvelet amihez felhasznaloi azonositas kell, csak auth token kisereteben vegezheto el.

Urlapok tartalma

Itt gyakorlatilag egy POST lekeresnel szerializaljuk az urlap tartalmat (PHP szerializacio, JSON, stb) es a kovetkezo GET lekeresnel elohivjuk.

Ez megint egy olyan dolog, amit akar kothetunk sessionhoz ha ugy tartja kedvunk, de tokeletesen felesleges szerver oldalon foglalni a helyet. Egy atlagos urlap tok szepen elfer sutiben kodolva. Nyilvan itt PHP szerializaciot hasznalni ongyilkossag, de a JSON + Base64 nekem tokeletesen bejott.

Biztonsagi szempontbol nem bir relevanciaval, mert ugyis visszakuldjuk a felhasznalonak az adatokat.

Felugro uzenetek

Itt kicsit kacifantos lesz a sztori, mert ha magat a szoveget taroljuk el, akkor sajat magat meg-XSS-ezheti a user. Tekintettel arra hogy az uzenetek tarolasa szinten nem biztonsagi kerdes, az uzenet helyett atadhatunk viszont egy forditasi (translation) kulcsot sutiben, ami megoldja a problemat.

Allapotok (pl. arukosar)

Ezek a fajta adatok a legritkabb esetben tartoznak szorosan a munkamenethez, sokkal inkabb a felhasznalohoz kothetoek. Mivel a legtobb ember mostanaban mar tobb keszuleken utazik (tablet, laptop, mobil) celszeru lehet ezt inkabb adatbazisban tarolni es a felhasznalohoz kotni munkamenet helyett.

Ha nagyon munkamenethez kell kotni, en itt praktikusnak erzem kiadni pl. egy kosar azonositot. Ez lehetove tesz olyan huncutsagokat is, hogy pl. elkuld egy linket a kosarhoz a masik keszulekre ha nincs belepve.

Session-level cache

Na itt utkozunk eloszor problemaba. Eloszor is, ennek szerver oldalon kell laknia. Masodszor komoly versenyhelyzetek lephetnek fel. Ha pl. eltaroljuk a felhasznalot, akkor a permissionjei csak a kovetkezo belepeskor valtoznak, ami a "maradj bejelentkezve" opcio hasznalataval igen sokara lehet. (Vagyis belefutsz a stale cache problemaba.)

Mivel en eloszotott rendszereken dolgozom, nekem a session-level cache nem opcio, inkabb optimalizalom kicsit a queryjeimet. Ha pedig statikus adatokrol van szo (pl. elerheto dijcsomagok), akkor az alkalmazasom indulasakor elinditok egy kulon threadet ami 15 percenkent lefrissiti az adatokat memoriaba. (Ezt PHP-ban is meg tudod csinalni, csak cronjobot kell irni ami Memcachebe vagy fileba betolja a frissitett adattartalmat.)

Kihagytam valamit?
40

Kliens

Hidvégi Gábor · Már. 26. (V), 13.44
Tegnap offline voltam, de sokat gondolkodtam a problémán, és ugyanerre a listára jutottam, mint te, bár a megvalósítást bizonyos esetekben másképp gondolom.

Amivel egyáltalán nem értek egyet, az az, hogy kliensoldalon bármilyen adatot vagy üzleti logikát tároljunk, több okból is:

Peter-Paul Koch blogján olvastam valahol azt a találó definíciót, hogy a kliensoldal, azaz a böngésző undefined, azaz csak találgathatsz arról, mire képes és mire nem, mennyi erőforrással rendelkezik. Ebből következik, hogy mindent, amit csak lehet, szerveroldalon kell megoldani, mert az a biztos pont az egész kommunikációs láncban:

  • az egyszerűbb kliensoldali logika miatt jóval kevesebbszer kell az ottani kódhoz nyúlni, azaz olcsóbb a karbantartása
  • ugyanemiatt jóval kevesebb a hibák száma
  • a rosszul megírt, lassú javascript nem meríti le a mobil eszköz akkumulátorát
  • pont az általad említett esetekben, amikor egy felhasználó több eszközről venné igénybe a rendszert, a kliensoldalon tárolt alkalmazásadatok egy készülékhez kötik az adott funkciót
  • ha megnézzük a weboldalak forrását, működését, kezdve a legnagyobbaktól: Youtube, Facebook, Microsoft – akiket mindenki másol –, egyértelműen kiderül, hogy a frontendesek túlnyomó többsége (99,9%-a) dilettáns, akik idő és tudás hiányában képtelenek jó minőségű kódot kiadni a kezükből; hogy mégis van munkájuk, az annak köszönhető, hogy a szakmában lévő elképesztő munkaerőhiány miatt nincs igazán versenyhelyzet
Éppen ezért én csak és kizárólag a lehető legbutább és legprimitívebb kliensben hiszek, ami lehetőleg JS nélkül is működik (SPA-k esetében pedig csak a megjelenítés a feladata), hisz ez a technológia a legnagyobb biztonsági rés az egész web történetében.
41

Vapici

janoszen · Már. 26. (V), 16.29
Vapici, hol allitottam en olyat hogy bongeszoben taroljunk uzleti logikat? En annyit mondtam, hogy sutikben lehet infot tarolni. Ha errol lemondasz, mehetsz vissza 1998-ba ahol URLben adunk at session ID-kat.
42

Sütemény

Hidvégi Gábor · Már. 26. (V), 17.44
Én adatot sem tárolnék benne, csak a munkamenet azonosítóját vagy tokenjét.

Persze attól függ, hogy ezeket az adatokat hogyan írod a html-be, ha kliensoldalon, akkor az már egy hibaforrás.
43

En is

janoszen · Már. 26. (V), 17.58
Es milyen okbol kifolyolag nem tarolnal benne adatot? Idestova 10 eve nem jelent problemat 1-2 kb-nyi adatot eltarolni kliens oldalon. Sot, lattam mar olyan oldalt is ami 4k-s header limittel gyonyoruen mukodott.
44

Már indokoltad

Hidvégi Gábor · Már. 26. (V), 18.02
Csak téged tudlak idézni:
Ezek a fajta adatok a legritkabb esetben tartoznak szorosan a munkamenethez, sokkal inkabb a felhasznalohoz kothetoek. Mivel a legtobb ember mostanaban mar tobb keszuleken utazik (tablet, laptop, mobil) celszeru lehet ezt inkabb adatbazisban tarolni es a felhasznalohoz kotni munkamenet helyett.

Ha nagyon munkamenethez kell kotni, en itt praktikusnak erzem kiadni pl. egy kosar azonositot. Ez lehetove tesz olyan huncutsagokat is, hogy pl. elkuld egy linket a kosarhoz a masik keszulekre ha nincs belepve.
A sütemény a böngészőhöz van kötve, nem az eszközhöz.
48

Szerintem félreértetted, amit

inf3rno · Már. 27. (H), 00.47
Szerintem félreértetted, amit írt, js-ről nem volt szó, csak arról, hogy cookie-ba teszi a dolgokat, aztán visszaolvassa következő kéréskor, hogy ne kelljen szerver oldalon tárolnia.

A js jó kliens oldalon, ha van b terv arra az esetre, ha letiltaná a felhasználó. A keretrendszerek elfedik a böngészők közötti különbségek nagy részét, úgyhogy általában nem kell ilyesmivel foglalkozni, ha használsz valamilyen keretrendszert. Vanilla js-t polyfillekkel kombinációban van értelme használni szerintem, vagy esetleg ha zárt csoportnak fejlesztesz, akikről biztosan tudod, hogy milyen böngészőt fognak használni.

szerk:
Abban igazad van, hogy külön kell választani ezeket a fajta adatokat aszerint, hogy mi az, aminek szinkronban kell lennie eltérő klienseket (akár egyszerre) használva, és mi az, aminek nem. Az előbbi resource state, és a szerveren kell menedzselni nem sessionben, hanem az adatbázisban, az utóbbi client state, és jobb ha a kliensben marad mondjuk cookie-ban, token-ben, js-ben, vagy bármi egyéb módon.
45

Zárolás

Hidvégi Gábor · Már. 26. (V), 18.26
Ahogy egyre többet gondolkodom rajta, úgy tűnik a tokenes megoldás a legésszerűbbnek. Viszont a zárolást még mindig problémának látom, vannak olyan műveletek, amit enélkül nem lehet elvégezni, vagy csak egy eszközön történhetnek meg használhatósági vagy felhasználói élmény szempontok miatt. Egy számlát például ne akarjon a tisztelt delikvens több helyről módosítani.
46

Nyilvan

janoszen · Már. 26. (V), 18.50
Ezt megteheted, de egy szamlazasi rendszernek a legritkabb esetben kell skalazodnia. Ha pedig kell, akkor jellemzoen batch feldolgozassal mukodik, nem kozvetlen muveletekkel. Vagyis a modositas / munkafolyamat elinditasa es a visszajelzes nem azonnali, hanem kesleltetett.
47

Mivel en eloszotott

BlaZe · Már. 27. (H), 00.28
Mivel en eloszotott rendszereken dolgozom, nekem a session-level cache nem opcio, inkabb optimalizalom kicsit a queryjeimet.
Azt hiszem értem mit akarsz mondani, de messzebbről nézve mindkét megoldás (cache és db is) csak egy data repository, ahol szükséges a concurrency hazardok megfelelő kezelése hozzáférés esetén. Mind a DB, mind a distributed cache-ek ismerik a tranzakció fogalmát (isolation level azért persze nem mindegy), tudnak entry (sql esetén row) level lockingot stb. Léteznek olyan distributed cache-ek is, amelyek tudnak indexelni, van sql-szerű lekérdező nyelvük is, valamint akár pl SQL servert is tudnak persistent storage-ként használni. Gemfire, Infinispan, Hazelcast, ami nálunk megfordult eddig. Ezek elég komoly sebességelőnnyel bírnak egy SQL serverrel szemben pl. Hogy userhez kötött entryket tárolsz benne, vagy sessionhöz kötötteket, nem nagyon számít. Van viszont más megfontolandó dolog, pl clustering mode (replicated vs invalidation based vs distributed), synchron vs asynchron írási mód, felléphet split brain stb.

Viszont két különböző dolog keveredik itt szerintem a hozzászólásokban, ami nincs eléggé kiemelve. Egyrészt szükséges a repository atomikus hozzáférésének biztosítása (akár http session, akár más), de ennél kevésbé triviális, hogy az üzleti logika mennyire és hol van kitéve race condition lehetőségének. Egy olyan megoldás, ami egy egész request feldolgozás idejére rádob egy exclusive lockot, sorosítani fogja a requestek feldolgozását, legyen szó író, vagy olvasó requestekről. Itt ha jól értem, akkor a cikk erre a problémára van felhúzva. Ami tehát nem mindegy:
- lockolás granularitása (pl a baromi drága validációnak semmi helye egy critical sectionben)
- lockolás módja (pl exclusive vs read/write lock, pessimistic vs optimistic lock)

Nagyobb teljesítményű, skálázhatóságra tervezett rendszereknél olyan megoldást kell választani, ahol ezek a választási lehetőségek fennállnak. Egyértelmű, hogy itt a php sessionje már nem elfogadható megoldás.

Érdemes még megemlíteni, hogy ha architecturálisan megoldható, single writer alkalmazásával akár teljesen el is hagyható a lockolás és csak az atomicitást kell tudni biztosítani, a readereknek nem kell várakozniuk a writerre és viszont. Ez már persze messze nem triviális, pl a single writer node(ok) el is halálozhat(nak). A lényeg, hogy vannak opciók a concurrency és a skálázhatóság kezelésére. De megfelelő tapasztalat híján a vége garantáltan fejvakarás lesz.
49

Azt hiszem concurrency

inf3rno · Már. 27. (H), 00.55
Azt hiszem concurrency kezelés alapjairól születhetne egy cikk, ha van kedved hozzá.
50

yesplease

janoszen · Már. 27. (H), 12.44
yesplease!
51

Biztos?

Hidvégi Gábor · Már. 27. (H), 15.28
Kérdés, hogy hányakat érint, és értem ez alatt azokat, akiknek a PHP sztenderd zárolási mechanikája a fentebb vázolt okok miatt már kevés.

Nagyon érdekes téma, de eléggé bele kell nyúlni a meglévő programba a használatához, és nem biztos, hogy ez a felület a legalkalmasabb arra, hogy egy jó és biztonságos alapkód elkészítéséhez.
52

PHP

janoszen · Már. 27. (H), 16.54
A PHP-nak ennek semmi koze. Amit Te PHP zarolasi mechanikanak nevezel, az gyakorlatilag egy flock() hivas. Ezen felul rengeteg fele keppen lehet zarolast csinalni, PHP-ban es mas nyelven is. MySQL-ben SELECT... FOR UPDATE-el, Memcacheben spinlock-kal, stb. Azert nem lenne baj ha ez el lenne magyarazva egyszer rendesen tekintettel arra hogy sokan hasznalnak ilyeneket.
53

PHP

Hidvégi Gábor · Már. 27. (H), 19.33
Azért írtam PHP-t, mert a legtöbb webes projekt ebben készül.
55

OK

janoszen · Már. 28. (K), 01.33
OK, de akkor miert van az, hogy az elmult 10 evben minden aldott projektnel belefutottam ebbe? Es nem, 10 eve nem epitettem meg elosztott rendszereket, csak epp kicsit kinotte az akkori vasat a szoftver.
54

+1, remélem nyelv mentes

inf3rno · Már. 27. (H), 23.25
+1, remélem nyelv mentes lesz, ha bevállalja, vagy legalább nem php-ről fog szólni.
56

Gondoltam már rá

BlaZe · Már. 28. (K), 23.30
Gondoltam már rá, hogy hasonló témákban - többszálú programozás/concurrency, (realtime) teljesítmény mérés és optimalizálás (esetleg Java/JVM specifikusan) - írok cikket. Gyakorlati példákat webes környezetből nem igazán tudok hozni, mert már jó sok éve olyan rendszereken dolgozok, ami nagyon messze van bármilyen GUI-tól. Leszámítva a JMX consolet és a monitorozást :) Amennyiben ez így érdekes lehet, akkor szívesen összerakok egy cikket először a concurrency/multi-threading témában.

Ha esetleg van még pár téma felajánlás, akkor az én kedvem is még nagyobb lesz cikket írni... ;)
57

Szerintem teljesen mindegy a

inf3rno · Már. 29. (Sze), 06.07
Szerintem teljesen mindegy a környezet, én legalábbis az alapelvekre vagyok kíváncsi, hogy mások hogy oldják meg a problémát, hátha tanulok valami újat. :)
58

Mindenkeppen

janoszen · Már. 29. (Sze), 09.10
Engem mindenkeppen erdekelne, sot ha a JMX konzolrol irsz akkor kulon halas leszek. Hany sorben merik a cikkedet? Sztem osszedobjuk. :)
59

Web

Hidvégi Gábor · Már. 29. (Sze), 16.53
János, te viszont a fentiek alapján webbel foglalkozol, és biztos találkoztál már jó megoldással az elosztott rendszerek plusz zárolás témakörében, nem? Egy ilyen írás is hasznos lenne gyakorlati megoldásokkal.
60

Alapovetoen

janoszen · Már. 29. (Sze), 22.45
Alapvetoen nekem az a megoldasom, hogy amit lehet azt idempotens modon valositom meg, amit meg nem lehet, ott lenyelem a keserut es zarolok. Roviden jatszottam MerkleDAG es hasonlo megvalositasokkal (IPFS, stb), de vegso soron csak azt a problemat oldja meg hogy vissza lehessen kovetni a modositasokat, az inkonzisztenciak osszefesulese tovabbra is gond. Nagyon specialis adathalmazokkal meg lehet oldani, de altalaban az ember nem ilyenekben gondolkodik. (Nagyon szeretni kell a fajdalmat ahhoz hogy az ember onszantabol igy strukturalja az adatait akkor is amikor nem muszaj.)

Egyebkent meglepo, de pl. banki rendszerek sem feltetlenul mukodnek zarolassal, ezert tudsz minuszba menni a szamladdal akkor is ha nincs beallitva hitelkeret. Egy kis webshopnal ez nyilvan nem opcio, ott egy 10e Ft-os hiany is nagyon faj, de pl. Amazon meretekben mar egeszen mas a teszta. Ezen a ponton ez masszivan uzleti dontes, nem technologiai.

Cikket irnek rola, de attol tartok hogy ahhoz elobb erosen utana kene olvasni az elmeletnek mert elegge "gyakorlat-szagu" a tudasom. (Tuti belem lehet kotni jo sok helyen hogy az nem is ugy van.)
61

+1, én is úgy tudom, hogy

inf3rno · Ápr. 4. (K), 16.07
+1, én is úgy tudom, hogy nagy méretekben inkább az üzleti döntések vezetik kód író tollát. Erősen számít a egy-egy dolog üzleti hatása, illetve az is, hogy automatizálni éri meg jobban az adott műveletet, vagy felvenni rá alkalmazottat. Ennek részben emberi oldala is van, ha türelmetlenné válik az ügyfél a szoftver hülyeségei miatt, és ezért veszítesz el egy nagy rendelést, az azért probléma, szóval egy szint felett inkább alkalmaznak valakit, akivel tárgyalhat az ügyfél.
62

JMX

BlaZe · Ápr. 4. (K), 21.44
JMX-szel kapcsolatban mi lenne az érdekes? Maga a JMX mire való, milyen alkalmazások vannak hozzá (jconsole, Visual VM, Mission Control etc), ott miket lehet csinálni? Vagy hogy hogy kell JMX szolgáltatást írni? Esetleg hogy lehet realtime monitorozásba bekötni?

Mi egyébként speciel monitorozásra pont nem használjuk a JMX-et. Prod supporthoz vezettünk ki rá funkcionalitást, amivel bele tudnak nyúlni dolgokba, ha issue van.

Egyelőre concurrencyről kezdtem el rendszerezni a gondolataimat. De sör méréshez más indokot találjunk. Sör, meg a concurrency nem barátok :)
63

Java

janoszen · Ápr. 5. (Sze), 07.05
Par honapja kezdtem bele a Javaba komolyabban. Ugyan az egyeb teruleteken szerzett tudasom sokat segitett, azert vannak homalyos foltok. Konkretan jelenleg az olyan problemak foglalkoztatnak, hogy valamelyik kivalo library miert memleakel production kornyezetben.
64

Proghun volt egy hasonló

BlaZe · Ápr. 5. (Sze), 09.02
Proghun volt egy hasonló téma, érdemes belenézned. Ha az ottani tippek nem visznek előrébb és van konkrétum, nyiss rá szálat, vagy keress meg privátban, megpróbálok segíteni.

Melyik lib csinálja amúgy?
65

Koszi!

janoszen · Ápr. 5. (Sze), 15.20
Koszi, futok vele par kort. Egyelore nem tudom, mi csinalja, es az sem biztos hogy nem csak a brutalisan kicsi container az oka, szal figyelem a torteneseket es meglatjuk. Koszonom a tippeket.
66

A container memory használata

BlaZe · Ápr. 5. (Sze), 22.50
A container memory használata miatt gondolod, hogy leakel, vagy a JVM heap usage utal erre? Ha a heapnél azt látod, hogy GC-k eredménye egyre laposabb (egyre kevesebb memóriát tud felszabadítani), akkor ott valami leakel. De JVM-nél az általános, hogy ahogy melegszik be, egyre több memóriát használ, amíg el nem éri a teljes üzemi állapotot, és akkor ott beáll. Ez loadtól függően akár tovább is eltarthat. Pl egy metódusnak alapbeállítások mellett 10.000 hívás kell, hogy a JIT érdemesnek tartsa az injektálásra, és csomó minden hasonlóan működik. Az allokált heapet is igazítja a használathoz. Egészen alacsony szintről (-Xms) felemelheti szép lassan a maximum engedélyezett méretig (-Xmx). Ezek együtt ha kívülről nézed, tűnhetnek leaknek, pedig nem feltétlenül az. Emellett sokféle memóriaterülete van a heap mellett: stack (nyilván :)), code cache (ide kerülnek a betöltött natív libek, a lefordított java byte kód), off-heap memory, java8 előtt PermGen, azóta metaspace, és persze maga a JVM is igényel memóriát. Egy szó mint száz, ha kívülről nézed, vonhatsz le rossz következtetést.

Eszembe jutott még egy cikk: Why does my Java process consume more memory than Xmx?
Illetve plumbréknek van egy GC handbookja, ez szerintem egyértelműen must read.