Autor Zpráva
Lukáš66666
Profil
Zdravím, dá se nějak snadno zjistit, který skript na webu pracuje nejpomaleji?
Enko
Profil
Dá, nastav si časování do jednotlivých segmentů kódu. Např takto:
<?php
  $cas_hledani_start = microtime(true);

  //tady bude segment kodu, ktery chces zmerit//

  $cas_hledani_konec = microtime(true);
  $cas_hledani = $cas_hledani_konec - $cas_hledani_start;
  $cas_hledani = substr($cas_hledani, 0, 7);
  //cas, ktery trval beh segmentu kodu
  echo "<center><em>Trvalo to: $cas_hledani s</em></center>";

  //smaz nastaveni pomocnych promenych
  unset($cas_hledani_start);
  unset($cas_hledani_konec);
  unset($cas_hledani);
Lukáš66666
Profil
Enko:
No takovýto způsob znám, ale v tomto případě by to znamenalo umístit ten kód do velkého množství souborů a výsledky někam zapisovat. Těch souborů je tam několik stovek.
TomášK
Profil
Z logu webserveru. Zpravidla je možné ho nastavit tak, aby logoval i dobu zpracování požadavku.
Lukáš66666
Profil
TomášK:
A poradíš mi jak? V tom se nevyznám.
TomášK
Profil
Neporadím, ani nevím, jaký máš web server. A musel bych hledat v dokumentaci, jak přesně se to dělá, což dokážeš pravděpodobně stejně dobře jako já - bude to u nastavení logování.
Martin2
Profil *
TomášK:
Z logu webserveru. Zpravidla je možné ho nastavit tak, aby logoval i dobu zpracování požadavku.
To je celkem k ničemu. Webserver neví, která část PHP programu vytváří úzké hrdlo. Ani nemůže.

Lukáš66666:
Co potřebuješ je nějaký profiler. Můžeš zkusit ten, co je součástí extenze Xdebug. Nicméně PHP program málokdy způsobuje pomalé vykonávání požadavků. Většinou je na vině špatně navržená databáze, dlouhé načítání vzdálených prostředků nebo větší datové operace (třeba s obrázky). Když se zaměříš na ně, měl bys problém objevit i ručně.
Lukáš66666
Profil
Martin2:
No problém je asi v databázy. Jenže několik měsícu web jel bez potíží s téměř nulovým zatížením a až teď to začalo dělat potíže a přitom v db ani v kodu se nic neměnilo vše je stále stejné i počet návštěv webu za den. Jediné co se změnilo je že zátěž narostla tak, že server padá a pak je několik minut uplně mimo provoz, takže se nikdo na web nedostane.
TomášK
Profil
A nenarůstá objem dat v databázi tak, že to zpomalilo nějaké dotazy nad únosnou mez? Logováním časů zjistíš stránky, které jsou pomalé. Profilerem taky, o něco detailněji, ale nastavení bude hádám složítější. Ale problém máš s databází, hledal bych tam. Kajman ti radil logování pomalých dotazů, můžeš na chvíli zapnout i logování všech dotazů. Návodů je po webu spousta, třeba tu: stackoverflow.com/questions/6479107/how-to-enable-mysql-query-log (hádám, že to bude mysql)
Kajman
Profil
Martin2:
To je celkem k ničemu. Webserver neví, která část PHP programu vytváří úzké hrdlo.

Ale Lukáš66666 chtěl hledat „který skript na webu pracuje nejpomaleji“. K tomu je zmíněná úprava logu apache vhodná. Po analýze logu už bude vědět, u kterého skriptu z několika stovek souborů začít s profilováním.
Martin2
Profil *
Kajman:
K tomu je zmíněná úprava logu apache vhodná. Po analýze logu už bude vědět, u kterého skriptu z několika stovek souborů začít s profilováním.
A Apache mu bystře poradí, že je to index.php nebo bootstrap.php? K ničemu.
Davex
Profil
Lukáš66666:
Jediné co se změnilo je že zátěž narostla tak, že server padá a pak je několik minut uplně mimo provoz, takže se nikdo na web nedostane.
Zjišťoval jsi, proč narostla ta zátěž a z jakého důvodu server padá? Nějaká služba spotřebuje dostupnou RAM, server začne swapovat a ukončovat procesy nebo co se tam děje? Je server dostatečně dimenzovaný a konfigurace služeb přizpůsobená dostupným prostředkům?
Lukáš66666
Profil
Davex:
Budu to celé znovu procházet, ale pamět ram spotřebovaná není je zaplněná sotva tak na 10 %. Předtím to zkrátka šlo a aniž by se cokoliv měnilo to najednou padá nebo se to dlouho načítá. A taky mi vrtá hlavou proč jednou je tam 100 lidi a zátěž je uplně minimální a pak je tam 50 lidí a server mele z posledního. Přitom uživatelé mají přistup ke stejným věcem.
Davex
Profil
Nečekají třeba procesy na I/O nebo nejsou chyby v systémovém logu? Stačí jeden vadný disk v poli nebo vybitá baterka na RAID řadiči.
Lukáš66666
Profil
Davex:
V tom se moc nevyznám. Dá se to nějak monitorovat? Všiml jsem si, že největší zátěž je tam až tak po 18-té hodině i když je tam stejný počet návštěvníků jako celý den. Včera to bylo tak pomalé, že se mi úvodní stránka načítala skoro 5 minut.
Davex
Profil
Ke zjištění chyb se chodí logy, např. /var/log/syslog či příkaz dmesg. Na monitorování serveru se hodí třeba programy top, htop, iostat, pidstat, sar, ...

K získání celkového obrazu o stavu systému stačí třeba top, ke kterému zobrazíš nápovědu příkazem man top. Vypadá nějak takto:



Nahoře je zvýrazněno 14.2 wa, což znamená, že se 14.2 % CPU stráví čekáním na I/O operace.

Pokud je níže ve sloupci S písmeno D, tak to znamená, že daný proces čeká na I/O, což je nejčastěji komunikace s diskovým úložištěm.
Lukáš66666
Profil
Davex:
Já používám ten příkaz top. Ale v tom sloupečku S mám skoro všude písmeno S. A ta hodnota wa se aktuálně pohybuje v rozmezí 0.0 - 0.2 , ale u procesu mysql to ve sloupečku CPU před okamžikem vyskočilo na 481 %. Jinak to dneska jede celkem v pohodě oproti včerejšku, ale navštěvníků je tam stejně.
Davex
Profil
Lukáš66666:
Krátkodobé zvýšení využití CPU procesem nevadí. Pokud by to bylo trvale, tak je pravděpodobné, že MySQL spálí spoustu času nějakým zbytečným počítáním. Třeba nejsou tabulky správně oindexované nebo nejsou optimalizované dotazy a správně se indexy nevyužívají. Další možnost by byla ta, že se o CPU dělíš s dalšími uživateli a nezbyde dostatečný výkon.

Kolik má VPS virtuálních procesorů, jaké je load average, a jaká poslední hodnota na řádku %CPU popsaná st?
Lukáš66666
Profil
Davex:
No teď se mi to zdá v pohodě, ale ještě mě napadla jedna věc jelikož to ted jede v pohodě a včera nejelo jestli to nemuže být tím že třeba na vps je na jednom disku spuštěných těch vps víc a tím padem ten disk jakoby nestíhá? Ale to je asi blbost ne?
Davex
Profil
Lukáš66666:
Ty provozuješ server na jednom fyzickém disku? Tam bych se bál něčeho úplně jiného.

Kdyby výkon brzdil disk, tak by MySQL tolik nevytěžovalo CPU. Programem iostat 1 můžeš sledovat, jak je disk vytížen. Případně využití jednotlivými procesy pidstat -d 10.
Lukáš66666
Profil
Davex:
No já totiž netuším jak to u VPS chodí jestli se ten disk sdílí a nebo každému vps je přiřazen samostatný.

A v tom co vypisuje ten iostat se nějak moc neorientuju.
Davex
Profil
Lukáš66666:
U běžných poskytovatelů se sdílí všechno. Od CPU, přes paměť, disky až po síťové rozhraní. S klesající cenou obvykle roste počet VPS na hostitele. Garantovaný minimální výkon poskytuje málokdo, protože musí být pro každého zákazníka vyhrazený a tím se zvyšují náklady.
Lukáš66666
Profil
Davex:
A myslíš že by to mohlo být tím? Komplikace jsou dneska taky cca půl hodiny ale výkon zase nijak nenarostl.
Nepomohl by třeba dedikovaný server?
Davex
Profil
Lukáš66666:
Na základě známých informací se to nedá posoudit. S největší pravděpodobností bude příčina přetížení ve způsobu použití databáze v kombinaci s nevhodným nastavením systému a služeb. Vhodnou optimalizací by se to mohlo vyřešit, ale vyžaduje to hlubší analýzu, kterou tady neuděláme.
Lukáš66666
Profil
Davex:
Zkusím použít cache pro některé stránky webu třeba to pomůže.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: