Doba zpracování, dlouhý čas potřebný k načtení stránky

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
Sochi
Člen | 17
+
0
-

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)

Grelek
Člen | 233
+
0
-

Sochi napsal(a):
PHP 3.9, verze Nette 2.0.3 pro PHP 5.2 bez prefixů

Ty máš PHP 3.9? :O

Patrik Votoček
Člen | 2221
+
0
-

Nepřegenerovává se ti při každém požadavku RoboloLoader cache?

Sochi
Člen | 17
+
0
-

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
+
0
-

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
+
0
-

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.

Filip Procházka
Moderator | 4668
+
0
-

Ukaž aspoň bootstrap a místa kde saháš na nastavení phpka a nette

redhead
Člen | 1313
+
0
-

Možná, že to s tím souviset nebude, ale zkus: https://forum.nette.org/…ruct-1300-ms

Sochi
Člen | 17
+
0
-

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
+
0
-

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
+
0
-

Použij Debugger::timer(), který budeš dávat na různé úseky aplikace na cestě ConfiguratorContainerApplicationPresenter.

Tím můžeš zjistit, která část životního cyklu ti brzdí aplikaci.

Sochi
Člen | 17
+
0
-

HosipLan napsal(a):

Použij Debugger::timer(), který budeš dávat na různé úseky aplikace na cestě ConfiguratorContainerApplicationPresenter.

Tím můžeš zjistit, která část životního cyklu ti brzdí aplikaci.

To mi neřekne nic navíc, co bych už nevěděl z profileru..

Filip Procházka
Moderator | 4668
+
0
-

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.