Google App Engine stracił na kilka godzin silnik

Jak donoszą agencje i strona statusów, GAE zanotowało wczoraj kilkugodzinne problemy z działaniem serwerów aplikacyjnych, memcache i bazy danych Datastore. Takie jednorazowe problemy zdarzają się każdemu, ale w przypadku Google App Engine jest to w ostatnim czasie dłuższa seria okresowych problemów, które tu i tam pojawiają się co kilka dni.

Nie wróży to najlepiej przyszłemu rozwojowi usługi w aspekcie Enterprise, gdyż dla dużych firm pewność działania to aspekt podstawowy. Choć mniejsi twórcy witryn prawdopodobnie nie będą szukali nowego domu (GAE to wiele zalet dla startupów), działy IT z administratorami w dużych firmach nadal nie mają się o co martwić w kwestii rozwiązań cloud computing przez kolejne miesiące i przeciwnicy adaptacji chmur w firmach dostają kolejne argumenty.

Google App Engine po darmowych obiadkach

Ponad tydzień temu, czyli 22 czerwca 2009 (z miesięcznym poślizgiem względem początkowo wskazywanej daty) znacznie ograniczono bezpłatne limity dwóch parametrów systemu:

• dzienny czas procesora z 46 do 6,5 godziny,
• dzienny limit transferu danych do i z aplikacji z 10GB do 1GB.

Pozostałe limity nie zmieniły się, ale prezentowane dwa uległy ograniczeniu o ponad 80-90%. Wiele osób pomyśli: "No tak, zwiedli ogromnymi wartościami, a teraz ograniczają na potęgę!". Może jest w tym ziarno prawdy, bo Google nie jest instytucją charytatywną (szczególnie w czasach kryzysu), ale bądźmy szczerzy - to oryginalne wartości były wzięte z kosmosu! Policzmy ile do 22 czerwca Google mogło dać jednemu programiście miesięcznie (wartości mnożone przez 10 aplikacji) całkowicie gratis:

• 10 x 30 dni x 10GB = 3TB transferu miesięcznie,
• 10 x 46h = prawie 20 dostępnych procesorów do wykorzystania miesięcznie,
• 10 x 150 MB + 10 x 500 MB = 6,5 GB przestrzeni statyczno-dynamicznej.

 Patrząc na te wartości oferowane bezpłatnie można dojść do wniosku, że z komercyjnego punktu widzenia Google "błądziło w chmurach" ze swoim rozwiązaniem chumrowym i niedawno zeszło na ziemię. Oczywiście obie wspomniane wartości można obecnie dokupić, ale czy nadal możliwe jest utrzymanie średniej witryny w bezpłatnym limicie?

Okazuje się, że tak, choć trzeba zacząć bardziej kombinować, jeśli witryna jest złożona lub ma więcej niż kilka tysięcy stałych użytkowników.

Sposoby na oszczędzenie kilku cykli procesora

Kilka wskazówek pozwalających skutecznie ograniczyć liczbę cykli procesora:

• skorzystaj z Jinja2 do generowania szablonów zamiast standardowych szablonów Django (Jinja2 jest podobna do szablonół Django, co zmniejsza czas nauki),
• przyspiesz szablony Jinja2 jeszcze bardziej, kompilując je do kodu Pythona przed umieszczeniem na GAE - kod,
• korzystaj z wersji multi poleceń dla Datastore i Memcache - pozwalają one pobrać w tym samym czasie kilka elementów, a także zapisywać je równolegle,
• obejrzyj prezentację Breta Slatkina na temat sposobów ograniczania czasu pakowania/rozpakowania długich list (używane w relacjach wiele do wielu), korzystając ze sztuczek z hierarchią kluczy,
• jeśli masz obiekty z dużą ilością danych, ale przez większość czasu korzystasz tylko z kilku, zastosuj dwa obiekty (szczegóły niech będa zapisane jako dziecko podstawowych danych) - oszczędzisz na serializacji i ilości pobrań danych (pamiętaj, że określanie kolumn do pobrania w Datastore nie ma praktycznego znaczenia),
• jeśli możesz coś umieścić statycznie i tak wczytywać, zrób to - przykładem może być kompresja CSS i JS, której nie należy robić w locie, nawet jeśli używasz przy tym memcache, bo to czysta strata zasobów),
• jeśli możesz, nie korzystaj z plików ZIP dla kodu elementów witryny odwiedzanych najczęściej, a jeśli limit na to pozwoli, w ogóle nie stosuj plików ZIP z kodem,
• w miarę możliwości stosuj paginację z rozwiązaniem z zakładką (ewentualnie zakładkowanie po dacie) zamiast pobierać 1000 wyników i je paginować (ponownie czas deserializacji),
• gdy nie potrzebujesz całych obiektów, a tylko ich klucze, użyj dostępnej od niedawna składni __key__,
• jeśli nie potrzebujesz indeksów dla niektórych pojedynczych właściwości, wyłącz ich tworzenie właściwością indexed ustawioną na false,
• tego chyba nie trzeba powtarzać: memcache i jeszcze raz memcache dla każdych buforowalnych, a intensywnych obliczeniowo działań.

Kilka wskazówek dotyczących ograniczenia ilości przesyłanych danych:

• w pliku app.yaml ustaw domyślny czas aktualności plików statycznych na około rok w przód (default_expiration: "365d"), by ograniczyć liczbę pobrań plików,
• skorzystaj z łączenia i kompresji plików JS i CSS, np. z systemu MediaGenerator z App Engine Patch,
• jeśli używasz bibliotek takich jak jQuery, Dojo lub Prototype, skorzystaj z możliwości odciążenia własnego konta przez wczytywanie bibliotek z serwerów Google,
• użyj rozwiązań takich jak Smush It (maksymalna kompresja obrazów) oraz spriteów CSS (przykład), by zminimalizować liczbę żądań i ilość danych,
• stosuj możliwie zwięzły kod HTML (używając intensowniej CSS i zewnętrznego JavaScript),
• jeśli masz taką możliwość, zamień przysłanie danych ajaksowych z XML na JSON.

Większość prezentowanych rozwiązań powinna być znana każdej osobie pracującej nad portalami o dużym nateżeniu ruchu. W przypadku Google App engine przydaje się ona także do wyciągnięcia jak najwięcej z darmowego limitu. Nawet pomomo wspomnianych na początku ograniczeń 5 milionów wyświetleń stron miesięcznie całkowicie gratis nadal stoi otworem!

Przenosiny z GAE do Bloggera

Jak zapewne zauważyliście, witryna dotycząca portfolio przeszła na Google Sites, a blog na Bloggera. Większość postów bloga jest przeniesiona i odpowiednio przekierowywana, ale niektóre z bardzo nieaktualnych wpisów zostały usunięte. Niestety, komentarzy nie przeniosłem, bo nie wiem jak, za co najmocniej przepraszam.

Przenosiny są spowodowane jednym z etapów czyszczenia i konsolidacji moich projektów i stron. Ponieważ projektu bloga na GAE nie zamierzam w przewidywalnej przyszłości rozwijać (był projektem testowym i zabawą z GAE), postanowiłem przenieść treść tam, gdzie tworzenie kodu nie jest potrzebne, a pozostanie w danym miejscu spore.

Długi brak wpisów i...

Oj, długo nie było nowych wpisów, ale mam coś na swoje usprawiedliwienie. Byłem zajęty tworzeniem między innymi artykułu wprowadzającego do Django dla webhosting.pl. Mogę dodać, że nie będzie to jedyny akcent Djangowy w tym internetowym magazynie w najbliższym czasie.

Jaiku.com używa Django

Kilka dni temu serwisy branżowe obiegła informacja, że Google udostępniło kod Jaiku.com i zaprzestało jego rozwoju jako własnej aplikacji, oferując całość jako JaikuEngine na zasadach open source. Wspomniano w artykułach, że nowa wersja działa na Google App Engine, ale zapomniano wspomnieć, że to aplikacja napisana w Django, stosująca helper dla GAE. Dla mnie Jaiku.com jako kod Twittera nie jest szczególnie interesujące, ale analiza kodu łączącego GAE+Django pisana przez pracowników Google może być ciekawą lekturą (mam nadzieję zobaczyć tam wydajne wykorzystanie GAE). Kod aplikacji znajduje się pod adresem http://code.google.com/p/jaikuengine.