Sziasztok!
A minap készítettem egy felületet ahol a kezelő egy munkalapot kap maga elé, amelyre rátettem egy tovább gombot.
Az említett tovább gomb ajax segítségével feltölti a fél képernyőt, de a feldolgozó oldalnak szüksége van arra, hogy csak akkor működjön ha a kezelő be van jelentkezve. Ezt session-nel oldottam meg. Mivel egy másodperc alatt 3-4 szer is kattinthat így annyiszor lefut a kérés. Amit látok, hogy a kicsi session file a merevlemezen minden híváskor frissít. Minél kevesebb terheltetéssel szeretném megoldani, de a kezelő validálása mellett. (Ezért voltam a session mellett mert a logint nem tárolom további adatbázis műveletekhez és böngésző becsukáskor vége mindennek)
Ez így mennyire nyerő, ha egy nap 10000 darab kattintás is lehet ? (pl lapozgat, de indul mindig a "session_start()..."
Milyen technológiával váltanád ki a munkamenet kezelést ?
Köszönöm.
Robi
Hozzászólások
Ha a disk I/O zavar, vagy maradj a fájlnál és dobd ki tmpfs-re, vagy dobj fel egy memcached-et és állítsd át a session.save_handler-t a php.ini-ben.
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
Mindenképp munkamenet kezelés lesz az. 10k kattintás az néhány mp-enként egy, ha mondjuk 8-18 órás felhasználást nézel. Ha rendesen van megírva és nem valami őrült méretet tárolsz a session változóban, akkor ez nagyjából rendben lesz. Ha mégis akarsz tuningolni, akkor meg lehet nézni, hogy a redis-es natív PHP sessionkezelésre mennyire lehet rávenni a környezetet. Ezt csak akkor nézegetném, ha valóban indokolt,
kb 200 bájt a session fájl.
felhasználó-id
bejelentkezés ip (mely terminálon dolgozik, ez azért kell mert akkor egy print parancs a mellette lévő nyomtatóra kerül, ergo ment és lesz egy kinyomtatót címkéje plusz kattingatások nélkül)
automata funkció engedély (1 / 0 állásban további perifériára) : ennyit tárol összesen. Ezzel az a célom hogy a legkevesebb interakcióval, felhasználó barátan dolgozzon. Amit automatizálni lehet tegyük meg. Kövezzetek meg nyugodtan de egyszemélyben notepad++ban írtam meg az egészet php nyelven. Saját mini framework-öt írva... és a backendet (html, javascript,css) is én készítettem.
Látom a mappában folyamatosan változik a fájl ideje. Ez mennyire öl meg egy ssd-t ?
Amit észrevettem, hogy 5.000ből egyszer permission denied session hiba üzenetet kapok.
> bejelentkezés ip
Mi? A kliens ip címe miden kérésnél elérhető a globális változók között, teljesen indokolatlan sessionben tárolni! Szintén szerencsétlen az autentikációt a sessionon keresztül biztosítani - mondjuk ha csak azt nézed, hogy van-e sessionben egy login=true, akkor nem értesülsz arról, h az admin közben letiltotta v. törölte felhasználó belépését a rendszerbe, aki így továbbra is belépve marad. Ezt csak úgy tudod elkerülni, ha a belépési adatok és session valahol (pl. az adatbázisban) össze vannak kapcsolva.
Biztos nagyon szuper rendszert írtál, de azért első blikkre is van min aggódni az SSD "terhelésén" kívül :)
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
Hacsak nem akar session hijacking ellen védekezni valahogy...
és ha nincs ilyen feature? (Mármint igény sem volt...)
Ugye, az IP hijacking nélkül, normál felhasználás során is megváltozhat egy session ideje alatt :-Z
De itt valami nyomtatás miatt akarta tárolni.
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
Nyilván - ezért aztán ha valaki (felhasználó) belefut egy ilyenbe, akkor így járt. Attól még más eszközöd nincs nagyon a hijack ellen.
Kettőnek semmi köze egymáshoz. Az egyik authentikáció (ellenőrzöd, hogy valóban azé-e a session, akié), nem valaki más lopta el a session id-jét - authentikáció - (régi szép PHPBoard-os URL-ek, ahol URL-ben utazott a session id, yay...), a másik meg authorziáció, hogy van-e joga azt csinálni, amit akar.
Az authentikáció a felhasználó azonosítása - magyarán a rendszerbe való beléptetése. Ennek a tiltásáról írtam. Az authorizáció a már belépett felhasználó különböző tevékenységeinek az engedélyezése.
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
Ahhoz, hogy le tudd tiltani, ahhoz először azonosítani kell :)
A jó megoldás szerintem is valami memcached lehet (illetve egy rendes programozási nyelv használata, amiben memóriában tudsz tárolni változókat eleve :-P), de ha csak ezt a problémát néznénk, akkor szerintem a jó megoldás az, ha a session fájl-t úgy írod meg, hogy ne változzon, csak akkor frissíted be, ha tényleg változott, beállítasz egy noatime-ot mellé, és akkor nem kopik tőle az SSD.
Vagy ha mindenképpen változni kell a session fájlnak, akkor RAMdiszk-re kell tenni. Persze az nem éli túl az újraindítást, de jó esetben nem is kell folyton újraindítani a szervert.
Szerintem meg először jussunk el odáig, hogy legyen 10000 oldallekérés.
Egyrészt van a mondás, hogy ne optimalizálj korán. De a másik serpenyőben ott van, hogy ha véletlenül bejön valami, népszerű lesz, és attól lerohad, akkor a siker kapujából zuhan vissza az oldal. Onnan nem nagyon van visszaút. Ha fundamentálisan szar valami, akkor azt nem lehet megmenteni később sem. A tervezésre igenis kell időt fordítani.
Oké, a session ojjektumot bármikor ki lehet cserélni ésszerűbbre, tehát ha ez szar marad az elején, az nem katasztrófa.
De a kérdező nem azt kérdezte, hogy érdemes-e az álmodozás szintjén optimalizálni, hanem hogyha optimalizálni kell, akkor azt hogy kell megcsinálni. Illik a kérdésre is válaszolni.
tl;dr: Napi 10000 oldalletöltés az lófasz kategória. Gyakorlatilag nem kapsz olyan pici VM-et sehol, ami ezt a session kezelést fileből ne oldaná meg. Ok, alkalmazás lehet komplexebb logikát igénylő dolog is, de leírásból nem úgy tűnik. Szerintem minden más elhangzott már a topicban. Nem kell overengineeringelni első nekifutásra, lehet iterálni is.
Még a memcached is overkill rá.
(Egyébként egy korábbi munkámnál volt sessionra memcached anno, aztán inkább kidobtuk, mert azt a terhelést a DB is elvitte, memcached csak plusz komplexitás volt és igazából összességében lassabbnak bizonyult, mintha a DB-t használtuk volna (ezen egy picit meglepődtem, de ez jött ki a mérésről.)
Egyébként az oldal olyan 50-200 query-t csinált egy-egy request alatt, napi requestek 10-100k között voltak. PHP sebességéről annyit, hogy miután ki lett mérve, hogy a futásidő 90-95%-a úgy is a DB-re esik, szartunk rá, ha csak nem volt valami kifejezetten lassú.
JWT. De ezen a szinten (mind szaktudásra, mind feladat komplexitásra gondolva) inkább írd meg rendesen sessionnel.
Mindenkepp a szerver oldali session, ami cookie-n keresztul van osszekapcsolva a klienssel a megoldas módja. Mindel hamarabb es foleg rovid ideig van a session nyitva, annal kisebb a konkurrencia. De nyilvan van.
Ha ez lassu, akkor vannak megoldasok ahogy írták masok is: memcached vagy redis. De azok is irnak tarolót. De az apache log is minden keresnel íródik. Ilyen egy szerver :)
A memched/redis tarolo meg cloud-ready-ve is teszi az alkalmazasodat, ennek is nezz utana. Jo lesz.
Mitől lesz az alkalmazás cloud ready, hogy ha a PHP kezeli a session-t natívan redis vagy memcache alapon, eleve, ez mitől cloud, hogy egy külső helyen lehet tárolni mégvalamit?:)
PHP + cloud ready = oximoron
Ezt fejtsd ki kerlek
http://www.youtube.com/watch?v=xnJwT_30p6k
Csak szarkazmus akart lenni, de lemaradt a smiley
gondolom arra gondolt a kolto, hogy 1 memcached + sok frontend php szerver es lehet szepen terheleselosztani vagy inditgatni-leallitgatni a szervereket terheles fuggvenyeben, amirol az egesz cloud mizera szol mostansag
Pont erre gondoltam, sessiont kozos helyen kell tarolni hogy cluster (php eseten ez ha + par node) minden eleme elerje. Erre regen meg divat volt az adatbazisos session is.
Cloud ready emellett meg sok dolgot jelent, de minden skalazhato legyen.
Jahogy a skálázhatóságra gondolt, az még nem klód szerintem. :) Az adatbázis oldalon azért ezek a "jajjakkormajdelindul és skálázol" kérdések erőset szoktak bukni (és nem a db szerver miatt). :)
Ez alapjan kevesse hiszem, hogy ennek cloud readynek kell lennie, valamint megerne kitolni coudba, es vissza, csak azert, hogy kinyomtasson az irodaban egy munkalapot :)
session kezelés a legjobb.
php natívan is tudja memóriába menteni, ha memcache-t használsz, és semmilyen réteget nem használsz a session menedzsmentre (ami egyébként ajánlott)
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
Köszönöm a segítségeteket.
Az "ezen a szinten"-re válaszolnám, hogy nincs ilyen igény. Itt 1 felhasználó hónapokig bent lehet. Ez egy mérleg program lett.
Miért tárolom az ipt: mivel kiosk fut rejtegeti az ip címét, egyszerűen az átjárót tudom kinyerni, valamint állíthatja a kezelő a beállítását, hogy mely területen dolgozik
1 ilyen mérőponton 3 darab ip eszköz van: 1. tcp sockettes mérleg fej, 2. kiosk pc, kijelzővel, 3. zebra tiket nyomtató
Jelen pillanatban már javában átléptem a cinikus napi 10.000darabos lekérdezéseket. Minden lokálisan fut, és több ezer termék mérésére - felcímkézése találtam ki. Becsült terhelésem 5000db termék címkézése /nap, a mérlegre meg másodpercenként lefut a kérés. Legalább ennyivel tudtam segíteni a kollégáimnak.
Köszönöm az építő tanácsokat. Köszönöm a ráfordított idődet.
Mi lett a megoldás?