Logowanie JSON Wpływ na wydajność

Widzę coraz więcej artykułów o logowaniu w JSON. Możesz go również znaleźć na blogu NodeJS. Dlaczego wszyscy tak bardzo to lubią? Widzę tylko więcej operacji biorących udział:

• Tworzonych jest kilka nowych obiektów.
• Obiekty strunizujące, które obejmują obliczanie długości łańcucha lub przydziały wielu ciągów.
• GCing wszystkie bzdury, które zostały utworzone.

Czy jest jakiś test wydajności podczas używania rejestrowania JSON i regularnego rejestrowania ciągów? Czy ludzie używają JSON (do logowania) w projektach korporacyjnych?

Rejestrowanie JSON umożliwia programową analizę pliku dziennika, nawet jeśli format zmienił się w czasie .

Dobrym przykładem są dzienniki Apache. Domyślnie Apache używa commonformatu dla access.log:

"%h %l %u %t \"%r\" %>s %b"

Załóżmy, że utworzono analizator składni offline, który pobiera jeden z tych plików dziennika i oblicza z niego niektóre statystyki.

W pewnym momencie wprowadzasz subdomeny do swojej aplikacji i dołączasz je virtual_hostdo swoich logów (abyś mógł debugować, jeśli pojawią się problemy z jedną z subdomen):

"%v %h %l %u %t \"%r\" %>s %b"

Twój parser nie korzysta z virtual_hosts, ale nadal musisz go dostosować, aby:

• zaakceptuj nowy format dziennika (zwróć uwagę %vna nagłówek formatu dziennika)
• nadal obsługuje stary format dziennika (dla starszych plików dziennika)

Ale jeśli zalogujesz się w JSON , twój parser nawet nie zauważy dodanego pola i może z powodzeniem parsować zarówno nowe, jak i stare dzienniki. A jakiś inny parser może skorzystać z dodanych pól, jeśli istnieją .

I oczywiście dla ciebie parsowanie JSON jest łatwiejsze niż pisanie w regexpscelu parsowania dzienników ciągów.

Jeśli komputer działa tak blisko swoich granic, że takie problemy naprawdę miałyby znaczenie, najprawdopodobniej masz poważniejsze problemy. Chociaż mogą występować wyjątkowe sytuacje, w których robi to różnicę, wiele aplikacji (być może większość) działa na komputerach, dla których różnica, jeśli logujesz JSON, zwykły tekst lub rekordy do bazy danych, nie ma żadnego znaczenia. Obiekty, ciągi znaków i inne konwersje muszą być wykonane w większości przypadków (chyba że logujesz surowy plik binarny?), Być może go nie zobaczysz, ponieważ używasz domyślnych klas, które obsługują go w tle (np. Jeśli piszesz do bazy danych).

Jeśli potrzebujesz do tego oceny wydajności, musisz wykonać je samodzielnie na komputerze, na którym chcesz uruchomić kod, oraz w środowisku programistycznym, z którego korzystasz na co dzień. Jeśli istnieje duże obciążenie lub w ogóle zależy od wielu rzeczy. Jeśli na przykład piszesz witrynę w Ruby on Rails, twoje dane w większości przypadków są skrótem, więc konwersja do JSON kosztuje Cię prawie nic, ponieważ wewnętrzna reprezentacja nie jest tak daleko od tego, co chcesz napisać (i jest to typowe aby kod Railsów cały czas krążył wokół takich obiektów i struktur danych).

Korzyści znów zależą od twoich narzędzi. Jeśli masz bibliotekę JSON wbudowaną w swoje biblioteki, możesz łatwo ją przeczytać i wyświetlić w jakiejś formie. Ponownie jako przykład: Zakładając, że masz interfejs administratora swojej witryny i chcesz pokazać pewne informacje rejestrowania przechowywane w JSON, możesz to zrobić w niektórych przypadkach, czytając i wyświetlając jako HTML w Ruby w jednym wierszu kodu.