W poprzednim poście napisałem o problemach z niebywale dużym zużyciem CPU podczas operacji zapisu do datastore Google App Engine. Od kilku dni zastanawiałem się, jak zaradzić temu problemowi – rozwiązanie znalazłem i zaimplementowałem dosłownie przed chwileczką.
Struktura rekordu z danymi zapisywany podczas zapytania do API była dość rozgałęziona – coś w stylu drzewa o 3 poziomach na drugim poziomie około 3-4 rekordów – na kolnym po około 2-3 dla każdego elementu z poziomu wyżej. Co ważne, żaden z elementów poniżej głównego rekordu nie był używany w zapytaniach.

Bawiąc się z małym projektem aplikacji dla Google App Engine doszedłem do różnych interesujących wniosków.
Jednym z ciekawszych jest użycie CPU – i bynajmniej nie CPU generowanego przez kod samej aplikacji – a CPU użyte przez datastore (jak wywnioskować można z panelu administracyjnego – około 90% użycia CPU jest generowane przez API Calls CPU).
Konsumowane jest ono w dość dużym tempie. Moja przykładowa aplikacja zapisuje pewne dane przy zapytaniu przesłanym do API. Zapytanie takie może zapisać/uaktualnić około (oszacowane manualnie na podstawie definicji modelu klas danych) 20 wierszy, musi załadować również dwa troszkę …

Po kilku tygodniach zabawy z GAE zauważyć można masę problemów. Jedną z bardzo denerwujących przypadłości Clouda w wykonaniu Google jest problem z Datastore, do którego proste zapytanie przekracza dozwolony czas odpowiedzi.
Logi prostej aplikacji po pewnym czasie pełne są informacji o DatastoreTimeoutException.

Jeżeli w Google App Engine próbujesz wysłać wiadomość e-mail i w logu widzisz błąd:

Illegal Arguments java.lang.IllegalArgumentException: Unauthorized Sender

upewnij się, czy aby na pewno jaki SENDER ustawione jest konto, które jest zarejestrowane jako jeden z administratorów Twojej aplikacji.
GAE pozwala wysyłać maile jedynie z kont zarejestrowanych jako administrator aplikacji. Możesz dodać dowolną ilość takich kont do swojej aplikacji w zakładce “Developers” w panelu administracyjnym.

Ostatnio odkryłem bardzo przydatne ustawienie dla PersistentManager’a. Miałem klasę A, jednym z pól klasy A była lista obiektów typu B. Obiekt B również posiadał pole będące listą obiektów typu C.
Tworzyły one pewną całość, listy były niewielkie, maksymalnie kilka elementów, więc chciałem je załadować kompletnie ładując obiekt typu A.