XCHAOS: Pockej, kazdej provozovatel velky sluzby ma pochopitelne spoustu ruznejch nodu ruzne po svete. Plus nejaky cache servery "blizko" uzivatelum (u ISP) apod. A nebo sem totalne nepochopil o cem mluvis.

ALMAD: víceméně, představa je, že by to fungovalo víc jako v počátcích Internetu, kdy nějakou jednu službu (dejme tomu, freemail) nenabízel jen jediný poskytovatel té služby na celé planetě, kromě to samé často koexistovalo jak v komerční tak i v bezplatné podobě, apod.

V podstatě u komerční služby je riziko, že bude přetížená a uživatelé odejdou ke konkurenci, v zásadě nepřijatelné. na druhou stranu, existují projekty - ve světě PHP si dokonce konkurují, všechny ty Drupaly a WordPressy a tak - které jsou přímo myšlené tak, že si další a další lidé budou instalovat další a další instance, a ne že nody budou růst nade všechny meze.

víceméně provozovatelé různých nodů budou různě limitováni dostupnými zdroji (bandwidth, výkon systému, kapacita disku...). budou mít ale i omezené možnosti svůj node zpropagovat a nabírat nové členy. naopak zřídit nový node by mělo být snadné.

spíš si to představuji jako počátky internetového e-mailu před 20 lety. akorát to bude od začátku lépe navržené, aby to bylo odolnější vůči spamu apod. ... no dnešní centralizovaná řešení to vytlačí stejně, jako před 20 lety decentralizované internetové protokoly vytlačily tehdejší pokusy o centralizovaná řešení (a ty rozhodně existovaly)

ALMAD: on demand zapnutí pár tisíc mašin je to, čemu bych se chtěl snažit vyhnout. to je celé...

XCHAOS: co je "současný stav": ten stav, ve kterem tvoje novinka ma "zamichat kartama".

Jestli se bavíme o tom, jestli má nějaké výhody smolit webové aplikace v PHP - tak nadále tvrdím - ne, nemá, měly by se vyvíjet v kompilovaných jazycích. - coze? O tom se nebavime (a btw, prvni pulka odpovedi je dobre, druha spatne 8) ). Bavime se o nejakem tvem "predkompilovanem SQL", u ktereho nejsi bohuzel schopen poradne popsat co vlastne by to melo byt a k cemu by se to melo pouzivat.

DAVIDOWITCH: v tom případě ten, komu se to stalo, se svou intuicí neumí pracovat (teď se samozřejmě nebavím o případech, kdy si Hitler intuitivně myslí, že v Rusku bude mírná zima :-)

_BENNY: já ale netvrdím, že intuice je nějaký okamži tý proces, nebo že dodá hotová použitelná řešení. intuice tě spíš směruje určitým směrem. intelekt na to reaguje dodáváním určitých řešení, které je ovšem samozřejmě nutné podrobit kritice.

REDGUY: co je "současný stav"? jako jo, pokud se bavíme o některých věcech, co jsem napsal dřív v C a nevyžadují reagovat na uživatelskou interakci v reálném čase, tak bych je dost možná dnes napsal v Pythonu (akorát mi přišlo děsně cool, že Python nepotřebují k tomu,aby běžely, ve své době... a taky jsem ho neuměl).

Jestli se bavíme o tom, jestli má nějaké výhody smolit webové aplikace v PHP - tak nadále tvrdím - ne, nemá, měly by se vyvíjet v kompilovaných jazycích. Očekává se tam stále větší nárazový paralelismus (více uživatelů současně) a stále svižněší odezva v reálném čase (ajaxové klikance a možná i onmouseovery...)

_BENNY: proste to nejlepsi reseni obvykle neni takove, ktere nas napadne jako prvni a jako prvni se nam libi. toho sis mohl za svuj zivot uz vsimnout ;)

XCHAOS: delas z toho neco jineho nez jsem rekl. to neni o tom za kazdou cenu odmitat intuici, to je o tom za kazdou cenu nezustat jen u intuice a nepohnout se dal jenom protoze je to tak sebeopajejici ;P

proti intuici trenovane kritickym rozumem nemam naprosto vubec nic, ale toho jsem se u tebe jeste nedockal ;)

XCHAOS: To neni otazka filozofie, spis vysledek pozorovani. Kdyz udelas neco podle intuice a pak to zacnes vic zkoumat, zjistis ze jsou lepsi pristupy.

DAVIDOWITCH:
_BENNY: tomu říkám tedy základ civilizace... odmítat intuici za každou cenu... :-)

já naopak pokládám za rozumné intuici kultivovat - tím, že se k ní chovám mile a pozorně a občas jí přikrmuji vhodnými metaforami.

ISTEVE: tak pochopitelně, že parsování je míň než zanedbatelný... to už jsme si tady vyjasnili. spíš mě zajímala prekompilace v kombinaci s nějakým direct memory access api - tedy, že by se data neproháněla přes socket. ale to je celkem fuk.

nemusíme se bavit jen o příkladu s joinem přes pět tabulek, myslím. přípomínka s tím, jak velkou roli hraje cacheování, je samozřejmě taky dobrá.... vlastně moje omezené programátorské zkušenosti vedou k tomu, že cacheovat se vyplatí vždy téměř všechno (kromě věcí, o kterých programátor předem ví, že jsou z principu necacheovatelné, což by ale právě u budoucích vývojářů-optimalizátorů mohla být jejich hlavní role... být schopni toto rozhodovat...)

REDGUY: v tom případě ale nechápu, proč používáš druhou osobu místo třetí ("pokud někdo čeká...."). takový styl vedení debaty zdá se mi býti manipulativní.

XCHAOS: _já_ že čekám, že databáze něco vymyslíš za mě Napsal jsem, cituji, "Pokud cekas", nikoliv "Cekas". Nauc se cist 8))

REDGUY: _já_ že čekám, že databáze něco vymyslíš za mě? co je tohle zase za slaměnný fígl? (strawman fallacy)

TENCOKACISTROMY: Samozrejme, ale o to tu preci jde, ne? Zajistilo to zrychleni pro jeden konkretni xchaosuv priklad.

Nesnaz se tu prosim v tomto klubu zobecnovat. To neprojde ,)

XCHAOS: Ze napises nekam "=" ve smyslu prirazeni, jeste neznamena ze to je imperativni jazyk.
Nicmene ano, napriklad u procedur se projevuje imperativ-like cast jazyka.

Zrovna MySQL neni technologie, kterou bych znal nejak podrobne. Nicmene jsi si jistej, ze "ENGINE = MEMORY" zmeni algoritmicky pristup u dotazu? Nezrychlil jsis to treba tim, ze jsi eliminoval IO operace na disk?

_BENNY: Proto ma kazdy spravny muz nosit nuz, aby se mu ubranil!

(Teda, doted jsem si myslel ze jsi ukladani session dat uvadel jako priklad tvyho michani kartama... ale kdyz ctu REDGUY, tak premejslim jestli nejde o nejakou novou unrelated prevratnou ideu ;) )

XCHAOS: ale já jsem třeba imperativně řekl MySQL ǎt na tabulku použije ENGINE = MEMORY - no tak v prvni rade, MySQL je dost sracka. Za druhe, i u skutecnych databazi je nejake to ladeni potreba, i kdyz obvykle ne v tak brutalni podobe. Pokud cekas ze databaze _vsechno_ vymysli za tebe, jsi dost mimo. No a za treti, dost mozna je to prave ten priklad, ze pouzivas MySQL na neco, na co neni urcena a pak se nediv, ze to musis extra stelovat aby to jakz takz fungovalo. Cili tvoje l33t skillz s ENGINE=MEMORY zas tak nic nedokazujou.

XCHAOS: Nerozumim. Na co presne reagujes? A co tim chces rict?

TENCOKACISTROMY: dobře... ale já jsem třeba imperativně řekl MySQL ǎt na tabulku použije ENGINE = MEMORY ... a tím jsem výkon výrazně zvýšil. takže tvrdíš, že mám používat jen takovou SQL databázi,která si engine zvolí sama? a jak bude vědět, že zrovna u téhle tabulky mi nevadí ztráta dat při restarty SQL serveru, a u jiných jo?

trochu imperativního přístupu k programování zkrátka neuškodí u jakéhokoliv paradigmatu

REDGUY: mno, tedy přesněji, v mém případě bylo potřeba použít max_heap_table_size = 256M v my.cnf (default je asi 16 MB... každopádně se to zaplnilo skoro hned). zvýšení výkonu je dost citelné, na druhou stranu - asi by bylo zajímavé to srovnat s nativní datovou strukturou přímo ve sdílené paměti (což možná časem zkusím).

no každopádně se mi nelíbí, že se to tady začíná zvrhávat na diskuzi "proč není potřeba C". zatím jsem minimálně dokázal, že není potřeba se srát s memcached :-) (tedy samozřejmě je otázka, do jaké míry je ENGINE = MEMORY v MySQL pomalejší či méně paměťově efektivní, než memcached - ale současně výhoda spočívající v unifikovanosti a možnosti použití složitých SQL konstrukcí je zřejmá (memcached nabízí v podstatě jen něco jako "hodně enviroment proměnných via socket").

(ale jo... možná skončím u toho, že místo sraní se se složitou shared datovou strukturou použiju pro svojí příští libmysqlclient webovou aplikaci napsanou v céčku prostě jako rychlé úložiště dočasnou SQL tabulku forcnutou do paměti - a bude vymalováno - minimálně ten zdroják bude hodně blbuvzdorný a čitelný, což je ostatně i mým cílem...)

TENCOKACISTROMY: to je tak obecné tvrzení, že vlastně nevím, co ti na to mám odpovědět, ani jestli odpovídáš na to, o čem mluvím :-)