Doba zpracování, dlouhý čas potřebný k načtení stránky
- Sochi
- Člen | 17
Ahoj,
dovolím si docela začátečnický dotaz, se kterým si ale nevím od jisté
chvíle rady. Problém je prostý, načtení stránky podle debuggeru trvá
dlouho, v debugbaru není problém se dostat ani na 6 až
9 vteřin 1 až 3 sekundy (připojení k lokální
databázi), přičemž databázových dotazů (nehledě na to, jak je
pomalá) je relativně málo (prakticky < 5) a spotřebují čas v rozsahu
od 20 do 100 ms. Pro porovnání aplikace z tutoriálu „Vytvořte si první
aplikaci!“ funguje relativně svižně, od 100 do 300 ms na celou stránku.
Dotaz: v čem může být zakopaný pes, proč je první aplikace tak pomalá?
Přijde mi divné, že by tak zásadní rozdíl způsobila pouze pomalejší
databáze.
Spouštěno ve virtualizovaném Ubuntu 12.04 přes VirtualBox (jiné aplikace běží dost svižně), PHP 5.3.9, verze Nette 2.0.3 pro PHP 5.2 bez prefixů. Z optimalizací jsem vyzkoušel snad již všechno možné, včetně např. nastavení cacheStorage na MemcacheStorage. Xdebug je vypnutý, nastavení PHP převážné výchozí. Bez eAcceleratoru nebo Zend Optimizeru (to bych rád nechal až na konec, kdy si budu jistý, že problém není ve špatném nastavení). V congif.neon mám 3 service a přibližne 10 factories, to mi nepřijde jako vysoké číslo.
Zkoušel jsem celou aplikaci profilovat přes Xdebug, ve výsledku 10 % spotřebovalo samotné PDO::execute, jinak po méně než pěti procentech na další Nette metody (routing, generování odkazů, render formulářů atp.). Díky Xdebugu doba zpracování samozřejmě pro profilování ještě narostla, takže absolutní čísla nemají žádnou vypovídající hodnotu.
Samozřejmě jsem pročetl snad všechna již existující podobná témata na fóru (např. https://forum.nette.org/…e-az-3-000ms) ale řešení mi nepřinesly. Nemám problém přiznat, že v Nette přiliš zběhlý nejsem, proto je dobře možné, že jsem nějaké nastavení například jednoduše přehlédl. Díky za každý nápad směřující k řešení :)
Editoval Sochi (23. 8. 2012 9:45)
- Sochi
- Člen | 17
Když přesunu databázi lokálně (abych nejakým způsobem minimalizoval komunikaci), doba načítání se sice výrazně zkrátí, prakticky ale zůstane v rozsahu 1 – 3 sekundy (což mi připadá stále dost). Zase takový lenochod to virutalizované Ubuntu není.
Patrik Votoček napsal(a):
Nepřegenerovává se ti při každém požadavku RoboloLoader cache?
To bohužek nevím, jak ověřit v nastavení. Soubor s cache na disku se ale rozhodně nemění.
Grelek napsal(a):
Ty máš PHP 3.9? :O
Samozřejmě, že ne. Překlep.
Editoval Sochi (23. 8. 2012 8:52)
- 22
- Člen | 1478
Sochi napsal(a):
Ahoj,
dovolím si docela začátečnický dotaz, se kterým si ale nevím od jisté chvíle rady. Problém je prostý, načtení stránky podle debuggeru trvá dlouho, v debugbaru není problém se dostat ani na 6 až 9 vteřin, přičemž databázových dotazů (nehledě na to, jak je pomalá) je relativně málo (prakticky < 5) a spotřebují čas v rozsahu od 20 do 100 ms. Pro porovnání aplikace z tutoriálu „Vytvořte si první aplikaci!“ funguje relativně svižně, od 100 do 300 ms na celou stránku. Dotaz: v čem může být zakopaný pes, proč je první aplikace tak pomalá? Přijde mi divné, že by tak zásadní rozdíl způsobila pouze pomalejší databáze.
Já tomu problému moc nerozumím, tak se blbě zeptám:
Jestli ti QuickStart – „Vytvořte si první aplikaci!“ jede
„normálně“, tj. 100 – 300 ms, tak „co“ ti teda trvá 6000 –
9000 ms, pokud se bavíme pořád o stejném PC a prostředí? Jak rychle se
ti načítá sandbox? Přijde mi to, že 6 – 9 vteřin máš na nějaké
své aplikaci, takže bych asi hledal nějaké kritické místo v té aplikaci.
Nepoužíváš tam třeba FB API? To by pak ten čas byl třeba uplně
normální, když si 6 x zavoláš na FB supersonicky rychlé API…
Editoval 22 (23. 8. 2012 9:21)
- Sochi
- Člen | 17
22 napsal(a):
Sochi napsal(a):
Ahoj,
dovolím si docela začátečnický dotaz, se kterým si ale nevím od jisté chvíle rady. Problém je prostý, načtení stránky podle debuggeru trvá dlouho, v debugbaru není problém se dostat ani na 6 až 9 vteřin, přičemž databázových dotazů (nehledě na to, jak je pomalá) je relativně málo (prakticky < 5) a spotřebují čas v rozsahu od 20 do 100 ms. Pro porovnání aplikace z tutoriálu „Vytvořte si první aplikaci!“ funguje relativně svižně, od 100 do 300 ms na celou stránku. Dotaz: v čem může být zakopaný pes, proč je první aplikace tak pomalá? Přijde mi divné, že by tak zásadní rozdíl způsobila pouze pomalejší databáze.Já tomu problému moc nerozumím, tak se blbě zeptám:
Jestli ti QuickStart – „Vytvořte si první aplikaci!“ jede „normálně“, tj. 100 – 300 ms, tak „co“ ti teda trvá 6000 – 9000 ms, pokud se bavíme pořád o stejném PC a prostředí? Jak rychle se ti načítá sandbox? Přijde mi to, že 6 – 9 vteřin máš na nějaké své aplikaci, takže bych asi hledal nějaké kritické místo v té aplikaci. Nepoužíváš tam třeba FB API? To by pak ten čas byl třeba uplně normální, když si 6 x zavoláš na FB supersonicky rychlé API…
Zmiňovaných 6 – 9 sekund byla vlastní aplikace ve stejném prostředí, ale s připojením ke vzdálené databázi. Když jsem změním připojování na lokální (tedy kompletně identické prostředí), čas se sníží na 1 až 3 sekundy. A to mi přijde hodně. Profiler (jak jsem psal výše) žádný bottleneck neukázal, nejvíc žere Route->constructUrl (5 – 10 %), PDOStatement->execute (7 – 10 %), Presenter->createRequest (okolo 5 %), SqlPreprocessor->formatValue (taky 5 %) a TableRow->access s TableRow->__get (obě okolo 3 %). Žádnou externí knihovnu nepoužívám, žádná kominikace s API, žádná složitá logika.
- redhead
- Člen | 1313
Možná, že to s tím souviset nebude, ale zkus: https://forum.nette.org/…ruct-1300-ms
- Sochi
- Člen | 17
HosipLan napsal(a):
Ukaž aspoň bootstrap a místa kde saháš na nastavení phpka a nette
Fajn, přiložím. Bootstrap bez změny oproti výchozímu stavu kromě routování:
<?php
// Routing settings for the application
$container->router[] = new Route('index.php', 'Homepage:default', Route::ONE_WAY);
// List of routing between subs
$subs = new RouteList('Subs');
$subs[] = new Route('<lang>/sub/<presenter>/handle[/<id>]/<do>', 'Subs::default');
$subs[] = new Route('<lang>/sub/<presenter>[/<action>][/<id>]', 'Subs::default');
$container->router[] = $subs;
$container->router[] = new Route('<lang>/<presenter>/handle[/<id>]/<do>', 'Homepage:default');
$container->router[] = new Route('[<lang>/][<presenter>][/<action>][/<id>]', 'Homepage:default');
// Configure and run the application!
$container->application->run();
?>
Dále php.ini bez změny od výchozích hodnot, pouze změny v max_execution time a paměti. V .htaccess následující:
<?php
## Charset
AddDefaultCharset utf-8
## Settings
php_flag magic_quotes_gpc 0
php_flag register_globals 0
## Configuration
php_value include_path .
php_value memory_limit 32M
php_value display_errors 1
php_value error_reporting 2147483647
## Multibyte
php_value default_charset utf-8
php_value mbstring.encoding_translation 1
php_value mbstring.internal_encoding utf-8
php_value mbstring.http_output utf-8
php_value mbstring.detect_order utf-8
php_value mbstring.func_overload 7
## Session
php_value session.cookie_lifetime 0
php_value session.gc_maxlifetime 10800
php_value session.use_trans_sid 0
php_value session.use_cookies 1
php_value session.use_only_cookies 1
php_value session.cookie_httponly 1
## Xdebug profiling
php_value xdebug.profiler_output_dir /tmp
php_value xdebug.profiler_enable 0
php_value xdebug.profiler_append 1
# No errors on dirs
Options -MultiViews
## Disable directory listing
<IfModule mod_autoindex.c>
Options -Indexes
</IfModule>
## Enable cool URL
<IfModule mod_rewrite.c>
RewriteEngine On
## Front controller
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule !\.(pdf|js|ico|gif|jpg|png|css|rar|zip|tar\.gz)$ index.php [L]
</IfModule>
## Enable gzip compression
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript text/javascript application/javascript application/json
</IfModule>
?>
Konfigurace Nette opět nic speciálního:
<?php
common:
parameters:
database:
driver: mysql
host: localhost
dbname: ...
user: ...
password: ...
php:
date.timezone: Europe/Prague
zlib.output_compression: yes
## Project session path
session.save_path: "%tempDir%/sessions"
nette:
session:
autoStart: smart
expiration: '+ 3 days'
database:
default:
dsn: '%database.driver%:host=%database.host%;dbname=%database.dbname%'
user: %database.user%
password: %database.password%
application:
errorPresenter: "Error"
services:
database: @\Connection
## Project cache settings
cacheStorage: MemcachedStorage
translator: GenericTranslator(@translations)
authenticator: Authenticator(@users)
factories:
...
contents: Contents
values: Values
menu: Menu
production < common:
development < common:
?>
- Sochi
- Člen | 17
redhead napsal(a):
Možná, že to s tím souviset nebude, ale zkus: https://forum.nette.org/…ruct-1300-ms
Díky za nápad, o tomhle vím, i když jsem si na to nyní vůbec nevzpomněl. Bohužel to není zdrojem problému v mém případě (nebo lépe řečeno, přepsat localhost na 127.0.0.1 nic nemění).
- Filip Procházka
- Moderator | 4668
Použij Debugger::timer()
, který budeš dávat na různé
úseky aplikace na cestě Configurator
→ Container
→ Application
→ Presenter
.
Tím můžeš zjistit, která část životního cyklu ti brzdí aplikaci.
- Filip Procházka
- Moderator | 4668
Pokud jsi z profileru nevyčetl, kde je problém, asi ho špatně používáš. Opravdu vyzkoušej ten timer a zkus najít kde je problém. Mně se QS načítá na localhostu během 60ms max.