Miért nem ment a Felvi.hu?

Hálózatok egyéb

Technikailag megoldhatatlan, hogy akkor is elérhető legyen amikor a megszokotnál többen látogatják (pl. jelentkezés leadása, ponthatárok kihirdetése stb.)?

Engem nem érint, mert már hetekkel ezelőtt jelentkeztem, de minden évben előre lehet tudni (több mint 6 éve), hogy a szolgáltatás órákra, napokra, sőt hetekre nem lesz elérhető és ez rendre be is következik, ahogy idén is.

Mégis, ma amikor hatékonyan skálázhatók a rendszerek (virtualizációs megoldásokkal stb.) ha előre tudják mekkora terhelésre számíthatnak miért nem készülnek fel?

Vajon mi lehet a szűk keresztmetszet? (szoftveres, hardveres kiépítés, kapacitás stb.)

Ez egyébként normális, megszokott más országok azonos szolgáltatásai esetén is?

Laikusként ezt elég nehéz elfogadni, engem nem érdekelnek az adatbázis szerverek, SQL lekérdezések stb., csak az, hogy ami előre tervezhető az működjön.

Ennek megfelelően a Posta ami 6-ig van nyitva 6:00 perckor zár.
A vonat ami 6 órakkor indul 6:00 perckor indul (Japánban, Magyarországon 6 és 7 között, de ez elfogadható a MÁV esetében, pedig ez automatizálható).

Egyetemre jelentkezni a határidőig a nap 24 órájában lehessen, váratlan esemény történhet (de ne 6 vagy még több éven keresztül sorozatban). Az is örvendetes lenne ha nem veszítenék el az érettségire jelentkezések adatait.

Én többnyire határidő előtt adok le mindent, engem inkább a bizonytalanság irritál, óramű (svájci és japán) pontosságú szolgáltatásokat akarok, a vonat 6:00-kor induljon (ha 2 percet késik legyenek felelősségrevonások), az állami szerverek 0-24h elérhetőek legyenek.

Pozitívum, hogy hajnali 2-ig másnap este 10-ig meghosszabbították a jelentkezés határidejét.

Update:

Hugom szerette volna hitelesíteni a jelentkezését, nem ment neki.

Hiba!

A rendszer adatbázisfrissítés miatt átmenetileg - előreláthatólag két napig - nem elérhető. Ezt követően, amennyiben még nem hitelesítette jelentkezését, akkor 2010. február 23-ig hozzáférhet a hitelesítést szolgáló funkciókhoz, de adatot nem módosíthat!

  • 5774 megtekintés

( BaT | 2010. 02. 16., k – 00:55 )

Ugyanez a kérdés áll a neptunra (etr-re?) is. Bár meg kell jegyezni, határozottan fejlődnek.

Hát mikor bme-n a neptunos fejes azzal fogadta az elsősöket, hogy a neptun pont akkor nem fog menni, amikor szükség van rá (persze ezt így nem mondta ki), mert egy rendszert se csúcsra méreteznek (azaz arra, amikor használják is). Akkor kicsit megrendült a bizalmam úgy az egészben.

( peterson v | 2010. 02. 16., k – 07:52 )

Szerintem két oka lehet a jelenségnek:
1.) software:
az alkalmazások SQL lekérdezései, PHP (vagy egyéb) kódjai nincsenek optimalizálva, így nagyobb terhelésbe belerohad. Ebben az esetben a felháborodásod teljességgel jogos. DE! Feltételezem hogy a kódok 6év tapasztalattal, és fejlesztéssel már optimalizáltak amennyire lehet. (Magyarországon vagyunk, állami szerver, tehát semmi sem biztos ;) , de reménykedünk).
2.) hardware:
ha a vas kicsi, akkor egy komoly gazdasági tényt figyelembe kell venni, miszerint a szerver ilyen mértékű terhelése évente 2x4 óra. Ha ehhez igazítják az erőforrásokat, akkor lesz egy bivalyerős szerver, ami egy évben működik 8760 (vagy 8784) órát. Ebből ~8 órát vannak kihasználva a képességei, a maradékban gyakorlatilag pihen. De fenn kell tartani, és kva drága pénzért meg kellett venni, évi 2x4 óra miatt.

Alternatívaként el tudom képzelni azt, hogy szereznek állami szinten néhány nagyon erős (tényleg nagyon erős) vasat, és arra tesznek minden állami portált és szolgáltatást. Amikor pedig tervezhető túlterhelés van (pl felvételi, vagy adóbevallás stb.), akkor tervezetten felfüggesztik a többi, éppen nem sürgős szolgáltatásokat, és minden kapacitást a várhatóan túlterhelt szolgáltatásnak adnak kb határnap este 8 és éjfél között. Lehet rosszul gondolom, és ennek nem lenne értelme?

---
"A megoldásra kell koncentrálni nem a problémára."

2.) hardware:
ha a vas kicsi, akkor egy komoly gazdasági tényt figyelembe kell venni, miszerint a szerver ilyen mértékű terhelése évente 2x4 óra. Ha ehhez igazítják az erőforrásokat, akkor lesz egy bivalyerős szerver, ami egy évben működik 8760 (vagy 8784) órát. Ebből ~8 órát vannak kihasználva a képességei, a maradékban gyakorlatilag pihen. De fenn kell tartani, és kva drága pénzért meg kellett venni, évi 2x4 óra miatt.
+1

Az autópályán is dugó van nyáron a nagy szabadságolási hullámok alatt (külföldön is), a boltban is dugó van, ha ákcióta sajt van (külföldön is), a neten is dugó van, ha sok okos utolsó pillanatban kezd gondolkozni - bankok, apeh, stb - (külföldön is).

Mondjuk azért, mert az év nagy részében simán elketyegne viszonylag kis erőforrásigénnyel (kisebbel, mint ami most rendelkezésre áll), míg időnként óriási terhelést kap, amit nem bír kiszolgálni. És nem ez az egyetlen ilyen rendszer Magyarországon, hiszen hasonlóan egyenetlen terhelést kaphat időnként mondjuk az APEH oldala, de mondjuk ugyanez van sok főiskolánál is, akik meg a vizsgajelentkezésekkor omlanak össze a terhelés alatt. Egy kormányzati cloud computing szolgáltató központ jó megoldást jelentene azoknak, akik csak ritkán számolnak nagyobb terheléssel, de akkor aztán komoly roham van. Semmi értelme például a Gazdasági Főiskolának komoly saját szerverparkot üzemeltetni csak a Neptunos jelentkezések miatt, jó helyen lenne ez egy központi cloudban. Egy helyen mehetne a Sulinettől kezdve sok minden, valószínűleg olcsóbb és hatékonyabb lenne, minthogy mindenki saját szervert etet a pincében. Ennek az a csúcsa, amikor egyes közoktatási intézmények képesek a saját weboldalukat is a tanáriban lévő ócska gépről működtetni, ami az éppen elérhető legolcsóbb adsl előfizetésen lóg. Óriási pazarlás, hogy az adófizetők pénzéből nagyrészt kihasználatlan kapacitásokat építgetnek, miközben azok akkor, amikor tényleg szükség lenne rájuk, összeomlanak.

Nem veszed észre, hogy ez az egész "probléma" egy levegőbe lövöldözés?

De ne lövöldözzük legyünk tényszerűek:

1. Tudjuk, hogy a mostani informatikai struktúra milyen? NEM
2. Tudjuk, hogy a cloud computingal pontosan hogyan, mennyiből lehetne megvalósítani? NEM
3. Tudjuk, hogy ez egy valóban létező probléma? NEM

Akkor minek itt fogalmakkal dobálózni? Meg szénnéműveltinformatikaifőszakértőként ezatutjómegoldásmegmégtrendiis javaslatokat tenni?

Egy felvi.hu szeru lap eves terheleset abrazolva egy minimalis varianciaju gauss gorbet kapunk, ahol a gorbe alatti terulet lenne a szukseges eroforras biztositas koltsege. Ezt pedig cloud-al lehet a legjobban felulrol kozeliteni nem pedig egy konstans gorbevel (aka sajat szerver). Feltetelezve termeszetesen, hogy a felvi.hu maximalis uzemidore torekszik, mert kulonben az optimalis megoldas a legolcsobb dzsunka PC lenne ;)

Hmm, ervek?

A cloud de facto definiciojabol kovetkezoen nagy.
Marpedig minnel nagyobb egy cloud annal kissebb az egyes rajta futo alkalmazasok terhelesenek reszaranya => egyre pontosabban lehet eroforrast optimalizalni.

Uzleti oldalrol meg ugye van a ceg, aki cloudot szolgaltat, es egyedul az o dolga, hogy minnel jobban ki legyen hasznalva a rendszere.

A felvi.hu pont az az eset, amire a cloud-ot kitalaltak.

Ja, hogy a felhőt valaki szolgáltatná? Az nem biztonságos. Én nem szeretném, ha . az ügyfélkapuval kapcsolatban lévő - felvi.hu-n lévő adataimat egy magáncég kezelné.
Ha meg egy cégnek saját magának kell felhőt alkotni, az nem fog még három teletömött servert venni, hogy bírja a felhő. Akkor már inkább a másik divat, a virtualizálás, bár szerintem az is csak porhintés.

Ave, Saabi.

Felhő vagy nem felhő, számítógépes rendszert vagy csúcsra méretezünk vagy standard felhasználásra. Ha csúcsra, akkor erőforrást pazarlunk, ha standardra, akkor megfekszik ha csúcsra járatják. A számítástechnikában nincsenek új csodák, a felhő kifejezés is csak ködösítés.

Ave, Saabi.

Nem mindegy, hogy több külön-külön üzemeltetett rendszert tervezel külön-külön csúcsra, vagy több együtt üzemeltetett rendszert tervezel csúcsra. Az utóbbi esetben csak abban a szélsőségesen rossz esetben szükséges annyi hardver, mint amennyi az első esetben, ha a rendszerek csúcsterhelése egy időpontra esik. Ideálisan szélsőséges esetben pedig elég annyi hardver, amennyit a legjobban terhelt rendszer igényel, hiszen ideális esetben az egyes rendszerek csúcsterhelése nem egy időponta esik.

Aki ezt nem látja át, az lehetőleg ne kerüljön üzemeltetés közelébe, de még fejlesztést se vezessen.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Ha konkrét feladatra - vagy feladatokra - méretezek egy gépet, akkor jól meghatározott körülményekre kell felkészülnöm. Mivel manapság elég kevés az olyan operációs rendszer, mely csak egy feladatot tud ellátni, nem szükséges feladatonként külön gépet üzembe állítani.
A cloud-computing se szól nagyon másról, csak itt sok gépet használnak olyan feladatra, amelyet egy is el tudna látni plusz még ködösítenek is egy kicsit. Kíváncsi vagyok, mi történik egy felhővel, ha a használatával kapcsolatban felmerül olyan igény, hogy ennek vagy annak az alkalmazásnak garantált teljesítményt tudjon nyújtani? Ekkor bizony erőforrásokat kell dedikálni, melyek akkor se adhatóak oda másnak, ha éppen nincsenek használva. Ha egy másik alkalmazás meg olyan rettentően titokzatos adatokkal dolgozik, amelyek nem kerülhetnek senki mással kapcsolatba, akkor máris dedikált számítógépekre tart majd igényt. És a felhő elkezd foszladozni.
Ésszerű tervezés és szervezés esetén nincs szükség a cloud és a virtualization nevű buzzwordökre, csak egy erős vasra és egy jó oprendszerre. Az erőforrások optimális felhasználásának kérdése ugyanis egyidős a számítástechnikával és a megoldások se az új buzzwördökkel születtek.

Ave, Saabi.

Ésszerű tervezés és szervezés esetén nincs szükség a cloud és a virtualization nevű buzzwordökre, csak egy erős vasra és egy jó oprendszerre.

...és vastag pénztárcára.

Kíváncsi vagyok, mi történik egy felhővel, ha a használatával kapcsolatban felmerül olyan igény, hogy ennek vagy annak az alkalmazásnak garantált teljesítményt tudjon nyújtani?

Akkor nem alkalmas rá a cloud kialakítás. Kivéve, ha pontosan tudod, hogy mikor éri az a terhelés és csak akkor foglalod be a megfelelő erőforrásokat. Ha semmiképp nem tudod másképp megoldani, akkor a _lehető_ _legrosszabb_ esetben is csak ott vagy, mint cloud nélkül.

Az erőforrások optimális felhasználásának kérdése ugyanis egyidős a számítástechnikával és a megoldások se az új buzzwördökkel születtek.

Én jelenleg olyan helyen dolgozom, ahol a terhelésben nem ritka a tízszeres különbség két nap között, viszont előre tudható, hogy a hónapban melyik egy-két nap lesz az, amikor ez bekövetkezik. Erre a konzervatív megoldás az, hogy évente 20-25 nap miatt a maradék 340 napon infrastruktúra 90 százaléka pihen.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

jaj.

A cloud arra jó, hogy nem használ egymillió-öt cég saját poweredge 2950-est, hanem egy cég tart ötvenezer poweredge 2950-est és azon az egymillió-négy másik cég mindig csak annyi CPU/IO-t eszik, ami kell neki. Hardvert nem neked kell supportálnod, lófütty bt csődbemenetelénél nem veszted el 5 évre a géped, etcetc. Illetve a felhőben a dedikált erőforrásigény provisioning kérdése, nem fizikai hardverhez kötésé. Kevered a virtualhostokkal a dolgot.
S mi történik a cloudban, ha tudod, hogy nagy terhelés jön, mertpl adobe vallás időszak van? több erőforrást rendelsz az adott területért felelős gépekhez. Vége az időszaknak? visszaveszed, s a felszabaduló erőforrásokat máshoz használod. Nem kell +15 gépet telepítened, átkonfigurálnod, mozgatnod, mert épp olyan időszak van.

Így kilencszázötvenezer-öt gép fogyasztását, árát, fenntartási egyéb költségeit, környezetterhelését megspóroltad.

Ha az adataid miatt fosol, akkor miért írod le a nick-ed? hiszen az alapján sok mindent meg lehet tudni az emberről...

Egész hozzáállásodból látszik, hogy nem is érdekel, hogy mire használják a virtualizációt, csak szajkózod az erős vasat meg a jó oprendszert.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Ahem, cloud mint szolgáltatás. Tehát nem az alkalmazások és az adatok gazdái, tulajdonosai üzemeltetik a felhőt, hanem egy másik cég. Ez analóg az outsourcingal? (ahol az üzemeltetést nem a számítógéppark tulajdonosa biztosítja, hanem megveszi szolgáltatásként)
Nos, akkor a kérdés leegyszerűsödött, csak meg kell várni a felhő(ben járó) szolgáltatókat és hogy van-e a szolgáltatásukra valódi piaci igény. Én ugyan kétlem, de hát láttunk már karón varjút. (én mondjuk nem, de hallottam már olyanról, aki látott már olyat, aki találkozott olyannal...)

Ave, Saabi.

A biteknek tényleg csak két értéke lehet (ehe, pedig nem is :) ), de a számítógépes rendszernek azért több lehetséges állapota is van, amit pl. ki lehet fejezni azzal, hogy skálázódási képesség. Igen, lehet úgy is tervezni, hogy standard felhasználásra méretezel, de növekvő igények esetén (főleg ha tudod hogy mikor jön a csúcs, mint pl. a felvi.hu esetében), ideiglenesen bérelt kiegészítő szerver-kapacitással ki tudod szolgálni a kéréseket. Sokan ezt cloudnak hívják, mert szeretik a buzzword-öket, mások meg józan előrelátásnak. Persze ha lemondasz az utóbbiról, akkor nincs miről beszélni :)

Csúcsra méretezed a felhődet és csúcson kívül kikapcsolod a nem használt node-okat? És ez nem erőforráspazarlás? Megveszed a gépet, évente bekapcsolod egy-két alkalommal majd három év múlva lecseréled egy újabbra. Ezalatt működött vagy egy hónapnyit összesen.

Ave, Saabi.

A felhőnek pont az a lényege, hogy valaki menedzseli a felhőt, mindig annyi vasat tol alá, amennyi kell. A felhő erőforrásaiból meg annyit használsz/fizetsz, amennyi neked kell. Ha több kell, akkor többet, ha kevesebb, akkor kevesebbet.

Ha összeveted a felhő fölös erőforrásait a mindenki saját negyedig kihasznált szerver-ezreivel, akkor hogy is jövünk ki jobban?

Persze, ha te azt élvezed, hogy a LAMP-od 16G rammal, 6T vinyóval és 8 procival nyomul, akkor minek írogatsz ide?

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Semmi. Tök jók! Tényleg! Bár véleményem szerint nagyobb jelentőséget tulajdonítanak ezeknek a technológiáknak mint amit megérnek, igazából tényleg hülyeség hadakozni ellenük. Majd az idő megoldja. Addig is megyek VMware trainingre, hátha nálam is sikeres lesz az agymosás. Mondjuk a korábbiaknál elég rövid ideig hatott.

Ave, Saabi.

Mondok nektek ervet: szemelyes adat.

A cloud jo megoldas lenne, ha nem 3rd partyhoz kerulne ki az adat. Namost a magyar allam nem igazan engedheti meg maganak, hogy kiadja az Amazon corp-hoz az adatokat, valahova, ami nem az orszag teruleten van.

Annak tokre latnam ertelmet, hogy csinalunk valamilyen extra eroforrasos rendszert, ami februar 15-en a felvi.hu-e, majusban az apehe, januarban a mittomisenkie, ha meg senkinek nem kell, egyetemi kutatoprojektek mennek rajt, tudomisen.

A para az, hogy a valtasok kozt masszivan wipe-olni kene a vinyokat, mert egyik se kezelheti a masik adatait, eleg szigoruak az adatvedelmi torvenyeink, es joggal azok.

Ezt a problemat kellene megoldani, meg felepiteni ra egy megfelelo clustert valamilyen technologiaval, es akkor lehetne itt cloudolni.

Végre, valaki érvel.

A magyar államnak meg nem kell EC2-ben dolgoznia, elég lenne egy infrastruktúrát felépítenie, amiben ezek futnak. Az adatok védelméről meg annyit, hogy az apehes rendszergazdik ugyanugy lemasolhatnak egy-ket filet, ha akarnak, nem? megis megbizunk bennuk.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Nyilvan az apehes rendszergazda olyan munkaszerzodest ir ala, ami konzekvenciakat tartalmaz ilyesmire nezve, ill. nem tartom kizartnak, hogy az apehes rendszergazdat egy fel titkosszolgalat figyeli akkor is, amikor pisilni megy.

Persze valojaban nyilvan nem figyeli, es ott folynak ki az adatok ahol akarnak, de meg mindig biztonsagosabb, ha szem elott vannak azok, akik kifolyatjak, mintha ket indiai figura lenne Uj Delhi kulvarosaban, merthogy ott occso az aram az amazon/google/stb adatparknak.

Mindenesetre az allami infrastruktura felepitese nem intezheto el egy apt-get install hadoop -pal, egyreszt le kell egyeztetni egy csomo, lehetoleg eltero burst-ideju (burst - kiugro terheles) szervezettel, aztan ezek szeparaciojat meg kell hiteles modon oldani, es ami a legfontosabb, at kell irni az osszes szoftveruket olyanra, hogy ezt a cloudot kepes legyen hasznalni (ami nem trivialis es nem olcso).

Szoval ha gondolod, menj el jovo het szombaton a Meetupra, mondd el ezt a Mazsa Peternek, bar szerintem igy kormanyvaltas elott szegeny elegge bena kacsa, de szinte biztosan tudja, kit kell allambacsinal megkerdezni errol, vagy elmondja, ez egyaltalan lehetseges-e.

Jah, +1, végre érvek. És akkor itt az ellenérvek:

Az Amazonon adattárolásra:
- EC2-n tartjuk a Subversion repository-nkat és az issue trackert. Titkosított fájlrendszer felett, a gép bekapcsolásakor, mount időben írjuk be a jelszót
- SimpleDB és S3-ra szintén tárolhatod titkosítva az adatot (és a kritikus keresésekhez nem bonyolult külön indexelést implementálni)

Úgy általában meg simán üzemeltethetne az állam vmelyik pénznyelő intézménye egy Amazon-szerű cloudot, ahonnan a felvi, meg a többi bármilyen szolgáltatás előre és közben is allokálhat gépidőt...

Oke, de ha egy torveny azt irja elo, hogy fizikai elkulonites, ami ha meggondolod, nem hulyeseg, akkor nem eleg a titkositott FS. A forraskod es a szemelyes adat kozul pedig utobbit tartjak fontosabbnak a torvenyalkotok, amirol lehet vitazni, de maganemberkent te se erzed talan alaptalannak :)

Meg a masik, hogy ettol meg at kell irni a cuccot valami cloud-kompatibilisre, es mindketten tudjuk, ez nem 2 perc.

Nekem nagyon ugy remlik, a Webtown dolgozott a felvi.hu -n evekkel ezelott, gondolom ismeros a nev (a schonherzes gyujtokft-k kozul az egyik), ha most is egy rakat egyetemista irja, akkor azert nehez lesz felhositeni a rendszert.

A forráskódot azért hoztam fel, hogy lehet titkosítva is tárolni kritikus dolgokat (még akkor is, ha a kritikust másképpen értelmezzük különböző kontextusban). A törvénnyel kapcsolatban nem akarok vitatkozni, a magyar jogalkotás le van maradva 10 évvel a technológiai témákban, és mindig amikor valaki törvényre hivatkozik, nekem csak az a mondás jut eszembe, hogy a törvényt mindig meg lehet változtatni (függetlenül attól, hogy a fizikai szeparációt alapvetően jónak gondolom, de nem minden esetben kell görcsösen ragaszkodni egy szabályhoz...)

Az átírás / fejlesztés / olcsó-egyetemista-fejleszt témakörhöz nem kívánok mit hozzátenni, az átlagos fejlesztő és a kiemelkedő fejlesztő között több nagyságrendi teljesítménybeli és anyagi különbség van, stratégia kérdése, hogy ki mit választ...

Nem magyarázni akarok, hanem kíváncsi vagyok milyen terheléseket kaphat az APEH oldala? A linkelt post írója biztos tudja ha példaként hozta, én pedig kíváncsi vagyok, egy jól ismert, általam is használt portál esetében a terhelési profiloknak milyen kapcsolata van a cloud computing-el, azért kérdeztem. Nem ismerem a cloudot, eddig inkább csak egy elegáns buzzwordnek tűnik a valamennyire standard módon, könnyen, óccón hozzáférhető szuper-számítóközponti kapacitásokra, de érdekelne egy "make (saját infrastuktúra) or buy (cloud igénybevétel)" döntési scenario, pl. terhelések alapján, előny, hátrány stb.

Az APEH portál alapvetően tájékoztató portál és letöltés centrikus, ezt jól lehet kezelni a kiszolgálási rétegekben megvalósítótt cache technológiákkal. Ránézésére nagyobb terheléseket a bevallási napok környékén szokott kapni, hiszen nyomtatánykitöltő programokat, illetve nyomtatványokat szoktak letölteni. Feltöltést és ehhez kapcsolódó műveleteket nem végeznek az APEH portálon keresztül.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Lehet bérelni hardvert, mivel előre lehet tudni, hogy mennyi terhelés érkezik és mikor (minden évben megismétlődik). Kell bérelni egy hónapra akkora gépparkot, ami elbírja a terhelést és a roham után lebontani a felesleges gépeket (nem tudom, hogy külön géptermük van-e, vagy egy szolgáltatónál vannak a gépeik, de akár a szolgáltató és adhat virtualizált gépeket ilyenkor). Sun technológia van a felvi.hu mögött tudtommal, abban van minden jó, session-replikáció, normális cluster háttér - ránézésre bármikor hozzá lehet csapni új node-ot a cluster-hez.

A másik probléma a tervezés lehet, egy ilyen 'jelentkezés leadása' nem egy összetett dolog kell legyen. Memóriában benn lehet tartani az összes intézmény összes adatát és az összes regisztrált felhasználót, és a tényleges jelentkezést bele kell tolni egy Queue-ba, amit majd a roham után ráérnek feldolgozni. Gyanítom, hogy bedolgozták a kéréseket adatbázisba real-time, és egyszerűen a db oldalon torlódtak fel a kérések...
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Ez pusztán attól függ, hogy mik vannak a session-ben replikálva és mennyire van jól megírva alatta az alkalmazás réteg... sok függ az alkalmazástól is, hogy mennyire lehet cluster-ben futtatni... én láttam már jó példákat WAS, GF és JBoss terén is. :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Bizony, bizony altalaban ezeknek a rendszereknek, nem a vas gyengesege a problemaja( hiszen szinte fillerekert lehet 64GB RAM 8core szervereket kapni), hanem eleve rosszul tervezettek. Altalaban nagyobb projecteknel a vas a kissebb koltseg, a fejlesztesi es licence koltsegekhez kepest. Egy 2-4 labas clusternek azert fel kell tudnia dolgoznia minimum 50-100 tranzakcio/sec-et, ha jol vannak szetbontva a dolgok szinkron es aszinkron feldolgozasra akkor ennek tobbszoroset is, ahogy bolcs _Franko_ kollegam megmondta.

Meglepődnél, mennyire el lehet bonyolítani egy egyszerűnek tűnő rendszert, és máris ott vagy a 200 adattáblánál...

Gond az, hogy sokszor olyan "hülyeségeket" is megkövetelnek egy-egy ilyen rendszernél, amiből a külső felhasználó semmit nem lát, de mégis muszáj.

----------------
Lvl86 Troll

Ezt én értem, de sok esetben meg lehet oldani, hogy az alapvetően szinkron műveletekként kivitelezett rendszert jelentős részben aszinkron műveletekre lehessen bontani, csak "hinni kell benne", hogy egy Q is lehet annyira perzisztens, mint egy adatbázis, és csak a folyamat elengethetetlen részét kell megtartani szinkron műveletként.

Egy ilyen felvételi jelentkezéses esetben nem kell gondoskodni arról, hogy feldolgozva adatbázisba kerüljön a jelentkezés, akárhány tábláról van szó, elég lenne egy Q, amibe bele kell dobni a megfelelő adatokat, ami jelen esetben nagyjából "időpont", "user", "iskola", "szak", stb, aztán utólag be lehet dolgozni a táblákba a felgyűlt adatokat... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Szabad helyek a jelentkezés során tudtommal nem számítanak, ez még nem a főiskola ;)

Az, hogy kit hova vesznek fel a megjelölt intézmények közül, az a jelentkezések lezárása után, tanulmányi átlag alapján kerül kiszámításra, ami azért se annyira egyszerű, mert intézményfüggő, hogy kinek mit számítanak be.

Igaz, ez legkorábban érettségi után számít.

----------------
Lvl86 Troll

A queue másfajta alkalmazás-logikát követel tőled, mint egy adatbázis. Nem azt kell megmondanod, hogy hány szabad hely van, hanem hogy a jelentkezés az még befér vagy sem a szabad helyekre. És egy queue-ba sokkal kisebb overhead sok szálon pakolgatni a dolgokat, amit néhány szál feldolgoz (és az adatbázisban így kevesebb lock alakul ki), mint ha a sok szál eleve bemászik az adatbázisba, aztán jöhetnek a lockok meg a várakozás. Ettől függetlenül lehet olyan lekérdezésed, hogy hány szabad hely van, és ki is lehet írni, de amikor a jelentkezést beadja az illető, akkor azt kell mondani, hogy a jelentkezés folyamatban, aztán ha feldolgozódott, akkor kell neki mondani eredményt...

Erre írta korábban egy másik topikban valaki, hogy ilyen alapon az ABS is fölösleges, hiszen azt is a fékezések 2%-ában használják ki.

Az ilyen rendszereknek EZ a FŐ feladatuk. A felvi.hu -n a jelentkezés, az ETR/Neptun-nál a kurzusfelvétel/vizsgajelentkezés.

Az, hogy a köztes időben fórum, meg infobázis, lényegtelen, nem ez volt a cél.

Az is egy másik dolog, hogy ügyesen is meg lehet oldani a nagy erőforráskülönbség-fedezéseket, meg bután is.

A felvi.hu-nak ez nem fő feladata. A weboldal már akkor is létezett és használták rettenetesen sokan, amikor még szó nem volt elektronikus jelentkezésről. Ez csak egy szolgáltatása. A NEPTUN/ETR hasonló. Az sok-sok dolgot kezel (ösztöndíjak, egyéb ki/befizetések, APEH-jelentés, stb.), ami hallgatói oldalról nem látszik, a kurzusfelvétel és egyéb hallgatói dolgok csak a szolgáltatások kis %-át teszik ki. Az megint más kérdés, hogy a tisztelt oktató használja-e a NEPTUN szolgáltatásait.

Jó, talán a felvi.hu-nak kezdetben nem ez volt, azonban az ETR/Neptun-nak igen. Ha erőforrásoldalról nézzük, hiába van ez utóbbiaknak 1000 és 1 szolgáltatása ( tudom én is jól, mert hallgatóként és oktatóként is használom az ETR-t) a FŐ szolgáltatás a kurzusfelvétel ( és vizsgajelentkezés, bár az sokkal elosztottabb ).
Márpedig ez a topic az erőforrásoldalról szól, nemdebár?

Oké, hogy évente egyszer kap ilyen terhelést. De akkor meg, mondják azt, hogy kérem, a rendszer elbír mondjuk 6000 felhasználót, kicsit lassacskán ugyan, de még stabilan. Akkor azt mondjuk, hogy számoljuk, hányan használják éppen. Amint belépett a hatezredik ember, a többit már nem engedjük be, hanem feltesszük egy várólistára, és közöljük vele, hogy várakozik az x-edik helyen. Aztán ha valaki kilép, a helyére engedjük azt, aki a lista elején van. Nem hinném, hogy ez technikailag olyan nehéz lenne.

Mert mit csinál így az átlag okos tizenéves (anyukája)? Aggódik, hogy jajj, nem tudjuk majd leadni, és idegbeteg módon nyomkodja a frissítés gombot, ami több ezer anyuka/tizenéves esetén simán felér egy DoS-al. Ráadásul teljesen haszontalan terhelést generálnak, és azt sem hagyják dolgozni, aki véletlenül már belépett.

Ugye tudod, hogy webalkalmazás szempontjából ez a "kilép" nehezen értelmezhető, és pláne fölösleges, ha a terhelés szempontjából oly mindegy, hogy "be van lépve" valaki, vagy "nem belépve" nyomogatja az f5-öt, hogy mikor léphet be. És mi van akkor, ha az általad vázolt megoldás (nem egészen triviális) implementálása azzal jár, hogy feleakkora terhelésnél eldől a http réteg, mint amúgy?

milyen http réteg kell egy egyszerű sorbaállító algoritmushoz? ha újratöltöd az oldalt, és az előtted várakozók száma nem csökken, hanem nő, hányszor fogsz f5-öt nyomni ameddig rájössz hogy magaddal szúrsz ki?

És persze nem kell ugyanazon a szűk keresztmetszeten keresztülverni ugyanezt a forgalmat (portálszerver is minek egy ilyennek...)

Persze a legjobb megoldás a BME Neptun ,,a szerverek száma a jelenlegi terhelés lekezelésére nem elégségesek'' szövege :)

szerk. a másik dolog, hogy a túlterhelés csökkenti az áteresztőképességet, ezért érdemes limitálni a felhasználók számát (és a rendszerben tölthető maximális időt!), mintsem beengedni boldog-boldogtalant.

nem kell a reverse proxyval szórakozni, aki már egyszer bejutott, azt kiszolgálod, aki pedig várakozik, azt kiviszed egy külön rendszerbe, hogy az ő bejutási próbálkozásaik ne a bentiek kárára menjenek. A legbutább dolog, ha végre be tudsz lépni egy túlterhelt rendszerbe, majd az első tranzakciónál kidob (mint például a Neptun teszi).

a rendszerben eltöltött maximális időt és az egyszerre bent levő emberek számát elég egyszerű eszköztárral is lehet szabályozni. A terhelést pedig nem feltétlenül kell online mérni, csúcsterhelésnél (arra a 2 napra) kell egy ember, aki nézi a munint meg az átlag válaszidőt és tologatja ezt a két beállítást.

nem értem, amit írsz.

"nem kell a reverse proxyval szórakozni, aki már egyszer bejutott, azt kiszolgálod"

- hogy szolgálod ki, ha nem reverse proxyzol? gondolom vannak frontend webserverek, és vannak backend szerverek. gondolom a backend szervernek nincs külső ipje. ha megszünteted a reverse proxy-t, akkor hogy éred el a backend-et?

- ha a frontend szolgálja ki az ssl-t és a statikus tartalmat, és tegyük fel, feloldod az elöbb említett problémát, akkor nem lesz ssl? és statik tartalom?

"aki pedig várakozik, azt kiviszed egy külön rendszerbe, hogy az ő bejutási próbálkozásaik ne a bentiek kárára menjenek."

- nem pejoratív értelemben kérdezem! csináltál már ilyet?
szerintem több lépcsős a request kiszolgálása, valszeg van frontend(ssl,statci data), backend1(weboldal megjelenítő réteg), backend2(ejelentkezés), ha nem vagy bent ejelben, alapból csak a frontend-et és a backend1-et terheled. az nem hat ki a bent lévőkre.

"A terhelést pedig nem feltétlenül kell online mérni, csúcsterhelésnél (arra a 2 napra) kell egy ember, aki nézi a munint meg az átlag válaszidőt és tologatja ezt a két beállítást."

- nem feltétlenül támaszkodnék a válaszidő dologra, alapból, melyik szerver válaszidejét nézed, ha pl van 5 node? a gond, hogy sokan csak azt látják, hogy www.felvi.hu, és ez egy honlap. ja... de imo a weboldalt kb 12+ szerver szolgálja ki (és még keveset mondtam).

- tegyük fel, meg tudod oldani a terhelés monitorozást, és észreveszed, hogy a global www.felvi.hu lassú, kiraksz egy túlterhelt static oldalt.
hogy kontrollálod, azokat, akiknek van sessionje, és tudják a linket az ejelhez? www.felvi.hu/felveteli/ejelentkezes asszem... beírod a böngészőbe, és szarod le, hogy a főoldal static. ha beálítod, hogy a www.felv.hu/$1 legyen static, akkor meg aki bent van, kibaszódik a static oldalra.

szóval... merengj még a dolgon.

2. Ennyi erővel minek 30 ezres focistadion, hisz csak évente ha tízszer van focimeccs, azon kívül csak áll magában, micsoda pazarlás. A neptunnak az a dolga, hogy tárgyfelvételkor és vizsgajelentekzéskor működjön, a stadionnak meg hogy meccsre megteljen. Nem igaz, hogy nincs egy egyetemen olyan számítási feladat, amivel ne lehetne kihasználni a szervert holtidőben is. Ha más nem adják bérbe a teljesítményt.

"2.) hardware:"
Mivel a kód mélyébe nem látok bele, így csak feltételezéds az egész, de ma már lehet ám szervert bérelni 2x4 órára! "clouding computing", persze erre lehet azt mondani, hogy ahhoz a rendszert fel kellene készíteni, viszont ez a tervezés fázisában is egyértelmű volt, hogy ilyesmi terhelésre kell számítani. summa summárum miért nem bérelnek szervert erre az időszakra, és miért nem tervezték skálázhatóra a rendszert.
________________
java'nother blog

a szerver bérlés nem oldotta volna meg a problémát, szerintem.
szerintem jó volt a hw.

Amit leírsz, az nem igaz a legtöbb állami/állami tulajdonú cégre.
Láttam már olyat is, hogy tervezés és a megvalósítás között 3 év telt el.
Ha ez az eset itt is, akkor imo fasza rendszert építettek, mert 3 éve kb 10-ed ennyi user akart ejelentkezni. :)

Bár nem használóm a felvi-t, de állítólag "6 éve van ez a probléma". Nem fikázni akarok senkit, egyszerűen előra kalkuilálható a probléma, mintahogy a legtöbb nagyvállalatnak, legalábbis japánban, a gazdasági válság előtt 2 évvel már megvolt az üzleti startégiájuk a szűkösebb időkre.
________________
java'nother blog

Valaki tény, hogy írta, hogy 6 éve van ez a probléma, de ez nem teljesen igaz. 1 évvel ezelőtt február 16-án volt az utolsó nap, akkor nem volt leállás. 2 évvel ezelőtt sem volt leállás, így kijelenthetjük, hogy valaki túlzott kicsit.

Szerintem a felvinél is felkészültek a tolásra. Mint a topicban már említettem 10-ig ment, lassan, de ment. Aztán jött a sok katasztrófatúrista az indexen megjelenő cikk miatt, és akkor borult meg a dolog :).

( chx | 2010. 02. 16., k – 08:20 )

Kicsit offtopic, de mi van ha valaki MSc képzésre jelentkezett volna de lecsúszott a határidőről?

_______________________
echo crash > /dev/kmem

( jkop | 2010. 02. 16., k – 10:09 )

Ez engem is kikészített két éve, meg most is, amikor a tesóm lépett volna be, és órákon keresztül kellett próbálgatnia hogy beengedje a kib*szott rendszer.
Én nem értem, elvileg 21. század második évtizede van, vagy mi a f*sz. Nem tűnik fel senkinek, hogy évek óta mindig ez van? És hogy talán ez így nem jó?

Szerintem azért érdemes lenne megnézni, hogy ez a "probléma" vajon hány embert érint VALÓJÁBAN! és vajon mekkora SÚLYÚ! gondot okoz.
Ha ezt megnéznénk akkor szerintem olyan jelentéktelen számú felhasználót érint és azoknak se okoz különösebben fontos problémát (nem származik belőle hátránya, elmaradt bevétele. stb..), hogy nem igazán érdemes ezzel foglalkozni.

Csatlakozom. Másrészt nem ez lesz az utolsó anomália a felsőoktatásban eltöltött éveid alatt. Hullani fog a hajad a TO hozzáállását látva, valamint a tanerő lekezellő, megalázó megnyilvánulásai miatt. De ennél durvább is tud lenni. Amikor futkoshatsz jegybeírás miatt épp más földrészen tartózkodó tanárt hajkurászva estébé. Szóval a felsőoktatás nagyrészt arról szól, hogy szpj minél többet, mert egy alsóbbrendű létforma vagy.
Engem az e-felvételi dobott ki egyik percről a másikra úgy, hogy aznap már vissza se tudtam kapaszkodni. Ez van. Hozzá kell szokni.
--
unix -- több, mint kód. filozófia.
Life is feudal

Szóval a felsőoktatás nagyrészt arról szól, hogy szpj minél többet, mert egy alsóbbrendű létforma vagy.

Ez így van. Ez egyfajta szelekció, aki nem bírja átvészelni ezt a részét a felsőoktatásnak, annak tökéletesen fölösleges elvégeznie bármilyen egyetemet/főiskolát, úgyse tud majd mit kezdeni a papírral.

:-)

Csaba

Lfszt szelekció! Egyszerűen megteheti és amelyik paraszt, az meg is teszi. Ennyi. Nem kell megideológizálni. Nincs mögötte koncepció. A szelekcióra ott vannak a "fölösleges és ostoba" tantárgyak. Arról nem beszélve, hogy a felsőoktatásból kikerülők felkészültségének minőségét nem határozza meg ez a fajta hozzáállás. Semennyire se lesz jobb szakember az, akit szopatnak.
--
unix -- több, mint kód. filozófia.
Life is feudal

Most az egesz szalra fogok reagalni:
Igazabol mar ket eve felsooktatasban vagyok es ismerem rendszert, nem kell nekem papolni. Es oszinten szolva egy-egy targyfelvetel durvabb szokott lenni mint ez a felvis gubanc :)
Mas reszrol viszont leszarom, hogy mindig ez van-e, vagy nem. Soha nem kene ilyennek elofordulni, mert enyhen szolva is ciki, hogy ebbol immaron hagyomany lett, hogy felvis, felsooktatasos es ugyfelkapus rendszerben erre kell szamitani. Az igenytelenseg egyik formaja ez, es az is, ha valaki szerint ez igy rendben van. Hat nincs rendben, rohadtul nincs.
Marmint most a lehalt szerverekrol beszelek.

( Madman | 2010. 02. 16., k – 11:16 )

nem azert mert nem lehet "optimalizalni" de tedd fel magadnak a kerdest hogy milyen eroforrasokat akarsz allando jelleggel valami ala rakni olyasminek aminel a terheles 99.99% ban alacsony es mikor itt az utolso nap utolso oraja es az osszes trehany lustanak aki keptelen volt eddig jelentkezni hirtelen nagyon fontos lesz es a terheles az alapszint 100szorosara ugrik az ido 0.01%-ara ... (hasonlo a helyzet a tanulmanyi rendszerekkel ... - en valahogy mindig tudtam jelentkezni pedig akkor meg megszarabb volt mint allitolag most ... )

( vl v | 2010. 02. 16., k – 11:30 )

Technikailag megoldhatatlan, hogy akkor is elérhető legyen amikor a megszokotnál többen látogatják (pl. jelentkezés leadása, ponthatárok kihirdetése stb.)?

Igen. Lehet 10-szer akkora vasat venni, ami az év 364 másik napján üresen kong, de azt Te meg én fizetjük ki az adóforintjainkból. Én speciel nem szeretnék még többet fizetni.

Nem látom be, hogy ha minden évben ez megy, lehet előre tudni, hogy gáz a határidő napján jelentkezni, van >1 hónap a jelentkezésre, akkor mi a f.szért kell mindenkinek az utolsó napra hagynia a jelentkezést...

A tegnapi hiradások arról szóltak, hogy hw hiba miatt a korábban jelentkezettek adatai is elvesztek. Nem kizárt, hogy hw-t azóta sem sikerült szerezni, mert gondolom a hw szállítójának - jó sun szokás szerint - az amszterdami raktárból kell berendelni az utolsó alkatrészt is. Support szempontjából a Sun a legrosszabb, gyakorlatilag nem lehet ma Magyarországon órákon belűl Sun alkatrészhez jutni, egy beépítő keretre is akár egy hetet kell várni. Ezért kell HP vagy IBM szervert venni.

mert gondolom a hw szállítójának - jó sun szokás szerint - az amszterdami raktárból kell berendelni az utolsó alkatrészt is

Te félrebeszélsz...

Hw hiba esetén a support adja a cuccot, és nekik nem Amsterdamban van a raktáruk. Mellesleg amilyen cuccokról itt beszélhetnénk, azokhoz akár a demogépekből is lehetne adni alkatrészt, annyira hétköznapi dolgok.

gyakorlatilag nem lehet ma Magyarországon órákon belűl Sun alkatrészhez jutni,

Tudsz valamit, amit én nem? Megveszed az eszközt, kötsz rá support szerződést, és ha valami tönkremegy, órákon belül kaphatsz alkatrészt.
Nem kötsz rá support szerződést, nem kapsz lóf.szt se.

egy beépítő keretre is akár egy hetet kell várni

Support? Eltörted? Vagy magától tört el? Mert ugye az a support, hogy ha tönkremegy rendeltetésszerű használat közben.

Ha újat akarsz venni, az nem support.

Ezért kell HP vagy IBM szervert venni.

Nem mondod? :)

"egy beépítő keretre is akár egy hetet kell várni"
" Eltörted? Vagy magától tört el? "

Nem, elfelejtették a géphez csomagolni. Tudom ez sem support, de akkor is. Vártunk 10 napot a rendelésre, azután megint várunk 10 napot a beépítő keretekre. Mióta IBM-et rendelünk minden rendben megy. Lehet itt kardoskodni a Sun funoknak, de amit Én láttam a Sunból, az arról szól miként lehet kiszolgáltatott helyzetbe hozni az ügyfelet, hogy sírva fizesse ki a sokadik Sun adót is.
Sun jött, élt pár évet, most meg lásd mi lett belőle...

Pont ezt az undorító nagypofájú, beszólogatok az vevőnek tipusú, übersznob; "hu de nagyon fasza gyerek vagyok, mert Sun logo van a hasamra vasalva" tipusú cégek azok amitől elment a kedvünk a Sun gépek beszerzésétől.

"Azt gondolom, hogy akinek 2x10 nap sok, az nem a Suntól akar rendelni, csak legfeljebb még nem tudja ezt."
Ahoz képest hogy addig rá sem mozdultok a rendelésre, amíg a millás számla az utolsó forintig ki nincs fizetve, és mi a már kifizetett árúra várunk +20 munkanapot, hát az igen sok. Főleg ha addig ki sem tudjuk vinni a projectbe a gépet, áll benne a pénz, és állunk mi is, mert a határidőt képtelen tartani a sun partner.
A sun partnerek egy forintot nem tartanak benne az árúban, még a kiszállításhoz sincs közük; nekik csupán csak a support a feladatuk, amihez alapból fingjuk sincs sokuknak.

Mi két alkalommal rendeltunk Sun vasat, minden alkalommal gondok voltak vele. Volt amikor beépítő keretet nem kaptunk, volt amikor memóriát nem kaptunk bele. 2-ből 2 nekem nem 0,1% false pass ! És a legszomorúbb hogy a sun partner, már csak becsületből nem tud 1-2 órán belűl előállni 1 tartalék alkartésszel, már csak becsületből.

Magyarország kis ország, mindenki ismer mindenkit. Ha az egyik szól a másiknak, hogy egy partnernek fizetési problémái vannak, akkor ott előre fog fizetni.

Magyarország kis ország, mindenki ismer mindenkit, és biztosíthatlak, hogy a Sun szállítási idejei jók. A nagyobb volumennel rendelkező gyártóknál bizonyos dolgokra igaz, hogy raktárról hozzáférhetők, de ez csak egy olyan kisebb kategóriára igaz, ami a Sun-nál lassan már nincs is. Bármi, amit e fölött kérsz, az igencsak rendelős máshol is és ez így normális és elfogadott az iparban.

A problémáidat sajnálom, egyébként vagy elhiszed, hogy becsületből kaptad meg egy hét alatt a 6 db air management sled-et, négy hét helyett, vagy nem, ami egyébként nem alkatrész, hanem inkább, mint a gumiszőnyeg az autóban, de tény, hogy kimaradt.

Valakivel összekeversz. Nagyon sajnálatos amit írsz, de én gyakorlatilag a vinyókat nem kaptam meg a X2270-hez, ami nem csak egy "gumiszőnyeg az autóhoz". Gyakorlatilag valaki elfelejtette megrendelni...

De azt hiszem nem is ez a lényeg, mi mindíg előre fizettünk minden stuffért. Egyébként tőletek nem vásároltam soha, valamikor 3 éve próbáltam rendelni, de akkor az nem jött össze azóta az Synergonnal vagyok kapcsolatban.

Amúgy a sunnál már nagyon sok minden nincs, ami a konkurenciánál HP, Dell vagy IBM van.

Amúgy mutass egy olyan sun viszonteladót ma idehaza, aki minimálisan ért is ahoz amit árúl, és nem csak kereskedik vele!?

Nem hinném, hogy standard eljárás lenne az előrefizetés. (Voltam én Synergon alkalmazott, akkor nem volt standard.)

De szerintem a disztribútor tud mondani olyan partnert, akinél nem így megy a játék, tekintve hogy sem a disztribútor nem fizet a Sunnak előre, sem pedig a partnerek a disztribútornak. Legalábbis az én tudomásom szerint. Aki meg direkt partner (nem tudom, hogy most éppen van-e ilyen, talán a t-csoporti státusza miatt a KFKI/Icon ilyen), az biztosan nem fizet előre a Sunnak. Ja, és ugye volt még a try&buy konstrukció is, aminél nemhogy előre nem fizetett a kuncsaft, hanem a leszállítás után 90 nap volt a határidő (amiből 60 napja volt arra, hogy meggondolja magát).

Az emberi hiba a rendszerben benne van, mivel emberek üzemeltetik. Nem hiszem el, hogy más cégeknél másképp lenne - főleg, mert a legnagyobb Sun partnerek - including Syn - egyúttal HP és IBM partner is.

Abszolút jogos az a kritika, hogy a partnercégek úgy általában nagyon gyatra színvonalon űzik az ipart. De ez alapvetően nem a Sun bűne.
Én pl. anno azért jöttem el a Syn-tól, mert azt, amivel foglalkoztam ott, egyre kevésbé csinálta a cég. Mondjuk úgy, hogy nem jöttek a projektek, én meg kezdtem unatkozni. És biztosan nem a piac halt ki a cég alól, mivel a következő munkahelyem ugyanarról a piacról tudta hozni a projekteket.

( fraque | 2010. 02. 16., k – 11:42 )

volt szerencsem elso kezbol a tegnap esti mizeriahoz.

nem ugy tunt, hogy az intezmeny-kar-szak kombot akarmi is cache-elte (szovicc, hehe) volna, folyamatosan 502-k meg 504-ek jottek ra, ami talan szuboptimalis, mivel tok statikus tartalom es szerintem a keresek nagy resze is erre ment el.

nekem 3-szor vagy negyszer jott a statikus karbantartas oldal, tartok tole, hogy Gati nem mond igazat, amikor azt allitja, nem borultak ossze. a backendeket is eleg sokszor mokolhattak, mert aranylag sokat kaptam a menu helyett "nem elerheto" szoveget.

aztan - nekem - 23:50-kor magikusan megjavult, vagy sokan adtak fel, vagy csinaltak rajta valamit.

szívesen tisztába raknám a dolgokat, de ...
23:50-kor kb mindenki ment aludni.

magához az egészhez meg, 22:00-ig lassan de ment a felvi, mindenki boldog volt, cirka x ezer user vígan kattintott és várt x másodpercet míg bejött az oldal, de bejött.. timeout nélkül.

majd a vicces kedvű sajtó, gondolta megírja aznap, 22:08-kor, hogy lassú az ejelentkezés, erre jött az összes bumburnyák (tisztelet a kivételnek), és ráfeküdtek az f5-re.

Olvastam ugyanitt, hogy 22:10-kor volt a felvi down... érdekes, nem?
22:08 lassú, rá 2 percre meg down. funny...

ja és az irónia az egészben, hogy ezt ma reggel találtam :D
http://allas.monster.hu/UNIX-rendszerm%C3%A9rn%C3%B6k-allas-Budapest-Ma…
véletlen? hmpf...

( balintdavid | 2010. 02. 16., k – 12:11 )

Jó kérdés.
Mondjuk az is jó kérdés, hogy a több hónapos felvételi időszakban miért utolsó napon kell leadni a jelentkezést.

Mondjuk az is vicces felvi.hu-ban, hogy Iceweasel 3.0-val csak úgy működött, ha UASwitcherben-ben átnyomtam Firefox 3-ra.
----------------------------
PRESS PLAY ON TAPE

En nem hagytam utolso napra, de mar vagy ket hete is vacakolt, nem engedett be, utana karbantartas volt stb. A masik, hogy Firefox alatt el van csuszva az egesz menuje, vizszintesen kell hozza gorgetni..
Amugy en ezert valasztom inkabb a hitelesito lapos megoldast az ugyfelkapus helyett, igy legalabb kinyomtatva is elkuldom a fontosabb adatokat (bar ez lehet, hogy ilyen esetekben nem szamitana,de hatha megis).

( tombenko v | 2010. 02. 16., k – 13:52 )

Vasárnap eszembe jutott, miért is ne mehetnék még egy szakra. Hétfő délután a hajamat téptem. :) 23:58-kor sikerült lezárni, örültem, mint majom a farkának, utána jött az SMS, hogy meghosszabbították...
Nem baj, még nem hagyom abba a tanulást. :)
--
Fight / For The Freedom / Fighting With Steel

( egeresz | 2010. 02. 16., k – 16:08 )

alapvetoen egy kapcsolat (feedback) hianyzik a rendszerbol.

Egy jo szervezetben a fejlesztes - teszteles - uzemeltetes - ismet elorol eletciklusban adataramlas tortenik, hivjuk mondjuk szabalyzasnak. Bizonyos helyzetekben a tapasztalatok ciklikus aramlasa elmarad, es valami vegpontta valik (pl az uzemeltetes) egyszeruen nem jut vissza adat az uzemeltetesbol. Ezt hivjuk mondjuk vezerlesnek.
Szoval vezerelt helyeken ilyen elofordul, akar tovabb is, nem csak 6 evig.

ja igen, szerintem is gaz.

( sany | 2010. 02. 16., k – 19:47 )

"nem igazán érdemes ezzel foglalkozni."

Ja, a minisztériumban is így gondolják! :)

De gondolj bele, ha neked a baleseti sebészet ügyeletén ezt mondják! :D

Mint szólnál rá?

( uid_4263 v | 2010. 02. 16., k – 22:34 )

Valószínűleg szoftver oldali kínja lehet a dolognak, 6 év alatt valszeg többször is kapott új hardvert ez a kulcsfontosságú szolgáltatás, harmadik alapvető tényező meg nincs.

Minden kvázi állami megrendelésre készülő szoftverből kifelejtik úgy tűnik a kritikus teszteket.

********************
"Aki nem backupol az tehetsegtelen :-)"
"...ha nem tévedek!" (Sam Hawkins)
http://holo-media.hu

( maszili | 2010. 02. 16., k – 23:22 )

Az esti híradóban azt mondta az illetékes elvtárs, hogy - A draútnak két vége van. A szerverek jók a kliensekkel van a baj! :D

--
maszili

( nikin v | 2010. 02. 17., sze – 03:08 )

Szerintetek azt legalább remélhetem, hogy:

- A képek,css-ek külön erre a célra beállított static content szerveren vannak?
67kb / a 81kb-os kezdőlapból
- Az adatbázis külön vason van.
- Ahogy nézegettem az oldal mindent tömörít. Ez vajon nagy terhelésnél előnyös-e?
(Ez amúgyis érdekel).

Másik dolog:

találtam ilyet:
http://www.educatio.hu/images/download/vizsgalati_jegyzokonyv_2008_06_1…

gondolom az itt leírt dolgok nagyobbrészt a mostani problémára is igazak.
sajnos a stat.felvi.hu ahogy nézem nem publikus (lehet én vagyok hülye)
mindenesetre az Alexa szerint Jan özepéhez képest megduplázódott a forgalom mostanra. (de gondolom a pillanatnyi terhelés növekedés ennél jóval több)

-- TROLL ON --
mit keres egy pdf az images mappában?
-- TROLL OFF --

Én is azok közé tertozom, akik szerint egy nagy kormányzati szerverpark nem lenne éppen hátrányos. Mivel tényleg elosztható lenne a terhelés... hogy milyen technológiával, azt a nálam profibbakra bíznám.

### ()__))____________)~~~ ################
#"Ha én veletek, ki ellenetek?"#1000H/UbuFb

- A képek,css-ek külön erre a célra beállított static content szerveren vannak?
67kb / a 81kb-os kezdőlapból
- Az adatbázis külön vason van.
- Ahogy nézegettem az oldal mindent tömörít. Ez vajon nagy terhelésnél előnyös-e?
(Ez amúgyis érdekel).

- szerintem igen
- szerintem igen
- nem, de nem ez volt a para, szerintem

( Ewkins | 2010. 02. 17., sze – 13:01 )

Vajon sikerül hugomnak február 23-ig hitelesítenie a jelentkezését vagy egy életre megtanulja a nyavalyás, hogy nem hagyunk az utolsó előtti percre mindent? :-D

Ez a rendszer tényleg életre nevel, és hatásosan teszi.

Bónusz, hogy ügyfélkapu regisztráció véglegesítésre foglalt időpontot interneten (kedd 15:45), mikor az okmányirodába ment meg minden zárva volt, és kérdezték tőle, hogy mi a f*szt keres ott, mikor 12-kor zártak, húzzon el, az anyjával szórakozzon.
Aztán nagy nehezen 2 kulcsra zárt ajtóval beljebb sikerült az egyik ott dolgozót 45 másodperc munkára rábírni és véglegesíteni.

Azt persze még nem tudja, hogyha a Felvi működni fog még mindig ott lesz az ügyfélkapus rendszer, mint végső akadály.

Bónusz, hogy ügyfélkapu regisztráció véglegesítésre foglalt időpontot interneten (kedd 15:45), mikor az okmányirodába ment meg minden zárva volt, és kérdezték tőle, hogy mi a f*szt keres ott, mikor 12-kor zártak, húzzon el, az anyjával szórakozzon.
Aztán nagy nehezen 2 kulcsra zárt ajtóval beljebb sikerült az egyik ott dolgozót 45 másodperc munkára rábírni és véglegesíteni.

Helyesebben: balkani eletre nevel... :(

Apósomék Montenegróban nyaraltak tavaly. Az pedig Balkánnak mondható. Messze korrektebb magatartást tapasztaltak az ottaniaktól, mint itthon. Ebből én úgy vélem, hogy csak szeretnénk Balkán lenni, de ahhoz sokat kell még tanulnunk.
--
unix -- több, mint kód. filozófia.
Life is feudal

Ez van, a hivatalnokok, eladók, ügyfélszolgálatosok itthon túlterheltek, utálják a munkájukat és alulfizetettek (emiatt ingerültek, stresszesek, boldogtalanok).

Nyugat-Európában és Amerikában keveset dolgoznak sok fizetésért (boldogabbak az emberek)
Kínában nagyon sokat dolgoznak nagyon kevés fizetésért (boldogabbak az emberek)
Japánban és Dél-Koreában sokat dolgoznak sok fizetésért (boldogabbak az emberek)

Magyarországon keveset dolgoznak (a nyugat-európaiaknál azért többet) kevés fizetésért és nem boldogok az emberek. Ez egy ilyen gyökerét vesztett (szovjet megszállás alatt megnyomorított) búvalbaszott kultúra, nyomokban társadalomra emlékeztető struktúrát alkotó privatizációs-haverkapitalista utcánmásikatlesős panelproli (minek konyha ha van konzerv, és Magi fix) nyugdíjasfalva :-D (a gond a fejekben van)

( rolikhan | 2010. 02. 18., cs – 14:38 )

Ez is kb olyan, mint az ügyfélkapu volt. Elkezdték igazán használni és egyből bedobta a törcsit. Aztán belenyomnak ide is pár misit a közösből.