Problemy z szybkością ładowania się strony

godzina 16:20 - tragedia.. udało mi sie otworzyć stronę za n-tym razem..

Ja już momentami nie wyrabiam. Albo się w ogóle nic nie otwiera(404), albo trwa to tyle co kompilacja programu pisanego w Javie na Pentium II 300 z 64 MB ram(można se zrobić herbatę i ją wypić)

Hmm, moim zdaniem konf. sprzetowa powinna wystarczyc i hmm - starcza. Wedlug statystyk w ogole max. wykorzystanie procesora to 90% (jakie odnotowano), przecietnie jest to 40%. Mysle ze wina lezy w innym miejscu, moze ktos ma jakas rade?

UPDATE: zmienilem nieco konfiguracje, powiedzcie czy odczuwalna jest jakas roznica? Na lepsze czy na gorsze?

Adam Boduch napisał(a)

UPDATE: zmienilem nieco konfiguracje, powiedzcie czy odczuwalna jest jakas roznica? Na lepsze czy na gorsze?

nie wiem czy to to czy przypadek ale udało mi się pochodzić po 4p bez ucisku na klatce i powtarzaniu "wdech ... wydech ..."
btw wydaje mi się że od powstania dodatkowego pola szukania po userze w szukajce, wyszukiwarka znacznie wolniej po nim szuka, kiedyś to było tak samo szybkie jak zwykłe szukanie po treści a teraz to zajmuje średnio minutę (samego generowania strony)

Nie powinno zwiększać czasu, bo jeśli to pole jest puste, to zapytanie jest identyczne z tym starym, o którym mówisz.

Co do speeda strony, zobaczym w ciągu dnia.

[edited - a raczej dopisek, bo się post nie wysłał :/]
chyba dupa, bo minutę się post wysyłał po czym FF2 próbował ściągnąć posting.php

@Marooned, Adamo ma rację pamiętam jak uzbrajałeś szukajke o autora postu, od tego czasu jest widoczny spadek prędkości generowania listy. Ale teraz to nie wiem co powiedzieć, bo koncepcję mi popsuło zdanie "jest identyczne..." Hmm... Gdzieś musi być żle sformułowany warunek lub coś podobnego. Aczkolwiek speed forum zrobił ++, nawet +++ w porównaniu z "wcześniej"

// Czas generowania strony: 0.1676 sek. (zapytań SQL: 12)

Jest 1 w nocy. Forum zawsze tak działa o tej godzinie.

plik: forum/search.php
linia: 339

' (...)
WHERE ' . (isset($sql_user) ? "$sql_user AND":'') . '

Jeśli user nie wpisał nic w pole szukania po autorze, to zmienna $sql_user nie jest inicjowana i ta linijka zawiera tylko słowo kluczowe WHERE dając w wyniku zapytanie, które było, gdy nie istniała możliwość szukania po autorze.

Zbieg okoliczności być musi.

ale ja mówię że jak się właśnie wpisze to szuka minutę, bo jak nie to zależy od wiatrów ale też się wydaje że wolniej

//aa, no to oczywiste, w końcu dodatkowe warunki do sprawdzenia się pojawiają - M

jednak nic z tego, bo znowu wolno chodzi ... chociaż cały czas czekania jest w generowaniu i strona się w ogóle pojawia, a wcześniej się pojawiała co drugi raz i po zdecydowanie dłuższym czasie niż pisało w stopce

no wiadomo że dodatkowe warunki, mówiłem że po autorze teraz szuka powiedzmy minutę a po tekście 5 sekund, a kiedyś i po autorze i po tekście było 5 sekund
no przypuszczam że zbieg okoliczności ale tak na wszelki wypadek napisałem

Jestem pod wrazeniem max jaki mialem to Czas generowania strony: 3.4924 sek. (zapytań SQL: 14)

:D

Popsuję Wam humor - raz pobieranie 'viewtopic.php', raz zerwanie połączenia potem "Czas generowania strony: 36.4525 sek. (zapytań SQL: 12)" a wszystko tylko dla tego tematu - coś nadal jest nie tak. Może podczas modyfikacji skryptu pojawiła się jakaś walnięta pętla - skopany warunek wychodzenia? To tylko taka moja sugestia - nie znam php :/

U mnie duzo lepiej, teraz max to 3-4s, przedtem minimum 30-40s albo i w ogole. Od wczoraj nie zauwazylem, zeby sie forum nie zaladowalo.

Ja dostaję czasami błędy MySQL ale poza tym to przyspieszyło 4p.

Nadal wooooolno + błąd MySQL "Duplicate entry" w coyote_session

[edited]
dodanie tej odpowiedzi jakieś 10s [czas generowania: 0.9s]

Właśnie ten wątek (druga strona przy wyświetlaniu 10p/stronę gwoli ścisłości):
Czas generowania strony: 35.3195 sek. (zapytań SQL: 12)
Nie jest tak zbyt idealnie :/

Hmm, w godzinach szczytu postaram sie jeszcze potestowac konfiguracje apache ale nie wiem ile jeszcze moge zrobic. Ja najwiekszy czas ladowania jaki mialem to 3 sek. Nalezy zauwazyc ze na serwie budza sie dosyc czesto procesy ktore "ssa" procesor, np. spamassistant, mrtg, webalizer, wiec ten przydlugawy czas ladowania to tylko jednorazowo, prawda?

Adam Boduch napisał(a)

tylko jednorazowo, prawda?
bynajmniej, niestety...

właśnie w temacie http://4programmers.net/Forum/viewtopic.php?id=101020 miałem "Czas generowania strony: 198.1432 sek. (zapytań SQL: 14)" :( Coś chyba te poprawki nie pomogły :/

deus napisał(a)

właśnie w temacie http://4programmers.net/Forum/viewtopic.php?id=101020 miałem "Czas generowania strony: 198.1432 sek. (zapytań SQL: 14)" :( Coś chyba te poprawki nie pomogły :/

To ponad 3 minuty... U mnie przeglądarka timeout daje po 2 min. Rekord nie do pobicia :P

Ja to najczęściej mam albo timeout albo próbuje ściągnąć pliczek viewtopic.php :/

Najlepiej działa przed południem. Później im bliżej godzin szczytu internetowego (15 oraz 22), tym gorzej.

Tym bardziej dziwna ze timeout na serwerze tez jest mniejszy niz 3 min ;)

No nic - kolejna zmiana (powinna pomoc). Zobaczymy jak sie bedzie sprawowac w godzinach szczytu. Testy wykazuja poprawe wydajnosci no ale niezapominajmy ze jest to strona dynamiczna i czas jej generowania zalezy od wielu innych czynnikow.

W kazdym badz razie obecnie jezeli chodzi o strony statyczne, serwer jest w stanie obsluzyc ponad 1000 wywolan na sekunde.

UPDATE: coz, teraz znacznie gorzej sie sprawuje w warunkach zwiekszonego obciazenia :/

Ja z kolei mam często tego typu błędy:

Przed chwila forum pobilo rekordy, bo widzialem z 5 roznych bledow (too many connections, cannot connect through socket costam, 404, czysta strona i cos jeszcze). Do tego na dwie zamieszczane odpowiedzi prob bylo 10, 3 udane (jeden duplikat ;) ).

Nom, jednak z serwerem HTTP jest wszystko w porzadku, to MySQL nie daje rady i muli :( Pedros masz jakis pomysl co by z baza rozwiazac?

Adam.Pilorz napisał(a)

Ja nie wiem, co się dzieje, ale u mnie Fx po otworzeniu forum 4p zaczyna zżerać 100% procesora :/. Nie ma problemów na innych stronach, więc chyba coś z 4p jest nie tak :/
mi ostatnio FF się sam wyłączał, jak wchodziłem na 4P, wyłączyłem obsługę JS i jest git.

Poprawilem nieco wydajnosc forum. W jednym miejscu brakowalo indeksu, dodalem tez w innym miejscu dla przyspieszenia dzialania. Okazalo sie tez ze kompilacja szablonow byla wylaczona ;]
Niestety problem wciaz istnieje - glownie przy odczytywaniu tematow z forum. Nie wiem czemu ale niekiedy banalne zapytania UPDATE albo INSERT (czyli takie ktore powoduja aktualizacje danych) kompletnie zawieszaja dzialanie calego skryptu. W glownej mierze to one sa powodem generowania strony w ciagu 30 sek :/ Banalne zapytanie UPDATE, ktore powinno byc wykonane w 0,001 sek (czasem tak bywa) niekiedy wykonywane jest po 30 sek. :-( Moze spotkal sie ktos z takim problemem?

Mnie się zdarzały taki klocki kiedy indeksy się sypały.

Adam Boduch napisał(a)

Banalne zapytanie UPDATE, ktore powinno byc wykonane w 0,001 sek (czasem tak bywa) niekiedy wykonywane jest po 30 sek. :-( Moze spotkal sie ktos z takim problemem?

1. Czy używacie transakcji (InnoDB)?
2. Jeśli tak, jaki poziom izolacji?
3. Sprawdźcie, czy nie ma jakis problemów z lockowaniem (deadlocki). Tabele MyISAM są lockowane całe, nawet jeśli tylko jeden rekord jest zapisywany. Być może ten nieszczęsny UPDATE czy INSERT czeka na uzyskanie locka.
4. Zawsze pomaga zrobić dumpa całej bazy i zassać jeszcze raz - przynajmniej wtedy jest gwarancja, że nic się na dysku nie rozjechało z fizyczną reprezentacją danych. W MySQL ustawionym domyślnie (MyISAM) łatwo o uszkodzenia, bo nie używa fsync.
5. Jakie jest obciązenie maszyny, gdy to się dzieje? Jakie jest użycie I/O, RAM, CPU?

// dopisane później:
MySQL SQL Error Duplicate entry '5f53395a33fc876313c0fc846axxxxxxxx for key 1 (1062)
SQL Query INSERT INTO coyote_session (session_id, session_user_id, session_ip, session_start, session_stop, session_logged_in, session_page) VALUES( "5f53395a33fc876313c0fc846xxxxxxxxx", 4889, "83.31.244.128", 1166913116, 1166913116, 1, "/viewtopic.php?id=99950&start=50")

Hmm - generator id sesji nie generuje unikatowych SIDów? Czyżbym odkrył dziurę w Coyote?
Czy może system nie używa jednak transakcji, lub ma zbyt niski poziom izolacyjności transakcji? Tj. ten drugi SID, który próbował wstawić do tabelki, to był tak naprawdę mój SID wstawiony wcześniej przez niedokończoną poprzednią transakcję (wieczorem chodzi wolno i nie pamiętam, czy nie kliknąłem przypadkiem 2 razy)? Fakt, że za drugim razem błąd nie wystąpił.

Wolałbym żeby to drugie, bo jeśli to pierwsze i np. SID jest generowany tylko na podstawie zegara, to zbyt łatwo dałoby się przechwycić cudzą sesję.

Dziś przeprowadziłem eksperyment - na 2 PC z innego łącza:

1. Na PC1 pisałem posta i dałem wyślij (mulił 3 minuty)
2. Na PC1 zapodałem ping (nieprzerwanie około 200ms)
3. Na PC2 strona się nie ładuje
4. Na PC2 zapodałem ping (nieprzerwanie około 200ms)
5. <krok 1. wciąż trwał>
6. Na PC2 połączyłem się telnetem (bez problemu od razu, ale żadnej odpowiedzi, pomimo przyjętego połączenia).
7. Gdy krok 1. został zakończony pusta stroną, na PC2 załadował się serwis z błędem Duplicate Entry.
8. Gdy dałem odśwież na PC1, na obu strona załadowała się prawidłowo.

Wnioski: może Ameryki nie odkryję ale wygląda na to, że może istnieć sytuacja, w której inni (wszyscy, niektórzy?) użytkownicy są blokowani, bo komuś wystąpił błąd. Już nie mówię o błędzie Too many connections (który i tak jest denerwujący), chyba, że one się ze sobą wiążą..

A tak przy okazji, dzisiaj czas generowania strony około 18:00 - 15 minut 20 sekund (nie ma ustawionych jakichś timeoutów?)

ja będę uparty, test zrobiony gdy serwis działał dość szybko - szukanie standardowe - czas=n/d, szukanie po autorze postu - czas: 3 min, po 3 min 404, tymczasem na innym kompie serwis nie działa, po dostaniu 404 zamiast wyniku wyszukiwania jeszcze jakaś minuta mija i serwis wraca do normalnego działania
może to przypadek, ale 3 na 4 razy tak właśnie mam

a nie twierdzę już że to przez poprawkę Marooned'a, bo on napisał że zapytanie jest identyczne jak przedtem po wpisaniu autora, ale może brakuje jakiegoś indeksu czy czegoś

jasne że te błędy mają dużo wspólnego ze zbyt dużą ilością połączeń, bo zapytania są wykonywane wolniej, a jeszcze niektórzy odświeżają stronę mając nadzieję że to coś przyspieszy (co się akurat czasami sprawdza).

a ustawienie timeoutu na ze 2 minuty też by mogło być - kto czeka 15 minut na załadowanie strony ? no chyba że mu bardzo zależy a i tak w między czasie idzie do kuchni zrobić sobie śniadanie ...