Poprawa wydajności systemu to proces bardziej teoretyczny. Masz w głowie model, dodatkowo to co system robi i trochę teorii na temat co jest najbardziej zżera zasoby. Potem propozycja zmian do systemu oraz przewidywane korzyści jakie powinno to przynieść. Następnie wprowadzamy zmiany, obserwujemy zachowanie systemu w warunkach testowych. W końcu zbieranie dowodów które potwierdzają lub obalają teorię. Ta droga poprawiamy teorię i także w końcu poprawiamy działający system. Proste, skuteczne i małymi krokami poprawiające system.
Niestety, jeszcze nigdy nie udało mi się tego zrobić w praktyce. Jeżeli do optymalizacji wystarczyło by odpalić ten sam kod milion razy w pętli, było by to proste. Ale mamy do czynienia z dużą ilością danych, rozłożonych na wiele maszyn. Jeśli czytasz ten sam element milion razy w pętli, to po prostu będzie przechowywany w cach i test obciążenia nie powie Ci nic. Jeśli potrzebujesz realistyczne wyniki, test obciążenia musi symulować rzeczywistą duży zestaw danych, rzeczywistą mieszaninę odczytów i zapisów, rzeczywistą ilość żądań w czasie, i tak dalej. To bywa trudne.
Jest to na tyle trudne, że po pierwsze trzeba wiedzieć jakie są wzorce obciążenia, potem trzeba znaleźć sposób aby je symulować. Na początek, watro zacząć od czytania logów. Plusem tego jest to że są to rzeczywiste dane, minus że to są tylko dane odczytu. Napisanie na tej podstawie symulacji jest trudniejsze, ponieważ trzeba uwzględnić zasady logiki biznesowej (np.sekwencyjny przepływ pracy musi najpierw zaktualizować A, następnie zaktualizować B , a następnie zaktualizować C ) i radzić sobie ze zmianami, które mogą zdarzyć się tylko raz ( jeśli zapis zmienia stan z D do E , nie można zmienić z D E później ponownie w teście , jak już jesteś w E ). Pamiętać należy o prawach dostępu, spr logów, sesji i masie innych rzeczy.
Jeszcze trudniejsze zadanie, jeśli chcesz przetestować zestaw danych, który jest większy niż ten rzeczywisty ( tak aby można było dowiedzieć się, co się stanie, gdy podwoi się liczba użytkowników i przygotować się do tego wydarzenia ). Teraz trzeba wypracować właściwości statystyczne zbioru danych (zastanowić się jak użytkownicy wpływają na siebie i jak to będzie się zmieniać wraz ze wzrostem ich liczby) i wygenerować syntetyczny zestaw danych dla tych parametrów. W tej chwili znajdujemy się w jakiejś wirtualnej rzeczywistości, coraz dalej od tego co naprawdę dzieje się z aplikacją.
W praktyce rzadko działa to w ten sposób. Mamy szczęście, jeśli czasem możemy uruchomić stary kod i nowy side- by-side potem obserwować, i starać się wyciągać wnioski. Często zdarza się, że nawet to nie jest możliwe. Zazwyczaj po prostu bierzesz kawałek kodu, a potem albo go wdrażasz albo wyrzucasz, zależnie od tego czy przyniósł więcej pożytku czy złego. Podejście to jest głęboko niesatysfakcjonujące dla umysłów ścisłych, nie mniej jednak jako tako działa.