I. Z tematem bez wstępu

Temat optymalizacji aplikacji webowych był już poruszany wiele razy, nie trudno w Google znaleźć setki jeśli nie tysiące stron dotyczących tego zagadnienia. Zaczynając od metod keszowania/buforowania skryptów, wykorzystania lub nie konkretnych funkcji/instrukcji, analizie zapytań SQL i ich odpowiednim modyfikacjom kończąc na testach wydajnościowych.To wszystko jest ważne - zmniejsza czas wykonywania skryptów, zwiększa wydajność aplikacji a docelowo sprawia iż strona klientowi (jakkolwiek go zwał - klient w postaci przeglądarki internauty czy tez w postaci naszego zleceniodawcy) otwiera się szybciej a serwer jest w stanie obsłużyć więcej żądań :)

Przyznaję - optymalizacja pisanej aplikacji jest na tyle skomplikowanym procesem iż jego realizacja (szczególnie w dużych projektach) często pozostaje na poziomie danego projektu. Mówiąć w skrócie - proces optymalizacji jest mało skalowalny.

Dużym problemem jest też czasochłonność optymalizowania, która tak naprawdę wydaje się nie do oszacowania a tym samym jest bardzo trudnym punktem w harmonogramie projektu (o ile wogóle się w nim znajduje). W dodatku powstają pytania o to czy da się w 100% zoptymalizować aplikację, czy zrobiliśmy naprawdę wszystko w tym kierunku, i na koniec czy nie odbije się to zbyt dużym kosztem pewnych funkcjonalności strony a tym samym zadowolenia klienta? No to pokolei...

II. Definicja vs życie

Ogólna definicja optymalizacji wg. Wikipedii jest taka: (źródło: http://pl.wikipedia.org/wiki/Optymalizacja)

"Optymalizacja - metoda wyznaczania najlepszego (optymalnego) rozwiązania (poszukiwanie ekstremum funkcji) z punktu widzenia określonego kryterium (wskaźnika) jakości (np. kosztu, drogi, wydajności)."

Innymi słowy, coś jest zoptymalizowane wtedy gdy zostało osiągnięte pewne z góry założone kryterium jakości. Natomiast spojrzenie z punktu widzenia programowania:

"W programowaniu komputerowym optymalizacja oznacza sposoby i metody poprawy kodu programu komputerowego by czas jego działania oraz wielkość pamięci potrzebnej do jego uruchomienia były jak najmniejsze."

Tu widać już podejście konkretne, liczy się minimalizacja czasu i pamięci a nie jak na początku poszukiwanie najlepszego rozwiązania. Przyznam, że choć pierwsza definicja jest mi nieco bliższa to obie pozostawiają pewien niedosyt. Dlaczego? Wyobraźmy sobie taką sytuację, w której klient zgłasza nam iż strona którą dla niego wykonaliśmy działa zbyt wolno. Co robimy ? Patrząc na obie definicje wyznaczamy, iż najlepszym rozwiązaniem z punktu widzenia realizacji założenia "szybkiego działania strony" (minimalizacja czasu i pamięci), gdzie kryterium będzie ilość stron które mogą zostać jednocześnie otworzone w ciągu 1s. będzie prezentacja serwisu jako statycznych stron HTML, których treści są automatycznie generowane (poprzez cron) np. co 10 min. Osiągamy świetny wynik, zadowoleni wysyłamy informację do klienta: "strona działa już szybciej". Ku naszemu zdziwieniu klient jest oburzony utratą pewnych funkcjonalności, chciał aby newsy, wyniki sondy, ostatnie posty na forum itp. pokazywały się na bieżąco a nie co 10min. Mówiąc wprost, content strony miał być nadal generowany dynamicznie.

Oczywiście sytuacja jest specjalnie przerysowana, ma na celu pokazanie braku w definicjach elementu "biznesowego", uzyskania pewnego kompromisu w dążeniu do celu, czyli wydajnieszego serwisu. Co powinniśmy zatem zrobić?

• Na bazie rozmów z klientem/uwag użytkowników, na tyle ile to możliwe zdefiniować cel - czyli co tak naprawdę mamy usprawnić, jakimi kosztami i przy jakich założeniach.
• Wyszukanie "wąskich gardeł" w działaniu aplikacji i wypracowanie pomysłów na ich zoptymalizowanie.
• Przedstawienie pomysłów klientowi, ich zalet, wad, kosztów, czasu na ich realizację, ewentualne ich korekty.
• Realizacja optymalizacji.
• Testy wydajnościowe/obciążeniowe i sprawdzenie czy zostały spełnione zamierzone założenia.
• Wdrożenie zmian w aplikacji.

Takie sześć punktów zawęża szerokie pojęcie optymalizacji serwisu do konkrektnych, realizowalnych w czasie zadań. Oczywiście podejść optymalizacyjnych może być więcej niż jedno, ważne by każde z nich zostało zamknięte przez osiągniecie danego celu.

III. Szacuneczek ?

Na początku artykułu wspomniałem o niemożliwości oszacowania procesu optymalizacji. Czy faktycznie tak jest?Tworząc nową aplikację nigdy do końca nie jesteśmy w stanie przewidzieć wszystkich problemów na które z pewnością się natkniemy, nie wiemy jakie strategiczne decyzje będziemy musieli podjąć by projekt zakończyć o czasie. Najczęściej też, większe projekty są podzielone na etapy prac (tzw. kamienie milowe) z których każdy może mieć nieco inną specyfikę i wpływ na pozostałe etapy. Zatem, nie możemy oszacować zoptymalizowania czegoś czego nie ma. Jeśli tego się podejmiemy najprawdopodobniej takie próby zakończą się fiaskiem i niepotrzebną stratą jakże cennego czasu. Pozostaje pytanie - kiedy wogóle można podjąć się procesu optymalizacji. Najprościej byłoby odpowiedzieć - wtedy gdy strona/aplikacja jest już w 100% wykonana, jak pewnie się domyślacie, jest to praktycznie nie możliwe do osiągnięcia. Weźmy pierwszy z brzegu przykład.

Realizacja projektu składającego się z 3 dużych etapów w ciągu 12 msc, przy czym po zakończeniu pierwszego z nich strona zostaje uruchomiona (jest online) i dostępna dla całego świata. Okazuje się, że po kilku dniach od uruchomienia, jej użytkownicy skarżą się na wolne ładowanie np. forum.
Czekamy z optymalizacją aż zostanie zamknięty ostatni etap? Przy takim podejściu najprawodpoboniej nie byłoby następnych etapów ;)
Optymalizacji podejmujemy się wtedy gdy został zamknięty pewien większy obszar funkcjonalności, dlatego też przy dzieleniu projektów na etapy warto ten element przewidzieć. Optymalizujemy też wtedy, gdy faktycznie istnieje potrzeba takiego działania a nie na zasadzie "kręcenia się w kółko", pisząc tą samą funkcję po raz 5ty, bo jest "nie wydajna".
Tak więc szacować z szacunkiem do optymalizowania - przede wszystkim z głową i w odpowiednich momentach życia projektu.

IV. Świadome optymalizowanie

Każdy programista wraz z coraz większym doświadczeniem jest bardziej świadom tego co pisze. Wie więcej na temat tego jakich funkcji w którym przypadku użyć, co zadziała szybciej, jakie konstrukcje kodu są wydajniejsze, co można a czego nie powinno się robić programując. Niestety tego nauczyć się nie da, wynika to po prostu z lat pracy, ilości napisanych aplikacji, przeczytanych książek itd. To tak jak w grach typu "Diablo", im więcej potworów w niej zabijesz, tym więcej punktów doświadczenia zdobywasz i jesteś silniejszy :)

Jest jeden (mój prywatny) sposób na to by móc chociaż w niewielkim procencie uniknąć pewnych błędów wydajnościowych pisząc aplikację. Mianowicie, wykorzystując jakieś funkcje (szczególnie nowe, lub takie których dotychczas nie używaliśmy) czytajmy w dokumentacji nie tylko to "co ona robi" i co "zwraca" ale także jak to robi oraz to co jest często między wierszami (np. często w komentarzach użytkowników, na innych stronach) - przypadki użycia.

Warto też pamiętać, że w wielu aplikacjach jest cała masa bezmyślnych rozwiązań i błędów, których poprawianie nic z optymalizacją wspólnego nie mają.