Z czasem każda aplikacja, no prawie każda – przynajmniej ta zauważona, zetknie się z problemem wydajności.
Od kilku tygodni walczę z poprawą wydajności pewnej aplikacji, zbudowanej w oparciu o Springframework, Hibernate i MySQL. Oto kilka pomysłów co możesz zrobić:

Włącz logowanie długich zapytań (long query log). Maksymalny czas wykonania zapytania ustaw dość agresywnie. Przynajmniej 3-4 sekundy – wszystko powyżej tego czasu będzie logowane. Zgromadzi to dość dużą ilość informacji – ale z pewnością przydadzą się one.
Do analizy logu możesz użyć narzędzia mysqlsla – po prostu rewelacja, wyciągnie te zapytania, które zajmują naprawdę …

W pewnym momencie rozwoju aplikacji najpoważniejszym wyzwaniem staje się zapewnienie wydajności. Przy wzroście ilości użytkowników wzrasta obciążenie systemu. Wzrasta również ilość przechowywanych danych i operacje na tych samych tabelach zajmują znacznie więcej czasu niż dotychczas.
Często trudno jest ocenić w którym miejscu aplikacji tracimy najwięcej, dodatkowo takich miejsc jest wiele i trudno wybrać, które fragmenty kodu optymalizować najpierw, aby uzyskać jak najwięcej.

Często pisząc krótkie “spike’i” (dla nie wtajemniczonych mianem spike określa się testowe/demonstracyjne aplikacje, lub ich zmodyfikowane fragmenty) potrzebujemy gdzieś zapisać lub przesłać obiekt Javy w formacie XML’a. Znajdziemy całą masę rozwiązań wspomagających to zadanie, jednak gdy zależy nam na czasie, niekiedy najprostsze rozwiązania są najlepsze.

Zanim zdecydujesz się na Google App Engine warto wiedzieć o pewnych przypadłościach i zastosowanych rozwiązaniach.

[-] Zapytania do Datastore mogą zwrócić jedynie do 1000 rekordów, zespół GAE pracuje nad propozycją kursora, który będzie pozwalał na iteracje po większej ilości danych.
[--] Duże limitacje GQL – w sortowaniu oraz użyciu operatorów. Szczegóły można przeczytać tutaj.
[---] Znaczne zużycie API CPU dla zapisu i odczytu danych z Datastore, zwłaszcza gdy ich hierarchia jest dość głęboka (więcej na ten temat w moim poprzednim poście – i o rozwiązaniu używając pola Serializowalnego).
[-] Długi czas tworzenia indeksów – …

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.

Ech. Nie jest łatwo zaprzyjaźnić się z GAE. Ciągle jakieś schody…
Przed momentem odkryłem problem z dostępem za pomocą refleksji do java.util.TimeZone, chcąc wyświetlić listę stref czasowych.
Wszystko zaczęło się niewinnie, od atrybutu modelu, zawierającego przefiltrowane listy:

Dzisiaj postanowiłem udostępnić kod źródłowy aplikacji FinPlan.pl publicznie. Do tego na zasadach licencji Apache 2.0.
Dość długo nosiłem się z takim zamiarem, dziś w końcu znalazłem czas by go urzeczywistnić.
Co to jest FinPlan.pl
Samą aplikację można zobaczyć pod adresem http://www.finplan.pl. Serwis pozwala na przeanalizowanie swojej obecnej sytuacji finansowej oraz zaplanowanie oszczędności, tak by ułatwić osiągnięcie przyszłych celów finansowych. Opcjonalna rejestracja w serwisie pozwoli te plany weryfikować i dostosowywać do bieżącej sytuacji – zarówno zawodowej jak i ekonomicznej. Na łamach serwisu mogą być udostępniane spersonalizowane …

Z góry zaznaczam, że specjalnym sympatykiem JSR1 ani Jackrabbit’a nie jestem, i póki co dwa razy zastanowił się bym, czy użyć go w produkcyjnym systemie. Wydaje mi się, że nie jest to technologia wystarczająco dojrzała, w internecie można natrafić na informacje od wielu osób skarżących się na problemy przeróżnej natury, od integracji z innymi narzędziami poprzez skalowalność aż po niełatwy backup. Lecz czasem coś po prostu jest Ci “dane”, więc trzeba się z tym oswoić i starać się podejść do tego z najlepszej strony.
Pierwszym problemem, jaki musiałem rozwiązać, była integracja …