Python a Ruby v Apachi a Hurvínkova válka (diskuse)

[Kyosuke]

Tak zrovna v rubím světě lidi hodně ujíždějí na Mongrelu. To je taková tvrdá droga z kategorie stavových automatů.

[daeltar]

Mongrel cluster ze 3 mogrelů, proxovanej za load balancingem v Apachi 2.2 je opravdu návyková záležitost. Funguje to skvostně, jen to trošku žere RAM(55 MB / 1 Mongrel).

[al-Quaknaa]

Mno, to je sice hezké, ale pokud je to jediná možnost, tak pro Rubysty i dosti smutné ... Jinak po přečtení článku o "ladění výkonu RoR aplikací", kde se píše o průměrné spotřebě 20 - 70 MB/aplikaci, která visí v paměti _pořád_ se mi začínají dělat mžitky před očima. Já jsem chtěl tu službu dávat zadarmo, ale i když jsou RAM levné, _takhle_ levné zase nejsou. A na desku, která tam tuším bude (ten server jsem pod rukama neměl), nejspíš stejně tolik modulů nasázet taky nepůjde, i kdyby je někdo zaplatil. Achich ouvej. Takže mod_ruby nic?

Navíc - pro práci s RoR potřebuje uživatel ssh účet? Zatím všechny návody obsahují příkazy spouštěné normálně v shellu, což by mi zase zkomplikovalo práci. Ještě bych mopžná připustil a zvládl nějaký chrootovaný ssh + busybox, ale jak mám doháje udělat "minimální" systém s RoR?! S TG je to dost možná podobné ...

[Kyosuke]

Hmm, možná bys měl vyzkoušet J2EE, abys vystřízlivěl. Mongrel není jediná možnost, ale je preferovaná. Každopádně bych si odpustil řeči typu „ačkoliv si Rubysté nedokázali vymyslet nic lepšího, než pouštět ruby jako CGI. Co na tom, že se musí pro každý request ruby spouštět znova. Od čeho jsou dedikované servery, že ano? No, možná kdysi cosi slyšeli o FastCGI.“, které zdárně kandidují na označení „kecy, žvásty a kydy“, protože Mongrel a Capistrano ukazují, že rubisté vymysleli lepší věci než CGI. Takže prosím neFUDovat. Přístup typu „není pro to modul do Apache => jest to póvl, bzdíti na to budu, jakož i káleti“ mi taky přijde vyloženě směšný. (Co mají říkat třeba některé lispovské implementace, u kterých jsou model paměti a architektura runtimu dost neslučitelné s embednutím do čehokoliv? Rovnou je vyhodíme do koše, přestože nabízejí výkon Cčka se sémantikou vysokoúrovňového jazyka?)

[al-Quaknaa]

No, tos mě trošku špatně pochopil :D Já proti mongrelu nic nemám; vůbec se taky nezmiňuju o jeho výkonu, který může být excelentní. Pokud se ale podívám na návody, které se na Internetu nabízejí (co se týče Ruby on Rails), tak se tam skoro vždycky nabízí jako první řešení spouštět ruby přes CGI, což je pomalé, následující potom je spuštění v "produkčním režimu", které je v přes fcgi, což je rychlejší. Mongrel se tam moc nezmiňuje.

Proč Mongrel zamítám, nebo proč mě moc nezajímá, že Rubysté vymysleli něco lepšího než je FastCGI? Asi proto, že se tady snažím najít řešení dostupné pro masy, a tím mongrel asi nebude. Pokud vás ale napadá, jak to pro ty masy a s mongrelem vymyslet, nechám se poddat. A to myslím vážně - už mě samotného napadlo, že by určitě šlo spouštět toho mogrela na různých (volných) portech a přistupovat k němu přes reverzní proxy, která bude směrovat požadavky na různé VHosty v závislosti na http Host: entitě - to už jsem řešil v poradně a vyřešil.

Abych to teda trošku přoblížil, když už tady odhaluju něco z chystaného. Cílem bylo ušetřit trochu paměti - řekl jsem si, lepší, než provozovat jednoho Apache s načtenými mod_php. mod_python a mod_ruby, bude mít tři Apache, kde u každého z nich budu moct regulovat počet procesů (serverů a vláken) zvlášť, zároveň taky každý proces bude menší. Ty poběží na portech, dejme tomu, 8080, 8081, 8180 (jsou-li volné, ale to je detail), a jednotlivé požadavky na ně budu přehazovat pomocí reverzní proxy, jako je třeba Pound.

A teď zpět k Mongrelovi - jestli je nějaký způsob, jak bez ssh přístupu (pokud mi napíšete nějaké webové rozhraní, tak třeba přes něj, mě je to jedno :D) tvořit/ovládat rails aplikaci a spustit Mongrela na určitém portu s právy daného uživatele (tedy pro každého uživatele zvlášť), tak bych se tomu zas tak moc nebránil. Sice pořád nevím, co s pamětí, ale třeba bych to překousnul. Ale musíte uznat, že takováhle správa by byla podstatně komplikovanější, než kdyby běžely prostě jen tři indiáni nějak rozumně nakonfigurovaní a pomocí mod_ruid a mod_ruby by si prováděli zbytek té magie sami?

Na Mongrela jsem tedy plivat nechtěl, ale podle všeho, co jsem si zatím přečetl, to vypadá tak, že všichni Rubysté prostě provozují své aplikace na serverech, ke kterým mají takový rozsah práv, který já zkrátka jenom na dobré slovo (registraci zdarma) dát nemůžu. A to je právě to, o co mi jde a moc rád bych si tenhle cíl zachoval.

[Daniel Kvasnička ml.]

jestli je nějaký způsob, jak bez ssh přístupu (pokud mi napíšete nějaké webové rozhraní, tak třeba přes něj, mě je to jedno :D) tvořit/ovládat rails aplikaci

No nejaky asi musi byt. Uz sem tu parkrat zminoval Webfaction, ktery na to ma control panel bezici na CherryPy. Naklikas framework a jedes. Viz. jejich blog. (Vim, ze je to asi reklama, ale nikde jinde jsem nic podobnyho nevidel a dost se mi to libi )

Jinak jeste k TurboGears: s mod_pythonem by to melo jet, ale musis mit min. verzi 3.2.7. Ja s 3.1.4 narazim na uplne stejny problem jaky je popsany v TG Google Group. S verzi 3.3.1 to vypada, ze to pujde, ale jeste se mi to nepoddalo.

[al-Quaknaa]

No, popravdě takhle nějak jsem si to představoval i já. S tím, že tam z těch PHPčkovejch (kterých je nejvíc) bude mnohem více věcí. A že to bude zadarmo. Proto se tady o něco snažím :) Akorát ti pánové z Webfaction mi asi neřeknou, jak mají ty Rails nastavené, že? Bylo by to od nich hezké :D Jinak - vzhledem k tomu, že neprogramuju, neměl by někdo zájem nějaký takovýhle panel dělat? Třeba bychom se i dohodli na tom, že bych nějakou korunou na jeho práci přispěl, nebo tak něco. Úplně nejlepší by bylo, kdyby mi naprogramoval něco, co by prostě jenom spouštělo nějaké šablony v určitých bodech vytvářené profilu, přidávání aplikace a podobně - já bych si už pak vystačil sám a bylo by to takové univerzální řešení.

Pokud by to náhodou někoho zajímalo a nebyl by proti, tak jenom nastíním, o co bych stál: dohodli bychom se na tom, jaké akce má ten panel zvládat a u každé akce by si řekl o nějaké informace, které by následně předal té mé šabloně. A ta už by následně jenom spustila nějakou dávku příkazů, ve kterých by používala data z panelu. Takže já bych jenom znal jakou proměnnou kde použít (jméno, přidělené kvóty, požadovaný framework) a s tím bych pracoval v nějakém primitivním (třeba) BASH skriptu (protože to "umím"), a ten panel by zas nemusel vykonávat nic jinýho, než tyhle údaje pro pozdější zpracování zapsat do databáze a vrátit uživateli nějakou hlášku (která by byla asi taky součástí toho skriptu). Nevím, jak moc je tohle programátorksy čisté, ale každopádně mě by to vyhovovalo maximálně :D

Jak jsem totiž napsal na konci tohoto blogu, server už mám, nastavení pro Apache/PHP též, nastavení pro Apache/Python zdá se taky (po vašich radách), nastavení pro Apache/Ruby (mod_ruby) zatím asi moc ne, ale nikdo z diskutujících se mi zatím moc nepokusil pomoct ;). A pak už je jenom ten nastavovací xicht, který si asi sám nenapíšu. A jak už jsem uvedl na začátku, mělo by to být zadarmo, co nejvíc free a open, takže vaši asistenci uvítám a nezneužiji (jen ve svůj prospěch).

[Daniel Kvasnička ml.]

Pokud jde o me, jsem ted casove maximalne vytizen, takze ti bohuzel nepomuzu.

Jak te tak ale posloucham, tak ti poradim to, co uz jsem jednou psal: zapomen na to, ze to bude zadarmo, jestli to myslis vazne. To neni rada ve smyslu: "mas sanci z lidi vytriskat prachy, tak na co cekas". Tady musis brat terminy free a open jinak. Nedelas SW, ktery das nekam na web a dalsi ti ho v ramci open source pomahaji budovat a vylepsovat. Ty mas fyzicky server, do ktereho si investoval penize, ktery se casem opotrebovava, ktery zere energii i tvuj cas. A jsou tu lidi, kteri delaji nebo by radi delali komercni aplikace v Djangu a podobnych, ale zatim to nemaji kde hostovat a ti by ti mohli nejakou rozumnou castku platit. Zajdi si na financak, do skoly a tak a zjisti si PRESNE, co v tvem pripade obnasi mit zivnostak jako student (a jestli ho na to vubec budes potrebovat). No a pak si rozmysli, jestli kdyz teda do toho pujdes komercne, jestli budes ve vztahu ke skole mit dost casu na to, abys plnil sve zavazky vuci platicim klientum...coz je vec druha.

Byt tebou, zkusil bych to proste rozjet jen tak a kdybys videl, ze to ma budoucnost, tak bys najel na komercni hosting.

[al-Quaknaa]

Jo, díky za rady. Už se mi ozval jeden člověk s tím, že rád pomůže, takže třeba i nějaký panel se zrodí. A pokud jde o to, zda by to vážně mělo být free - ano, získávám nějaké pochybnosti. Ale nejdřív to zkusím s pár lidma, uvidím, jaká bude zátěž (může mi někdo potvrdit, že je to opravdu tak, jak jsem všude četl, že totiž každá Ruby/Python aplikace, narozdíl od PHP, pořád bere paměť - protože pořád běží?) a _možná_ se nejdřív pokusím sehnat dostatek lidí, aby se ten server zaplatil, a pak tam třeba rozjedu něco free. Já nevím, je to pro mě dosti nové (Python a Ruby a jejich frameworky) a tak se asi budu rozhodovat podle situace.

Jinak ale mám takový drobný předpoklad - pokud si tam někdo udělá účet a vyrobí si nějakou (třeba) TG aplikaci zadarmo, tak pro komerční provoz je doména třetího řádu tak jako tak na kočku a tudíž si koupí placenou variantu. A pokud je to jen nějaký nadšenec, co si chce udělat stránky, tak si tam nakliká nějaký PHPčkový redakční systém, který mě zas tak moc nemrzí - neběží rezidentně v paměti. Ale jak říkám, uvidíme. Každopádně až to poběží, tak tě kontaktuju na testování TurboGears :) A pokud je tady někdo, kdo by se přihlásil an testování RoR, tak mi prosím dejte vědět, abych si vás připsal na seznam. Howgh

[Daniel Kvasnička ml.]

(může mi někdo potvrdit, že je to opravdu tak, jak jsem všude četl, že totiž každá Ruby/Python aplikace, narozdíl od PHP, pořád bere paměť - protože pořád běží?)

Podle me je to tak, pokud by jsi nepouzil mod_python, tak urcite. S TG (a mozna i s dalsimi, co pouzivaji MySQLdb) je tu jeste jeden problem a to, ze TG si drzi stale otevrene pripojeni na DB (kvuli zabudovanemu systemu zaznamenavani navstev) a kdyz na tu aplikaci hodne dlouho nikdo nepristoupi, to spojeni padne a MySQLdb si ho neumi znovu nahodit. Takze kdyz jsem pustil tu aplikaci a treba 12h ji nikdo v prohlizeci nevyvolal, dostal jsem pak chybu 500 s hlaskou "MySQL server has gone away". Ctrl+F5 v prohlizeci to nahodilo, ale pro verejnou aplikaci je to nemyslitelne. Zkouseli jsme na to v praci nejaky hack a zatim se nepovedlo, tak nevim...

[hele]

na to staci nastavit timeouty na mysql serveru zejo. takze to neni problem.

[Daniel Kvasnička ml.]

No jenze to neni server, kterej by byl urcenej jen pro moji aplikaci. A jen kvuli ni tam nechavat viset pripojeni X hodin kdyz tam jsou dalsi vykonove kriticke aplikace, to neni nejlepsi reseni. Na verejnem hostingu, to uz ani nemusim komentovat...

[al-Quaknaa]

Že by? Ale je to jen střela do prázdna, vím, že když jsem hledal, zda je možné ten mod_python použít, tak jsem na nějaké takové problémy narazil, takže se to určitě řešilo a vyřešilo. Na tohle jsem narazil v jednom mailinglistu. Je to k něčemu?

[Daniel Kvasnička ml.]

Tohle je presne ten patch, se kterym jsme to rekompilovali a bez vysledku. Nicmene chyba mohla byt nekde v nasi konfiguraci, protoze jinym lidem to evidentne pomohlo problem vyresit.

Co si budem povidat. Musim priznat, ze v deployingu je to 1:0 pro Django.

[al-Quaknaa]

Jo a ještě k tomu "free a open" - šlo mi o to, že bych chtěl co nejvíc z použitých postupů a případně i programů publikovat veřejně. Aby to zkrátka měli ti po mně lehčí. Takže ve vztahu k tomu Control Panelu jsem narážel na to, že by to měl být open source a že pokud to někdo napíše, tak že z toho nebude nějaká exkluzivní služba. Já vím, že moc ekonomické to asi není, že kdyby byl ten hosting jediný, co by to nabízel, tak by měl asi větší šance, ale já jsem takhle přesvědčený ... ale žádný panel zatím není, takže zasep předbíhám.

[Daniel Kvasnička ml.]

To si myslim, ze je dobry napad. Kdyz se ti to povede udelat jako F/OSS projekt, tak to muzou vsichni hosteri se zajmem o Python ci Ruby postupne vylepsovat, proste klasickej open-source. Pak uz bude konkurencni boj zaviset hlavne na cenach a mnozstvi frameworku a to se nam klientm bude libit

[Daniel Kvasnička ml.]

No nevim, pokud se budes u TG ridit tim navodem na provoz pod mod_pythonem, tak by zadny SSH pristup nemel byt potreba. Nakopirovat, spravne napsat .htaccess. Jak to tak vypada, dam TG & mod_pythonu druhou sanci a zkusim to rozjet...

[botanicus]

Presne, presne! Mongrel ruluje!

[Daniel Kvasnička ml.]

No koukam do dokumentace TG, ze o mod_pythonu uz tam neco je -- do nedavna tohle byla docela slabina TurboGears. Priznam se, ze u nas ve firme bezi TurboGears proste jen na svem serveru...ani supervisord jsme nakonec nepouzili. Ale to na hostingu neni prijatelne reseni.

S Djangem to je myslim jednodussi. Myslim, ze .htaccess by nam mel stacit.

[disorder]

tak ako sa to podarilo s railsom? mne totiz zaboha nejde rozbehat cez fastcgi (fcgid na apache2), stale konci s error 500.

keby sa nejaka dobra dusa nasla co by ukazkovy virtualhost sem pastla :) dik

btw skusam to na debiane etch, rails 1.2.4 zo sida