IWIW érdekeség :-)

Fun

Sziasztok!

Az imént próbáltam bejelentkezni. És kezdőoldal helyett ez fogadott:

XML-feldolgozási hiba: nem jól formázott
Hely: http://wiw.hu/pages/main/index.jsp
160. sor, 147. oszlop:

A szesz hatalmas Istene gyújtson világosságot elborult, torz agyunkban és az alkohol fényeskedjék tévútra futott alantas életünk sötétl ösvényén!

------------------------------------------------------------------------------------------------------------------------------------------------------^

Akkor most fölnyomták a wiwet vagy mi az izé van ... :)

  • 19827 megtekintés

( freebush | 2007. 03. 04., v – 21:00 )

Nemtom, ha igen, akkor már nem, mert most jó.

( kissipos | 2007. 03. 04., v – 21:10 )

Mi lenne?! Semmi. Ez egy szokásos jelenség Opera böngészővel. Vagy frissíted a lapot és akkor már jól jelenik meg, vagy ott van egy sor, hogy "lap megjelenítése html-ként" és arra klikk és akkor már jól jelenik meg. Hogy a "hibát" mi okozza, azt ne kérdezd, de gondolom trágya kódolás lehet az oka.

__________________________________________________________________________

"Ennek a fiúnak semmilyen kollektív jelentősége sincsen: éppen hogy egyén."

( trendkill | 2007. 03. 04., v – 21:16 )

én firefox-al szoktam nézni, 10-ből egyszer ez fogad...

( uid_4672 | 2007. 03. 04., v – 21:47 )

iwiw sux. egy ilyen szolgáltatás elvileg nem erőforrásigényes, de ezeknek mégis sikerült úgy összehozni, hogy technikailag a lehető legxarabb megoldást találják: hogy lehet egy ilyet JSP-ben írni?? Mi olyan erőforrásigényes ebben az iwiw-ben? Pár mysql query-t kiadni?

Amúgy tudok egy olyan emberkét, akinek az adatlapját NEM LEHET MEGNÉZNI, mert MINDIG xml errort ad.

1. az iwiw egy olyan szolgáltatás, amit NAGYON szét lehet osztani több szerver között

2.
"Amúgy én nem nevezném pár querynek, mert a nemtomhánymillio userből néhányszáz biztosan fennvan, és egy oldal generálásához is több query kell..."

másfél millió felhasználója van AFAIK.

pár száz query-t/sec nem tudnak kiszolgálni? Akkor mi a francért fizetett érte a t-online 1 milliárd forintot? Azt mondtam, hogy mi a francért kell egy ilyet JSP-ben írni, amikor a JAVA és a teljesítmény az két különböző fogalom. A JAVA nagyon szép az egyetemen oktatni az objektumorientált programozást, de a gyakorlatban egyenlő a 0-val. Lásd iwiw.

Na most ahogy elnézem neked sincs. A java lehet, hogy erőforrás igényes és nem való mondjuk 50 felhasználós rendszerek kiszolgálására. De a technológiában rejlő hatalmas lehetőségek miatt enterprise szinten nincs vetélytársa, lásd bármilyen queue management (JMS/JNDI).
Viszont ha valaki nagyon szarul ír meg benne valamit, akkor halálos lesz. Van itt nálunk is egy portál programozó jps/postgresql/kétprocesszoros/4GigaRAM gép, aki a 4000 (!) rekordos adattábla keresésével ki tudja feketetni az előbbi kombót. És hát ezért ez valami. És a postgresql védelmében, a srác az oracle-t is simán kifekteti.
Én nem akarom védeni a java-t, de egy jó programozó kezében és egy erős vason csodákra képes.

Láttam én Oracle-Bea Weblogic-Megajóégtudjami felállásban megpusztulni (overload miatt) adatbázist... Ha a jdbc-n keresztül érkezett az ominózus select, akkor beragadt, és felzabált mindent, ha TOAD-ból nyomtam be, akkor meg szépen visszaadta a nagy büdös semmit (hozzáteszem, helyesen!)

Ertelmes hasznalat eseten a Java, .NET papirforma szerint veri sebessegben az interpretalt nyelveket (PHP, Perl), weben is. Memoriahasznalatban persze 2-3-as szorzo :).

Itt valoszinuleg nem a JSP reszevel van a problema, hanem a hulye adatbazisszerkezettel.
Nem olyan regen probaltam ki, hogy a GeoIP adatbazist importaltam MySQL-be. IP szerint probaltam lekerdezni, hogy az epp melyik tartomanyban van, es milyen orszaghoz tartozik. Kb 80k sorbol allt a tabla, siman vitte a gepem, bar alig van benne memoria (nem erre nereteztem anno).
Kiprobaltam ugy is, hogy szetdobtam 3 tablaba (orszagkod-orszagnev hozzarendeles, ip-ip numerikus erteke, meg egy osszekapcsolas az eddigi adattal). Ez a szerkezet a valtozasokat jobban birja (nem mintha gyorsan valtoznanak :) ), de a lekerdezes lassabb. Sikerult vele kelloen lelassitani :). (Egyik esetben sem volt indexelve, ugy joval gyorsabb lett volna.)

Egy kapcsolati halot (ami az iwiwnel van) rengeteg modon lehet abrazolni. Ha jol talaljak el, akkor gyors lesz. Ha rosszul, akkor lassu, vastol fuggetlenul.
---------------------
Time is like a drug. Too much of it kills you. - Pratchett

Én meggondolnám hogy egy iwiw szerű rendszer alá adatbázis kezelőt tennék -e, vagy simán csak egy fájlrendszert használnék -e hozzá.

Azért mert:
- sebesség és a teljesítmény a kritikus szempontok dominálnak,
- nem lehetnek (optimális tervezésnél) annyira öszetett adatszerkezetek amiket ne lehetne egyszerűen text fájlokban tárolni és onnan lekérdezgetni.

Nem gondolom hogy az iwiw-et lényegesen fejleszteni fogják, max még több reklámot fognak beletenni...

Hozzászólásod alapján nem igazán van tapasztalatod adatbázis használatban, és nyilván nincs is rálátásod arra hogy mit lehet csinálni egy jólmegtervezett adatbázisal. Jó lenne ha kicsit bővebben és értelmesebben írnád le a véleményed, és nem csak poénkodnál!

Az adatbázis kezelők (Oracle, SQL server stb...) az üzleti és egyéb olyan szférában mutatják meg elsősorban erejüket, ahol komplex adatstruktúrákból kell nagymennyiségű bonyolult számításokat, és öszetett lekérdezéseket végezni, hatékonyan, gyorsan és flexibilisen.

A sima web-re használt adatbázis motorok pl. MySQL és társai csak nagyon nagy jóindulattal foghatók fel adatbázis kezelőnek, és mint már írtam is sok esetben az SQL 92 szabvány parancsait sem valósították meg bennük. (Pedig azóta már az SQL 99 is beporosodott) Ezeket inkább adat tárolóknak lehet nevezni, hiszen beteszek egy adatot és kiveszek egy adatot-on kívűl sok minden másra nem nagyon alkalmasak.

Nyilván most emocionális alapon most nagyon fel leszel háborodva a "MySQL ellenes" mondatokon. Javaslom Oracle Hungary és a Simonyi szakkollégium kéthetenként ingyenes szemináriumának a látogatását. A következő alkalom 2007. március 13. - témája: Oracle adatbázis architektúra.

Vonja le, de rögtön... Nekem nem egy, nagyon jó informatikus (azzá lett) cimborám végzett a bányamérnökin. Ha netán véletlenül valakik részegségük, vagy félrevezetettségük okán balekká kereszteltek, s később firmává lettél, akkor egy sörpárbaj vár a kijelentésed miatt rád.

Mutasd meg legyél szíves!

Minimálisan három féle adatmodellben gondolkozok amikor az iwiw féle adatbázist próbálom átgondolni: Hierarchikus, Hálós, Relációs adatmodell. A félreértések elkerülése végett: lehet számtalan féle adatmodellt leszármaztatni vagy kitalálni, de ezek a leginkább elterjedtek.

A hierarchikus adatmodell leginkább egy fastruktúrához hasonlítanám, amit gráffal adok meg. Az egyedeket csomópontok, míg az egyedek közti kapcsolatokat az élek jelzik. Csak azokat az egyedeket kötjük össze élekkel, amelyek között valamilyen kapcsolat van. (Ezt a típusú gráfot fának nevezzük, ugyanis egy gyökércsomópontból minden csomópont csak egyetlen úton érhető el.) Nem részletezném hogy a fe bejárhatósága adott esetben mennyire időigényes.

A hálós adatmodell esetében ha maradunk a gráfnál, akkor az egyedek szintén a csomópontokat, az élek meg a kapcsolatokat modellezik.

A relációs adatmodell eleme a matematikai reláció amely Descartes-szorzat részhalmazát jelenti. Ez a sorozat lényegében elemi egységekként kezelt entitásokat rendel egymás mellé. A sorozat egyes műveleti tényezői egy-egy halmazból, értékkészletből veszik fel értéküket, amelyeket végesnek tételezünk fel. Azonos típusú és szerepű elemek halmazát attribútumoknak nevezik. A attribútumok egy névvel ellátott rendezett halmaza pedig a séma. A séma-attribútum-reláció hármas egy táblázatot ír le, ahol az attribútumok az oszlopokat jelölik; a reláció a ténylegesen előforduló, kitöltött sorok összességét jelenti; a séma a táblázat alapszerkezetének, az oszlopfejlécek sorrendjének elnevezése. A relációs algebrán a következő algebrai alapműveletek értelmezettek: Descartes-szorzat, unió, különbség, szelekció, projekció. Minden alapművelet kizárólag relációkon értelmezett (ezért relációs az adatmodell neve), azaz minden művelet csak relációkon végez műveleteket.
A relációs relációs adatmodell egyéb származtatott műveleteket is megenged, ezek száma korlátlan. pl: metszet, natural join, Theta illesztés, stb.

Igazából első gondolatom az volt, hogy az iwiw-ben előforduló kapcsolatrendszeri háló valamint az alap adatok rendkívül jól ábrázolhatók a hálós adatszerkezeten. Ha ez az állításom igaz, akkor teljesen szükségtelen egy relációs adatbázisba átkonvertálni az adatszerkezetet csak azért hogy legyen hol tárolni adatainkat, valamint az adatszerkezet miatt sokkal hatékonyabban bejárható (lekérdezhető) az adatbázis. Hangsúlyozom, hogy egyáltalán nem biztos hogy matematikailag bizonyítható minden elvárásnak megfelelő adatábrázolás valósítható meg a hálós adatszerkezeten az iwiw igényei szempontjából, de ha bebizonyítható hogy igen, akkor már minimálisan 2 adathalmazban (fájlban) elhelyezhető az egész adatbázis, és érdemes lehet megírni azt a szerver oldali alkalmazást ami lekezeli az adatkezelési igényeket. Nyilván meg lehet spórolni vele az 'lassú' SQL értelmezőt is...

Nos matematikailag meg lehet támadni az állításomat, vagy alá is lehet támasztani bizonyításokkal, és úgy gondolom egy igényes tervezési folyamat mindig itt kell hogy kezdődjön - mint ahogy azt már számtalanszor mások is kiemelték - és csak úgy lehet szakmailag igényes munkát végezni ha az alternatív lehetőségeket is megvizsgáljuk már a tervezési fázisban.

A mostani adatbázis kezelők sokat tudnak, mert igyekeznek széles igényeknek megfelelően jó költség/teljesítmény aránnyal megoldást kínálni a napi problémákra, de szerintem már egy akkora projectnél mint az iwiw érdemes lenne jól megtervezni a rendszert.

Csak azt tudom ajánlani, hogy ne próbálkozz belefolyni olyan erőforrás igényes üzleti projectekbe amiket a napi pár száz látogatót kiszolgáló LAMP rendszerek már nem viselnek el.
És nem árt előtérben tartani: a programozó legjobb barátja az alkalmazott matematika.

Ha gyakorlat nálad azt jelenti, hogy nem csinálok 1/nap-i rendszerességgel CMS alapú (pl. Drupal) alalpú portálokat, akkor valóban nincs kellő gyakorlatom. De ha azt veszem hogy van pár vállalat, bank, minisztérium aminek a rendszerénének a fejlesztésénél ott voltam a tervezéstől az auditálásig akkor viszont tévedtél!

Javaslom, hogy olvasd el mégegyszer a tananyagot a hierarchikus és a hálós adatmodellről, külön kitérve arra, hogy milyen fájlszerkezettel valósítható meg, mikor használták és miért került leváltásra. És nem utolsó sorban nézz utána, hogy egy sql kiszolgálónak milyen a belső felépítése! A parse-olás nagyon gyors művelet, nem sokkal lassabb, mint egy szövegfájlból az adatokat beolvasni, ami az időt viszi az már a lekérdezés megtervezése, optimalizálása. Az adatok elérése piszok gyors, köszönhető a btree adattárolásnak, a page cache-nek és még pár dolognak. Ami lelassítja az a többszálú tranzakció kezelés, zárolások, stb. Ezt szövegfájlnál hogy oldanád meg?
Elhiszem, hogy úgy gondolod, hogy az iwiw-ben sokminden csak egy entitás attribútumai (pl. a személy adatlapja), de az entitást gyorsan el kell tudni érni és azért vannak itt entitások közti lekérdezések is, nem beszélve arról, hogy a módosításnak is gyorsnak kell lennie. Mindennek hatékonynak és megbízhatónak kell lennie nagy adatmennyiségek esetén is. Relációs modell esetén sokkal szabadabbak a lekérdezési lehetőségeid, mint a hálós modell esetén. És azért az se mindegy, hogy mennyire támogatott, elterjedt módszert használsz. A hálós modell helyét a 90-es évek közepére átvették az sql adatbáziskezelők és ha még egyeltalán valaki fejleszt hálós adatmodellre kiszolgálót, akkor is kicsi a választék és bizonytalan a jővője. Ez egy szerveralkalmazásnál megengedhetetlen.

A relációs adatbázis a 70-es években kezdett elterjedni, az SQL nyelvet az a csoport kezdte el fejleszteni az IBM-nél, ami azután kilépve az IBM-ből az Oracle cég lett.
Pontosan ismerem az SQL rendszereket, hiszen nap mint nap ezzel foglalkozom; de azt is át kell gondolni sok esetben, hogy optimális -e ez a rendszer adott esetben.
Én most csupán csak adatszerkezetek problémáját vetettem fel, nem foglalkoztam a költség tényezőkkel, a supporttal stb.
Az SQL lekérdezés alapvetően időigényes lekérdezés, tetézi még azzal is, hogy egy relációs adatszerkezeten (általában) több vagy öszetett lekérdezéssel lehet elérni az eredmény halmazt.
Csak példaként tudom állítani a Google esetét, ahol nincs adat arra vonatkozóan hogy relációs adatbázis vagy SQL adatbázis alapú rendszer működne, nyilván nekik sikerült optimálisan az elvárásaiknak megfelelő szerver oldali adattárolást kitalálni.
Abban azért biztos egyet érthetünk, hogy alapvetően az adatbázis kezelés a rendszerek "lassú" láncszeme, és nem a java nyelv vagy a ASP ami egyedül a prbléma okozója.

"Mindennek hatékonynak és megbízhatónak kell lennie nagy adatmennyiségek esetén is."
Ez alapvetően egy szoftver feljesztői feladat.

"Ami lelassítja az a többszálú tranzakció kezelés, zárolások, stb. Ezt szövegfájlnál hogy oldanád meg?"
Nem érdemes leragadni a "szövegfájl"-nál, maradjunk a "fájl"-nál!
Nyilván amennyiben nem egy meglévő adatbázis kezelőt állítok be, akkor egy szerver oldali alkalmazást kell fejleszteni, ami lekezeli a fájl kezelést, a memoria használatot, a cashelést, és azokat a technologiákat amiket elmlítettél. Persze ez is egy igazi programozói feladat, hiszen elő kell venni pl. a C fejlesztői eszközöket is.

De mindezek fényében egy milliárdos projectről van szó, ahol talán meg lehet azt oldani, hogy néhány program fejlesztő néhány hónapig dolgozzon a fejlesztésen.

Én a relációs adatbáziskezelők belső működésében "némileg" már elmélyültem. Ennek tükrében számomra elég meredek a kijelentésed, hogy
"...hogy néhány program fejlesztő néhány hónapig dolgozzon a fejlesztésen."
Mindkettőt értsük úgy, hogy pár tíz? Mert akkor esélyes, hogy meg lehetne csinálni. De akkor is többe kerülne a support hozzá, mint a drágább vas üzemeltetése, nem beszélve arról, hogy specializáltabb tudásra lesz szükség, ha valamit módosítani kell (biztosított munkahely pár embernek).

A többire nem reagálok, mert csak egyre jobban elbeszélnénk egymás mellett. Te egy másik burokban létezve nézed a dolgokat.

SQL (RDBMS) -tol mindig letezik gyorsabb vegy egyenlo sebbesegu megoldas.
Az a baj, hogy te modellt keresel ra, mig masok kodert aki megirja :)
Nem arrol van szo, hogy egy konyen bivitheto dolgot hegesztel, hanem arrol, hogy irsz egy cumot ami kizarolag az adott szitiacioban (iwiw) k. gyors, megha kodolas kozben eretnek dolgokat is kovetsz el :)

Jah, meg belso informaciok kitalalasa... De beszeljunk masrol, ugy altalaban szerver oldali alkalmazasokrol, Javatol es iwiwtol fuggetlenul... :)

Ha egy alkalmazasba beraksz egy szinkronizacios pontot, amelyet _minden_ szal rendszeresen es gyakran lekerdez, akkor ohatatlanul egymasra varnak a szalak, azaz a szinkronizacio a szuk keresztmetszet. Namost ha megnezel nehany popularis cache keretrendszer forraskodot, ott a rosszabb esetekben pont egy synchronized blokkon keresztul erik el a cache-t. Elegge visszafogja a teljesitmenyt...

A masik tipikus hiba, ha barmilyen jo is a program (nyelvtol fuggetlenul), rossz a megvalositasi kornyezete. Pl. ha rosszul van beallitva a load balance es a session sticky bit, akkor hiaba raksz ala barmit, szenvedni fog a belso halozati forgalomtol...

Namost, visszaterve az iwiw-re, nem a JSP-ben van a hiba, es ezt tovabbra is tartom :)

ha a párhuzamosság a baj, akkor újra kellene tervezni azt a részt, mert elfogadhatatlan, hogy a leggyakrabban használt kódrészlet a leglassabb... Gondolom ilyen esetben egyszerű read-write lock van, azt fogja meg, no de ebben az esetben nem túl jó választás. Van más is, ami biztosítja a párhuzamosságot, konzisztenciát - és nem lassít. Persze erősen függ az adott feladattól, hogy mit kell használni...

( freeoli v | 2007. 03. 04., v – 22:45 )

XP + firefox 2.0.0.2 vel meg se moccan ... ie6 al viszont pöccröff ... ez nagyon gatya ... szándékos vagy valami nem lett eléggé kitesztelve?????

Szerintem sok minden nem lett ott kitesztelve. Volt már olyan, hogy totál nem ment a kereső, bármit írtam, 0 találatot adott. Kitöröltem a browserből a cookie-kat, és erre megjavult.
Most meg operában jelenik meg igen ramatyul szétcsúszva a bejelentkezőképernyő, de azért működik.

( wladek1 | 2007. 03. 04., v – 23:55 )

Sziasztok!
Mostantól hozzáférhettek az iWiW gadget-hez (minialkalmazáshoz), amelyet a magyar Windows Vista megjelenése apropóján, azzal kapcsolatban fejlesztettük ki. Célunk az volt, hogy az iWiW fontosabb funkcióit a számítógépeteken még kényelmesebben elérhessétek. Letöltéséhez kattints ide!
Hamarosan a Mac OS X operációs rendszer alatti - iWiW widget - verziót is elkészítjük.

Most úgy néz ki, erre gyúrnak... Nem érnek rá ilyen kis ügyekkel foglalkozni, minthogy Linux és FF valamint pera alatt milyen problémáink vannak. A "widget"-et sem erre szánták...

--
//:wladek's world

( mofli | 2007. 03. 05., h – 08:28 )

Valószínleg a reklámok okozzák, mivel nem ellenőrzik le eléggé, hogy mit szerkesztenek bele a lapba.

( wladek1 | 2007. 03. 07., sze – 21:51 )

XML-feldolgozási hiba: xml deklaráció külső entitás kezdetétől eltérő helyen
Hely: http://iwiw.ru/pages/main/index.jsp;jsessionid=1
209. sor, 10. oszlop:

</script><?xml version="1.0" encoding="UTF-8"?>

---------^

Na, ez nekem is új volt. Meghívókérés állapotának megtekintése után irány a kezdőlap.
Igen, iwiw.ru , mert így elég nagy eséllyel 10 alkalomból nyolcszor legalább valami bejön...

--
//:wladek's world

( Frantique v | 2007. 03. 08., cs – 11:51 )

Szerintem alultervezett a rendszer. Nem tudom, miért nem nézetik át független szakértőkkel, ha már ennyi pénzt öltek bele... Azt hiszem, ha kidobnák "közösbe" a forrást, lennénk páran, akik racionalizálnánk a kódot. Most az a tipikus eset van, hogy nem számoltak ekkora adatmennyiségre, teszteléskor 100-200 rekordokkal szórakozhattak. Ha nem, akkor szomorú.
Engem spéci ez is zavar:

http://www.electronicart.hu/iwiw.jpg

Igénytelenség... azt nem feltételezem, hogy 1 milliárdot érő rendszert ilyen kontárnak kinéző kóderek gyártották. ;)
--
Coding for fun. ;)

( freeoli v | 2007. 03. 08., cs – 12:55 )

Túl kocka a banda ...

Hogy lehet egy ilyen értékű rendszerbe egy ekkora prosztó szöveget beleírni???? ráadásúl ami sok ember arcába meg is jelenik ... én ezt nem értem :(

( bailey | 2007. 03. 08., cs – 20:43 )

az érdekeség az érdekesség akart lenni?
vagy
"érdekes ég"-et akartál? :p
--
bYe bailey

( kissipos | 2007. 03. 10., szo – 01:57 )

Nemrég barátnőm felhívott telefonon. Azt kérdi tőlem, hogy "mi az az Ajax error?" Hogy ez hogy jön ide? Hát úgy, hogy a munkahelyén történt az eset, ahol Internet Explorer 6-ot használnak és épp iwiwezni akart.

__________________________________________________________________________

"Ennek a fiúnak semmilyen kollektív jelentősége sincsen: éppen hogy egyén."

Hát sajna nem megy az alvás. Ha le is fekszem legkorábban éjfélkor, akkor is álmatlanul forgolódom az ágyban kb. 2-ig. (Nem, nem szerelmi bánat, szimplán álmatlanság.) Akkor meg már inkább csinálok valamit. Netezek, meg filmet nézek, meg egyebet.
Na, most már megyek lefekszem, de előtte még dumálok egyet jóanyámmal (most fog felkelni, mert megy dolgozni).

__________________________________________________________________________

"Ennek a fiúnak semmilyen kollektív jelentősége sincsen: éppen hogy egyén."

szintén...
Pedig rohadtul nem egészséges. Nappal nehéz felkelés, fáradtság, kimerültség, éjszaka meg zsibbadt ébrenlét, mert álom nem akar a szememre jönni. A legjobban még az megy, hogy 3-ig nyomom és utána valahogy beájulok. Viszont az egészségem és a közérzetem már így is megsínylette. Lemegy a mostani hajrá és kikezeltetem magamból ezt.

( konczy | 2007. 03. 10., szo – 10:58 )

Kicsit elsiklottatok a szakmázásban afelett, hogy nem a programkód ért milliárdot, hanem a kapcsolati háló :) /de legalább kiderült pár szakmai dolog is offtopic/.

( Rt711 v | 2007. 03. 22., cs – 16:34 )

ismet>
xml parsing error: unclosed CDATA section
location: http://iwiw.hu/pages/main/index.jsp
Line Number 211, Column 28

document.forms['mainForm'
-----------------------------------------^

azert a vegen csak sikerult bejutnom :)

XML Parsing Error: unclosed token
Location: http://iwiw.hu/pages/user/friends.jsp?userID=xy /kiszedtem az ID-t: by rt/

Line Number 22, Column 483://]]>

iWiW - Adatlap

ez egyre jobb :D