jAbLoK

Podle článku Google App Engine Announces Pricing Plan, APIs, Open Access na ReadWriteWeb se očekává, že Google dnes na Google I/O konferenci oznámí několik novinek ohledně AppEngine (viz též starší zmínka na Jabloku):

Služba bude v základní bezplatné verzi přístupná všem zájemcům bez čekání (rozdíl oproti současnému uzavřenému byť zvolná narůstajícímu okruhu testerů).

Limity základní verze zůstavají na 500 MB persistentně uložených dat a přenosové kapacitě specifikované jako “dostatečná pro 5 milionů pageviews měsíčně”. Do konce roku se objeví možnost přikoupit dodatečné zdroje, ReadWriteWeb uvádí následující předběžný ceník:

• $0.10 - $0.12 per CPU core-hour
• $0.15 - $0.18 per GB-month of storage
• $0.11 - $0.13 per GB outgoing bandwidth
• $0.09 - $0.11 per GB incoming bandwidth

Zmínka o placení za CPU mi není příliš jasná vzhledem k tomu, že základní verze žádné omezení vlastní výpočetní kapacity nezmiňuje. Uvidíme.

Posledním zajímavým rozšířením jsou dvě nová API - pro manipulaci s obrázky a především - pro kešování (absence kešování byla vzhledem k přirozeným omezením odezvy distribuované databáze nepříjemná).

Jinak celý tento článek je pro Javisty off-topic, jiné jazyky než Python zatím Google v AppEngine podporovat nehodlá

V příspěvcích o eBay a AppEngine jsem zmiňoval, že používání HTTP sessions nejde úplně dobře dohromady s požadavky na horizontální škálovatelnost.

Používat sessions je lákavé, umožňují programátora odstínit od bezstavovosti HTTP protokolu. Na druhou stranu, jakmile aplikace přeroste možnosti jednoho stroje, tak začnou komplikovat život, když chcete provozovat load balancing přes cluster aplikačních serverů: duplikovat je napříč servery je patrný overhead, sticky sessions neméně zjevně snižují efektivitu load balanceru.

Jinými slovy: odstiňovat programátory od bezstavovosti HTTP vlastně nemusí být až tak dobrý nápad.

Nejmenší zlo je nakonec sessions ukládat do nějakého relativně persistentního úložiště vně aplikačního serveru - zpoždění sítě a potřebné serializace a deserializace sice mírně brzdí, ale aspoň neovlivňují zbytek clusteru.

Tedy, nejmenší zlo za předpokladu, že sessions používáme.

K čemu vůbec sessions?

K čemu se vlastně HTTP sessions používají? Napadá mě:

• udržování identity uživatele + kešování osobních dat
• udržování stavu uživatelského rozhraní (JSF, dívám se vaším směrem…)
• nákupní košík
• kešování informací potřebných pro stránkování dat (opravdu to někdo radí)
• a další - příklady uvítám v komentářích

Pokud mne laskaví čtenáři v komentářích nedoplní něčím nečekaným, dalo by se používání sessions rozdělit do následujících částečně se překrývajících kategorií:

• autentifikace
• kešování
• antipatterny

Antipatterny

Nevýhody používání sessions pro ukládání aktuální pozice při stránkování dat pitvali už před necelými deseti lety členové Usenetové skupiny cz.net.internet (a po nich i před nimi jistě spousta dalších).

Z nějakých záhadných důvodů se jako typický důvod pro sessions uvádí nákupní košík. K tomu mě nenapadá jiný důvod než že jej kdysi kdosi použil v nějakém tutorialu na sessions a od té doby to každý papouškuje: košík by měl být odolný proti výpadku aplikačního serveru, navíc se neaktualizuje ani nezobrazuje tak často, aby musel být nutně kešován - zkrátka i když jeho trvání obvykle nebývá dlouhé, je velmi záhodne jej ukládat do databáze.

Jako antipattern mi osobně přijde i přístup JSF - a to ať už se stav stromu komponent ukládá do session nebo na klientovi. Ale vzhledem k popularitě tohoto frameworku mi asi něco uniká. Doufám.

Kešování

Session může působit dojmem jako bezva struktura pro kešování, aspoň dokud si člověk neuvědomí nevýhody popsané více. A dokud nezačne kešovat data, která mohou být modifikovány v rámci jiných sessions. A když si nevýhody uvědomí, tak nejspíš sáhne po něčem, co bylo pro kešování navrženo a uvedenými nedostatky ve škálovatelnosti netrpí. Třeba memcached. A těch pár zlomků sekundy na zpoždění sítě a (de)serializaci holt obětuje.

Autentifikace

Session se asi nejčastěji používá pro udržování informací o přihlášeném uživateli. Fakticky se ale jedná o speciální případ kešování popsaného níže - pokud víme, že o uživateli potřebujeme znát skutečné jméno, adresu, a základní preference, prostě si je můžeme nasypat do memcached pod těžkouhodnutelným klíčem generovaným podobným mechanismem jako session.

A pokud od autentifikace očekáváme jen ověření identity uživatele, můžeme prostě do cookie nastavit přímo identifikátor uživatele, jen digitálně podepsaný nebo ještě lépe zašifrovaný. Pokud autentifikační služba není izolována na vlastním clusteru, symetrické šifrování by mělo bohatě postačí. Na druhou stranu se v tomto případě se musíme postarat o pár praktických záležitostí okolo správy klíčů a deploymentu.

Obrázek: Možnosti ověření a interpretace authentication tokenu - kešování a kryptografie

Kryptohrátky jsou zbytečným overheadem v tradični aplikaci, kdy většina požadavků je zasílána za účelem vykreslení celé stránky - typicky vždy budete muset znovu zobrazit jméno uživatele a podobně, tudíž si hrábnutí do cache neušetříte.

Naopak pokud si mantru “udržovat stavu na klientovi” vykládáte po vzoru GMailu tak, že webová aplikace se sestává z pár HTML stránek, kterou uživatel porůznu aktualizuje AJAXem, pak samozřejmě může kryptografické ověřování a interpretace session tokenu přispět ještě o trošku k lepší odezvě a škálovatelnosti.

Pokud někomu ze čtenářů zbudou síly něco napsat, zajímalo by mě:

• k čemu výše neuvedenému používáte sessions?
• zkoušeli jste v praxi vytvořit bez použití sessions netriviální víceuživatelskou webovou aplikaci?
• a pro znalce a fanoušky Java Server Faces - máte po přečtení výše uvedeného dojem, že mi ohledně této technologie něco zásadního uniká?

Odkazy

• Gojko Adzic: Put the webserver on diet to increase scalability
• Cal Henderson: Scalable web architectures: Common patterns & approaches

Před pár dny Google na svém blogu oznámil spuštění automatického překladače mezi češtinou a opravdu velkou spoustou jazyků.

Takže pokud vás zajímá, co se tak zrovna zajímavého děje v Číně aniž byste disponovali patřičnými jazykovými znalostmi, můžete s trochou fantazie sledovat český překlad čínských Google News. Uznávám, že zpráva Andy Lau Shi Zhu Liqian vztahy s měkkou sílu postupně nejistý dotýkající se patrně čínské pop-kultury už vyznívá trochu surrealisticky, na druhou stranu na podobné výplody je patrně zvyklý mnohý uživatel dosavadních automatických překladačů mezi češtinou a angličtinou.

Teď ještě, aby to umělo překládat i feedy.

Mimochodem, japonština se i podle úrovně překladu zdá být znatelně jednodušším jazykem.

… se jmenuje článek od Joela Spolskeho, kde autor vysvětluje základní myšlenku Map/Reduce (tedy převést problém na paralelizovatelné zpracovávání seznamů) na JavaScriptu.

Lispu neznaje, první odpověď, která mě na otázku v nadpisu napadla, byla: no jo, perl

Javu samotnou hanět nezačnu ani náhodou, nicméně na Joelově stížnosti na “Java-only” vzdělávání něco bude.