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.

Od jakiegoś czasu zastanawiam się, jak obecnie podejść do tworzenia oprogramowania dla urządzeń mobilnych. Częstym, jeżeli nie wyborem jest tworzenie aplikacji natywnych – czyli budowanych w oparciu o SDK danego producenta (w przypadku Androida  grupy producentów/urządzeń).
Wybór taki przypomina decyzje, jakie podejmowane były, i w sumie nadal są, w przypadku aplikacji na zwykłe komputery. Inaczej tworzymy aplikację na Windows & inaczej na Mac OS X, jeszcze inaczej na Linux’a (oczywiście to uproszczony pogląd).
Sytuację to ogromnie zmienił trend jakim stał się SaaS, czyli aplikacje dostępne 24h na dobę, w przeglądarce, dla dowolnej …

Witam!
Jakiś czas temu znajomy strasznie męczył mnie, by mu pomóc zareklamować się w Google. Gość ma konto AdWords, pokazał mi jak to funkcjonuje, i przyznam się, że z jako takim obyciem wśród aplikacji internetowych – przestraszyłem się! Chodziło mu o jedną prostą reklamę, no – może ambitniejszym zadaniem było to, że znajomy prowadzi firmę w Bielsku – i tylko tam chciał się reklamować.

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.

W sobotę 20 marca 2010 r. w krakowskich Przegorzałach odbędzie się konferencja Zimowy AgileTuning. Na spotkaniu zaplanowane są prezentacje i dyskusje dotyczące inżynierii oprogramowania, jak i o tematyce całkowicie dowolnej, prowadzone w małych grupach.
Na niezwykłą atmosferę wieczoru składa się obecność właściwych ludzi oraz dobór odpowiedniego miejsca sprzyjającego bezpośrednim i nieskrępowanym dyskusjom. Duża część uczestników przyjeżdża na specjalne zaproszenie organizatorów. Każdy z nich ma bogate i różnorodne doświadczenia.

Świetna – właśnie – prezentacja, polecam:

W poprzednim poście pisałem iż czas życia instancji aplikacji w kontenerze GAE jest bardzo ograniczony ? aplikacja ładowana jest w momencie zapytania ? pozostaje w pamięci przez krótki czas ? o ile nie nadejdzie kolejne zapytanie.
Przy małym ruchu powoduje to w praktyce ładowanie aplikacji dla każdego zapytania – używając np. Springframework powoduje to kilkunasto sekundowe opóźnienie w obsłudze zapytania ? co jest niedopuszczalne.
Jak na razie jedynym rozwiązaniem, choć nie jestem w 100% przekonany, iż można założyć, że kolejne zapytanie zostanie obsłużone przez tą samą instancję, a po drugie zjada to …

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ę …