Adam Banaszkiewicz

Problem Przechowywanie raportów PHPMetrics z wielu projektów z przestrzeni kilku lat. Raporty takie są robione co miesiąc i zbierane w celach statystycznych. Zakładając statystyki projektu zbierane przez 3 lata, wychodzi na 36 raportów JSON. Mając kilkadziesiąt takich projektów liczba raportów dość znacznie rośnie. Średni raport bezpośrednio z PHPMetrics to 7 MB. Jeśli pominiemy spacje (pretty print) to raporty mają około 5 MB. 5 MB, razy 36 miesięcy, razy 50 projektów... 1800 raportów o wadze 9 GB! Głównym driverem które przyświecał rozwiązaniu problemu było to, że odczyt tych raportów będzie bardzo rzadki - średnio raz na miesiąc. Drugim driverem było to, że dane te będą odczytywane zawsze jako całość, nigdy partiami. Dodatkowo nigdy nie będziemy w nich nic wyszukiwać. Te dwa drivery pozwoliły zdecydować, że raporty te możemy swobodnie przechowywać na systemie plików serwera (lokalnie czy AWS S3 - bez różnicy). Rozwiązanie Zmniejszyć rozmiar plików maksymalnie, zostawiając tylko te dane, które faktycznie potrzebujemy. Krok 0: Usunięcie białych znaków To było najprostsze co można zrobić. Mając JSON wystarczy go sparsować i ponownie przekształcić do JSON. $result = json_encode(json_decode($source)); Przed: 9,3 MBPo: 5,8 MBZysk: 38% Krok 1: Usunięcie niepotrzebnych danych Z racji tego, że raport PHPMetrics zawiera wiele różnych danych, nie wszystkie dane potrzebowałem. Naturalnym było więc pozbycie się tych nadmiarowych danych z raportu. foreach ($data as $item) { if ($item['_type'] === 'Hal\\Metric\\ClassMetric') { $resultAssoc[$item['name']] = [ 'type' => 'class', 'lcom' => $item['lcom'], // ... ]; } } Przed: 5,8 MBPo: 889 kBZysk: 85% Krok 2: Zmiana kluczy na numeryczne W przypadku takich raportów bardzo dużo kluczy się powtarza, ponieważ każda klasa posiada te same metryki. Zmieniłem więc klucze na jednoliterowe. Na przykład volume na v, już sama ta zmiana dawała dużą optymalizację w przypadku 20 metryk per klasa, ale dało się zrobić jeszcze. Klucze w postaci ciągu znaków w JSON posiadają dodatkowe znaki w postaci double quote, ale liczba nie. foreach ($source as $key => $item) { $resultDigits[$key] = [ 0 => $item['type'], 1 => $item['lcom'], 2 => $item['lloc'], // ... ]; } Przed: 889 kBPo: 536 kBZysk: 40% Krok 3: Zamiana na CSV W przypadku JSON nie udało mi się już nic więcej wymyślić. To był maks tego formatu. Doszedłem do wniosku, że skoro tak to może warto spróbować poszukać innego formatu? Zaletą tego raportu jest to, że mamy tam praktycznie płaskie dane. Lista klas i interfejsów, oraz 20 metryk dla każdej klasy w postaci liczby. Najbardziej oczywistym formatem wydawał się tutaj CSV. Pierwsza linijka to nazwy wartości - już nawet w pełnej postaci a nie numerycznej - a następnie nazwa klasy i jej metryki po przecinku w kolejnych liniach. $csv = fopen(__DIR__.'/report.csv', 'wb'); // Headers fputcsv($csv, [ 'classname', 'type', 'lcom', // ... ]); // Data foreach ($resultAssoc as $classname => $entry) { if ($entry['type'] === 'class') { fputcsv($csv, [ $classname, 'c', $entry['lcom'], // ... ]); } } fclose($csv); Przed: 536 kBPo: 280 kBZysk: 48% Podsumowanie Zdaję sobie sprawę z tego, że proces ten mogłem przyspieszyć, migrując dane od razu z JSON do CSV. Każdy kolejny krok jednak wynikał z poprzedniego. Podobnie było z driverami, które w trakcie tego procesu wpływały na decyzyjność. W przypadku gdyby drivery wyglądały inaczej, albo dane nie były wystarczająco płaskie, zatrzymałbym proces na kroku 2. Pomijając krok 0, który jest dość oczywistym krokiem by nie marnować przestrzeni dyskowej, dzięki tym wszystkim transformacjom zmniejszyłem plik raportu średnio o 95%! Jest to niesamowity wynik jak na tak proste operacje. Pierwotnie 1800 raportów ważyło bagatela 9 GB! Po optymalizacji jest to już tylko 450 MB. W dobie wszechobecnej chmury i taniego S3 wydawałoby się, że możemy już przestać martwić się o przestrzeń dyskową. Jednak w przypadku dużego wolumenu może się okazać, że nawet 20% optymalizacja da redukcję zajmowanej przestrzeni o dziesiątki gigabajtów. W przypadku projektu dla którego wykonywałem optymalizację, 50 projektów to tylko MVP - w przyszłości liczba ta może wzrosnąć do setek, i w tedy z 9GB mielibyśmy dziesiątki, jak nie setki gigabajtów danych, które trzeba utrzymywać na serwerze. Czy warto? Taka optymalizacja zajęła mi może z pół godziny pracy. W przypadku oszczędności rzędu 95% myślę, że warto.

Bartosz Perek

Biography

Moje konto

Dokumenty

Kontakt