[Zalazdi]

Mirki, mam małe pytanie. Mam dość sporo obciążoną stronę (dogemonitor.com). Przy większym ruchu (60-100 online) strona potrafi trochę "przymulić". Muszę wykonywać sporo operacji po stronie PHP tak czy inaczej, tego nie obejdę (chyba, że przepisując stronę na inny język - aka Node.JS, które by się bardziej sprawdziło, ale to dosyć kłopotliwe).

I czy istnieje jakieś narzędzie, gdzie wcisnę sobie w kod microtime() czy coś podobnego, na koniec wykonywania skryptu czasy się zapisują i później mam dostęp do średniej etc.

W tym problem, że nie chcę dodatkowo obciążać tym bazy danych. Potrzebuję, żeby był to jakiś program, który może zapisywać je sobie w pamięci RAM (tego mi na serwerze akurat nie brakuje) i dostęp będę miał przez SSH.

Any ideas?

#programowanie #php #debugowanie

[m.....i]

@Zalazdi: "zainstaluj" sobie cloudflare. Zewnętrznie mierzy szybkość ładowania no i ma kilka funkcji cache. :]

[Zalazdi]

@mahitaji_anarudi: W tym rzecz, ze zewnętrzny czas ładowania strony za wiele mi w tym nie pomoże. Strona to HTML + JS + CSS (front) + 3 pliki PHP jako backend. I w samym PHP chcę profilować, tak, że później mam dane typu:

"Pobranie z bazy - 100ms"

"Parsowanie danych - 200ms"

"Zapis do cache - 5ms"

"Pętla foreach - 250ms"

Oczywiście "breakpointy' (czy jak to nazwać) sam sobie wpiszę, z tym

[m.....t]

@Zalazdi: Xdebug profiler

[Zalazdi]

@matiit: A on potrafi profilować wszystkie żądania do strony, czy tylko te "debug"?

[f.....x]

@Zalazdi: ty masz zrobione to tak ,że przy każdym wejściu na stronę pobierasz dane z giełd? Jeśli tak to proponuje z crona pobierać informacje nawet co minute i wrzucać do bazy. Trudno pomóc...w zasadzie nie napisałeś nic na temat tego jak masz to zorganizowane od strony technicznej

[MacDada]

@Zalazdi: Xdebug obsłuży wszystko, ale też obciąża dodatkowo każdy request.

Dopisuj sobie logi, później wyciągaj z nich dane i licz.

Gdzie pisać logi? Najprościej do pliku na dysku, ale szybszą metodą jest walić do Memcache'a (działa w RAMie). Nie są to „istotne” dane, więc ewentualny restart nie będzie bolesny.

[Zalazdi]

@fotexxx: Nie, oczywiście że nie. Pobieram co minutę wszystkie nowe "ordery" (zakończone transakcje) i zapisuje je do bazy. Później jeśli ktoś chce je odczytać - pobieram zamówienia dla maksymalnie 5000 jednostek czasu (dla minuty - 5000 minut, dla godziny - 5000*60). Zapisuje je do cache z maksymalną ważnością (czyli dla interval 1m to będzie

Najbardziej optymalne rozwiązanie, jakie przyszło mi do głowy, dla którego dane cały czas będą "świeże".

@MacDada:

[MacDada]

@Zalazdi: Już samo włączenie go na produkcji stanowi (jakieśtam) obciążenie. Sprawdź na ile istotne to się dowiesz.

Testuj lokalnie, a nie na serwerze produkcyjnym, który może mieć różne obiążenie w zależności od pory dnia, etc. Olej kesze, testuj pełny kod. Zapisz czas rozpoczęcia, zakończenia requesta.

Włącz Xdebuga, j.w.

Włącz profilera w Xdebugu, j.w.

Będziesz miał odpowiedź czy to bardzo obciąża.

U nas na produkcji (jedne z najpopularniejszych witryn w Polsce) Xdebug

[Zalazdi]

@MacDada: W tym rzecz, że jeśli testuję lokalnie, bez żadnego obciążenia (lub liczonego w 5 osobach) to nie ma żadnego problemu z wykonywaniem requestów. I testowanie zawsze daje mi wyniki maksymalnie 1s przy parsowaniu danych i zapisie do cache. Jednak przy większej liczbie userów te 1s zamienia się w 5-10.

[MacDada]

@Zalazdi: Hmm, no to ciesz się, że masz lekką stronę :D

Jeśli lokalnie śmiga, to może czas dorzucić więcej pehapów, itp? Nginx zamiast Apache? Może to nie PHP jest problemem.

W każdym razie nadal możesz pozapisywać czasy na serwerze i uśredniać, biorąc pod uwagę fakt, że będzie to dużo mniej miarodajne.

[f.....x]

@Zalazdi: Trudno mi doradzić ,ale cos zaproponuje.

Miałem kiedyś podobny problem ,gdy potrzebowałem mieć aktualne dane a ruch na stronie powodował dławienie się mysql. Skutecznym rozwiązaniem problemu okazało się zrzucanie danych w formie statycznej do pliku json co 5 sek który potem był parsowany w js :).

Przed tym zabiegiem serwer ledwo zipał a po zmianie obciążenie spadło o dobre 40%.

Rozwiązanie skuteczne o ile json jest w rozsądnych rozmiarach :)

[Zalazdi]

@MacDada: Chyba, że uruchomię xdebug i sprawdzę, co zabiera najwięcej czasu i spróbować to zoptymalizować jak się da.

Tak, bardzo możliwe że to wina np. Apache. Też będę musiał to sprawdzić wieczorem, kiedy większość Ameryki się obudzi :)

@fotexxx: Tyle, że nie za każdym requestem biorę dane z bazy. Jedynie, kiedy potrzeba mi świeższych danych (czyli dla interwału 1m to będzie co minutę, dla jednego dnia, cache odświeża się co

[f.....x]

@Zalazdi: no to co w takim razie tak obciąża? zainstaluj może nmon albo coś podobnego i zobacz jakie procesy żyłują serwer:) Od tego w zasadzie powinieneś zacząć:)

[Zalazdi]

@fotexxx: Obciążenie serwera nie sięga 50%. Więc i to nie wiele pomoże. Po prostu coś za długo trwa. Tylko nie wiem co.

[MacDada]

daje mi wyniki maksymalnie 1s

@Zalazdi: blah, nie wiem czemu miałem w głowie

1ms

, a to przecież

1s

– więc długo. No to możesz spokojnie lokalnie optymalizować, to jest długi czas przetwarzania jeśli chodzi o samo PHP.

Jak masz jakieś typowe błędy (jak np kilkukrotne iterowanie po długiej tablicy, gdy można jednokrotnie), to jest szansa, że zjedziesz do

200ms

.

Wąskim gardłem BARDZO często jest też bazka.

[a.....r]

@Zalazdi: Przepisz w nodejs.

[MacDada]

@MacDada: A gdy idzie o bazki, to tak ją zbudować, żeby robić proste selecty, jak najmniej joinów, dobre indeksy, proste inserty zamiast update'ów, itp.

Odpal sobie tego xdebugowego profilera albo chociaż pozapisuj sobie czasy w ramach requesta i lokalnie obczaj gdzie masz najwięcej zżeranego czasu.

[Zalazdi]

@MacDada: Baza + PHP. Zresztą. Krótki kod, podrzucę. http://wklej.to/vsJka

@archlinuxuser: Też i o tym myślałem, kiedyś bawiłem się z node.js i socket.io (które w tym przypadku byłoby cholernie wydajne). Jednak wtedy potrafiło mi przynajmniej raz na godzinę paść.

@MacDada: Zaraz odpalę xdebug i zobaczymy.

[MacDada]

@Zalazdi: No to masz najpierw while'a, a potem foreacha – powinno dać się ścisnąć w jedną pętlę.

[f.....x]

@Zalazdi: Dodam tak od siebie:

https://github.com/wandenberg/nginx-push-stream-module

Warto się zapoznać świetna sprawa