Temat: Optymalizacja dziesięciu linijek kodu PHP

Mam taki kawałek kodu (wyświetla ostatnich 5 komentarzy z fotek, pomijając dublowanie się linków):

http://pastebin.com/m69f4ae7c

Okazuje się, że masakryczne obciąża procesor. Ma ktoś jakiś pomysł ;-)?Radosław Szczęsny edytował(a) ten post dnia 09.03.09 o godzinie 23:25

Temat: Optymalizacja dziesięciu linijek kodu PHP

Radosław Szczęsny:
Mam taki kawałek kodu (wyświetla ostatnich 5 komentarzy z fotek, pomijając dublowanie się linków):

Okazuje się, że masakryczne obciąża procesor. Ma ktoś jakiś pomysł ;-)?Radosław Szczęsny edytował(a) ten post dnia 09.03.09 o godzinie 23:21

to jeszcze pokaż ten kod w jakiś sposób:)
http://pastebin.com/

Temat: Optymalizacja dziesięciu linijek kodu PHP

Tak, coś się nie wkleiło :P.

Temat: Optymalizacja dziesięciu linijek kodu PHP

Radosław Szczęsny:
Tak, coś się nie wkleiło :P.

ale ogólnie to ten kod działa tak jak było planowane? robi to co ma robić?Adam W. edytował(a) ten post dnia 09.03.09 o godzinie 23:34

Temat: Optymalizacja dziesięciu linijek kodu PHP

kilka podstawowych bUendow.

zamiast count* uzyj limit
zamiast selecta w petli zmodyfikuj pierwsze zapytanie sql

i pewnie cos jeszcze, ale pora pozna..

Temat: Optymalizacja dziesięciu linijek kodu PHP

GROUP BY photos_comments.id

nie rozumiem sensu grupowania po ID wpisu (domyślam się że autoincrement) ?

if(count($row)>5)

a czemu nie LIMIT 5 ?

dobierz odpowiednie indeksowanie , mnie kiedyś przyśpieszyło otwieranie strony z (horror) 8 sekund do kilkunastu ms :)

Temat: Optymalizacja dziesięciu linijek kodu PHP

Adam W.:

Radosław Szczęsny:
Tak, coś się nie wkleiło :P.

ale ogólnie to ten kod działa tak jak było planowane? robi to co ma robić?Adam W. edytował(a) ten post dnia 09.03.09 o godzinie 23:34

Tak, tak.
Ogólnie działa to w sposób, że pokazuje 5 ostatnich komentarzy ale wyklucza możliwość, że będziemy mieli wyjściowo 5 tych samych linków. Po prostu je grupuje w jeden (sumuje liczbę komentarzy w nawiasie) i podbija "do góry".

ID fotki => ID komentarza łączone w tabeli z ID fotki

Temat: Optymalizacja dziesięciu linijek kodu PHP

Skup się na zapytaniach do bazy, bo to jest chyba główny problem. Np możesz sobie zobaczyć poprzez EXPLAIN SELECT... w jaki sposób zapytanie jest wykonywane, ile rekordów musi przetworzyć, aby zwrócić wynik, czy używane są klucze.

Unikaj tez używania 'SELECT * FROM', zamiast tego używaj 'SELECT pole1, pole2, ...FROM".

Temat: Optymalizacja dziesięciu linijek kodu PHP

Nic dziwnego, że Ci to zamula.
Uruchamiasz pętlę w pętli a w niej jeszcze cyklicznie pojedyncze zapytanie. Tak się nie robi. Powinieneś wykonać zapytanie raz, pobrać kilka rekordów np. do tablicy, a potem sobie uruchomić w pętli tablicę (najlepiej foreach). Ten kod jest wyrwany z kontekstu, ale na pierwszy rzut oka wydaje mi się, że masz tam mnóstwo niepotrzebnych rzeczy. Czy aby na pewno potrzebne jest tam aż tyle pętli, zapytań i zmiennych? Staraj się zrzucić, jak najwięcej operacji na bazę danych, ale też maksymalnie ograniczyć ilość wykonywanych do niej zapytań. Jeśli chodzi o nadmiar zmiennych, to akurat PHP, to nie powinno boleć, że jest ich za dużo. Takie rzeczy są istotne np. podczas alokacji pamięci w C lub C++, ale redukując liczbę zmiennych minimalnie (ale jednak) zwiększysz wydajność kodu i możesz znacznie zwiększyć jego czytelność, co jest bardzo ważne, jeśli chcesz tę aplikację w ogóle kiedykolwiek rozwijać lub modyfikować.

Temat: Optymalizacja dziesięciu linijek kodu PHP

Nie daloby sie tego jakims JOINem skleic i dostac calosc w jednym zapytaniu? Trudno wnioskowac bez pogladu na strukture bazy, ale mnie to wyglada jakbys dwa razy to samo odpytywal.

Temat: Optymalizacja dziesięciu linijek kodu PHP

Piotr Wittchen:
Nic dziwnego, że Ci to zamula.
Uruchamiasz pętlę w pętli a w niej jeszcze cyklicznie pojedyncze zapytanie. Tak się nie robi.

ale policzyłeś ile tych zapytań się wykonuje?
'katowałem' CPU 10 tysiącami zapytań, kilka operacji zmiany kodowania - wykonało się to w mniej niż 20 sekund.
także tutaj nie można być fanatykiem - kilkanaście zapytań to żadna zgroza.
fakt, że tak się nie powinno robić, ale żeby od razu masakrycznie obciążało procesor?:)
ja nie wiem dlaczego to masakrycznie obciąża, nie mam debuggera w oczach, trzeba by sprawdzić jak bardzo obciążają same zapytania, ile ich się wykonuje. no bo kod jak kod, nic szczególnego:)

Temat: Optymalizacja dziesięciu linijek kodu PHP

Radosław Szczęsny:

select photos.id,photos.title zamiast select *
teraz jest tak, że pod * wpadają Ci niepotrzebne do niczego dane z 2 tabel (photos_comments, photos)!

po co COUNT(*) AS count_comments (a więc również GROUP BY) skoro nigdzie dalej tego nie używasz?

limit 5 na końcu pierwszego zapytania też ułatwiłby sprawę.

Temat: Optymalizacja dziesięciu linijek kodu PHP

Adam W.:

Piotr Wittchen:
Nic dziwnego, że Ci to zamula.
Uruchamiasz pętlę w pętli a w niej jeszcze cyklicznie pojedyncze zapytanie. Tak się nie robi.

ale policzyłeś ile tych zapytań się wykonuje?
'katowałem' CPU 10 tysiącami zapytań, kilka operacji zmiany kodowania - wykonało się to w mniej niż 20 sekund.
także tutaj nie można być fanatykiem - kilkanaście zapytań to żadna zgroza.
fakt, że tak się nie powinno robić, ale żeby od razu masakrycznie obciążało procesor?:)
ja nie wiem dlaczego to masakrycznie obciąża, nie mam debuggera w oczach, trzeba by sprawdzić jak bardzo obciążają same zapytania, ile ich się wykonuje. no bo kod jak kod, nic szczególnego:)

No dobra, ale czy wywołanie więcej, niż jednego zapytania wydaje Ci się normalne w celu wyświetlenia jakichś 5 komentarzy? :-P Nie mówię, że nie wolno używać kilku zapytań na raz, ale trzeba to robić wtedy, kiedy jest taka potrzeba.

Temat: Optymalizacja dziesięciu linijek kodu PHP

Adam W.:
ale policzyłeś ile tych zapytań się wykonuje?
'katowałem' CPU 10 tysiącami zapytań, kilka operacji zmiany kodowania - wykonało się to w mniej niż 20 sekund.
także tutaj nie można być fanatykiem - kilkanaście zapytań to żadna zgroza.
fakt, że tak się nie powinno robić, ale żeby od razu masakrycznie obciążało procesor?:)
ja nie wiem dlaczego to masakrycznie obciąża, nie mam debuggera w oczach, trzeba by sprawdzić jak bardzo obciążają same zapytania, ile ich się wykonuje. no bo kod jak kod, nic szczególnego:)

Po pierwsze zalezy jakie zapytania, po drugie 20 zapytań przy jednym odświeżeniu strony razy ileśset tysięcy odświeżeń w ciągu doby przez kilka tysięcy użytkowników to dużo.
I trzeba być fanatykiem.

Tabele by się przydały jakieś przykładowe do tego bo nie chce mi się wymyślac, a jak czegoś sobie nie przetestuję na żywo to nie zrobię :)Jakub Korupczyński edytował(a) ten post dnia 10.03.09 o godzinie 18:02

Temat: Optymalizacja dziesięciu linijek kodu PHP

Jakub Korupczyński:

Adam W.:
ale policzyłeś ile tych zapytań się wykonuje?
'katowałem' CPU 10 tysiącami zapytań, kilka operacji zmiany kodowania - wykonało się to w mniej niż 20 sekund.
także tutaj nie można być fanatykiem - kilkanaście zapytań to żadna zgroza.
fakt, że tak się nie powinno robić, ale żeby od razu masakrycznie obciążało procesor?:)
ja nie wiem dlaczego to masakrycznie obciąża, nie mam debuggera w oczach, trzeba by sprawdzić jak bardzo obciążają same zapytania, ile ich się wykonuje. no bo kod jak kod, nic szczególnego:)

Po pierwsze zalezy jakie zapytania, po drugie 20 zapytań przy jednym odświeżeniu strony razy ileśset tysięcy odświeżeń w ciągu doby przez kilka tysięcy użytkowników to dużo.
I trzeba być fanatykiem.

o czym Ty piszesz?:)
nie bierzesz wszystkiego pod uwagę.
autor tematu nie napisał gdzie ten kod jest wykonywany, ile ludzi z tego korzysta, jak często jest to wykonywane. napisał tylko, że ten kawałek kodu masakrycznie obciąża CPU. ja tylko napisałem, że nawet 20 zwykłych zapytań nie obciąża masakrycznie CPU.

Temat: Optymalizacja dziesięciu linijek kodu PHP

Piotr Wittchen:

Adam W.:

Piotr Wittchen:
Nic dziwnego, że Ci to zamula.
Uruchamiasz pętlę w pętli a w niej jeszcze cyklicznie pojedyncze zapytanie. Tak się nie robi.

ale policzyłeś ile tych zapytań się wykonuje?
'katowałem' CPU 10 tysiącami zapytań, kilka operacji zmiany kodowania - wykonało się to w mniej niż 20 sekund.
także tutaj nie można być fanatykiem - kilkanaście zapytań to żadna zgroza.
fakt, że tak się nie powinno robić, ale żeby od razu masakrycznie obciążało procesor?:)
ja nie wiem dlaczego to masakrycznie obciąża, nie mam debuggera w oczach, trzeba by sprawdzić jak bardzo obciążają same zapytania, ile ich się wykonuje. no bo kod jak kod, nic szczególnego:)

No dobra, ale czy wywołanie więcej, niż jednego zapytania wydaje Ci się normalne w celu wyświetlenia jakichś 5 komentarzy? :-P Nie mówię, że nie wolno używać kilku zapytań na raz, ale trzeba to robić wtedy, kiedy jest taka potrzeba.

myślę, że znalazło by się kilkadziesiąt sposobów na wykonanie tego zadania. tylko nie było pytania jak to zrobić tylko czemu to obciąża CPU:)

Temat: Optymalizacja dziesięciu linijek kodu PHP

ło jezu. masz nie kawałek kodu a kawałek kupy. z przewagą kupy (parafrazując)

żeby przeanalizować:
1 wyciągasz wszystkie komentarze połączone ze zdjęciami + sumę wszystkich wierszy (count(*))
2. jeżeli ilość komentarzy jest 5, ustawiasz limit na 5 i jedziesz pętlą od 1 do 5, w której...
4. najpierw sprawdzasz, czy id komentarza (spośród ostatnich 5 wyciągniętych w pkt 1) jest w tabeli displayed, i
5. jak nie ma, pobierasz wszystkie komentarze dla zdjęcia, którego komentarz nie był jeszcze wyświetlony i printujesz zdjęcie z pierwszego zapytania i liczbę komentarzy z zapytania z pkt. 5.
6. jak jest, zwiększasz sobie limi
7. bez względu na 5,6 - dopisujesz ID do tabeli displayed

łojapier*ole ;)

napisz może co chcesz osiągnąć, bo z tego kodu nic nie wynika.
przede wszystkim, nie rozumiem indeksów, pobierasz *, gdzie "id" odnosi się zarówno do photos_comments.id jak i photos.id, a później wykorzystujesz to id jako photo_id. Po drugie, robisz w pętli zapytanie, ktore zwraca wszystkie komentarze dla danego zdjęcia, a wyświetlasz tylko ilość tych komentarzy.

jest też błąd, piszesz, że id komentarza to id fotki ale z kodu wynika ze photo_id komentarza to id fotki... kto to spłodził?

aaaaa, już wiem ;)

select photo_id, title from photos_comments where id in (select max(id) as latest from photos_comments group by photo_id) order by id desc

i wyswietl to co zwrocilo. zliczanie ilości wszystkich komentarzy sobie dorób ;)

Temat: Optymalizacja dziesięciu linijek kodu PHP

Adam W.:

Jakub Korupczyński:

Adam W.:
ale policzyłeś ile tych zapytań się wykonuje?
'katowałem' CPU 10 tysiącami zapytań, kilka operacji zmiany kodowania - wykonało się to w mniej niż 20 sekund.
także tutaj nie można być fanatykiem - kilkanaście zapytań to żadna zgroza.
fakt, że tak się nie powinno robić, ale żeby od razu masakrycznie obciążało procesor?:)
ja nie wiem dlaczego to masakrycznie obciąża, nie mam debuggera w oczach, trzeba by sprawdzić jak bardzo obciążają same zapytania, ile ich się wykonuje. no bo kod jak kod, nic szczególnego:)

Po pierwsze zalezy jakie zapytania, po drugie 20 zapytań przy jednym odświeżeniu strony razy ileśset tysięcy odświeżeń w ciągu doby przez kilka tysięcy użytkowników to dużo.
I trzeba być fanatykiem.

o czym Ty piszesz?:)
nie bierzesz wszystkiego pod uwagę.
autor tematu nie napisał gdzie ten kod jest wykonywany, ile ludzi z tego korzysta, jak często jest to wykonywane. napisał tylko, że ten kawałek kodu masakrycznie obciąża CPU. ja tylko napisałem, że nawet 20 zwykłych zapytań nie obciąża masakrycznie CPU.

10k UU dziennie, na stronie głównej, co kilkanaście sekund.

Temat: Optymalizacja dziesięciu linijek kodu PHP

Okropna jest ta pierwsza linijka, w której wczytywane są wszystkie rekordy z bazy do PHPowej tablicy. Nie przypadkiem podstawowym mechanizmem jest przeskakiwanie po rekordzie, a nie wczytywanie od razu całości (co zazwyczaj polega na przeskoczeniu wszystkich rekordów i zapisaniu ich w tablicy ;)) - różnica w wydajności jest raczej ogromna.

Zatem - abstrahując od miażdzącego zapytania SQL, radzę Ci zastosować inną metodę wyciągania danych z bazy.

Temat: Optymalizacja dziesięciu linijek kodu PHP

Zmień 1szą linijkę kodu (zapytanie). Tak jak napisali inni zamiast * daj nazwy pól, limit lub użyj DISTINCT...Adrian Pionka edytował(a) ten post dnia 17.03.09 o godzinie 08:31