Szukam kwantyfikacji obciążenia wydajności monitorowania NewRelic w python django app

Question

Pracuję nad dużą aplikacją Django (v1.5.1), która zawiera wiele serwerów aplikacji, serwerów MySQL itp. Przed wprowadzeniem NewRelic na wszystkie serwery chcę aby zorientować się, jakiego rodzaju koszty poniosę za transakcję.

Jeśli to możliwe, chciałbym nawet rozróżnić śledzenie aplikacji od monitorowania serwera, które byłoby idealne.

Czy ktoś wie o ogólnie akceptowanych numerach? Być może witryna prowadząca tego rodzaju dochodzenie lub kroki, abyśmy mogli przeprowadzić dochodzenie na własną rękę.

Answer 1

Dla agenta Python i monitorowania aplikacji internetowej Django, obciążenie na żądanie zależy od tego, ile funkcji jest wykonywanych w ramach określonego żądania, które są oprzyrządowane. Wynika to z faktu, że pełne profilowanie nie jest wykonywane. Zamiast tego są oprzyrządowane tylko określone funkcje. Jest to zatem tylko narzut związany z tym, że dla tego jednego wywołania funkcji wykonywane jest opakowanie, a nie zagnieżdżone, chyba że te funkcje zagnieżdżone były z kolei instrumentami.

Określonymi funkcjami, które są oprzyrządowane w Django, są funkcje oprogramowania pośredniego i obsługi widoku, a także renderowanie szablonu i funkcja w szablonowym rendererze, który dotyczy każdego bloku szablonu. W odróżnieniu od samego Django, posiadasz oprzyrządowanie na niskim poziomie funkcji modułu klienta bazy danych do wykonywania kwerendy, plus memcache i zewnętrzne strony internetowe itp.

Oznacza to, że jeśli dla konkretnego żądania internetowego wykonanie przeszło tylko przez 100 funkcji przyrządu , to jest tylko wykonanie tych, które ponoszą dodatkowy koszt. Jeśli zamiast tego Twoja przeglądarka wykona dużą liczbę różnych zapytań do bazy danych lub jeśli wyrenderujesz bardzo skomplikowany szablon, liczba przyjętych funkcji może być o wiele większa, a dodatkowe obciążenie związane z tym żądaniem internetowym będzie większe. To powiedziawszy, jeśli twoja funkcja przeglądania robi więcej pracy, to zazwyczaj ma już dłuższy czas odpowiedzi niż mniej skomplikowany.

Innymi słowy, narzut na żądanie nie jest ustalony i zależy od tego, ile pracy jest wykonywanych, a dokładniej od tego, ile funkcji oprzyrządowanych jest wywoływanych. W związku z tym nie jest możliwe ilościowe określenie rzeczy i podanie stałej liczby na żądanie dla kosztów ogólnych.

To wszystko powiedziane, będzie trochę narzut, a ogólny cel docelowy jest około 5%.

Generalnie rzecz biorąc, jest to, że wgląd uzyskany dzięki pomiarom wydajności oznacza, że ​​dla większości klientów zwykle istnieją całkiem proste ulepszenia, które można znaleźć niemal natychmiast. Po wprowadzeniu takich zmian czasy reakcji mogą dość szybko zostać obniżone poniżej poziomu sprzed rozpoczęcia monitorowania, więc kończysz przed wyprzedzeniem miejsca, w którym zaczynałeś, gdy nie masz monitorowania. Przy dalszym kopaniu i dostrajaniu ulepszenia mogą być jeszcze bardziej dramatyczne. Zwróć uwagę na pewien aspekt dostarczanych parametrów wydajności, możesz także lepiej dostroić serwer WSGI i być może lepiej wykorzystać go i zmniejszyć liczbę hostów, a tym samym zmniejszyć koszty hostingu.