Wolny Czas Inicjalizacji Symfony2

Miałem 5-30 sek odpowiedzi z Symfony2 domyślnie. Teraz jest ~500ms w środowisku dev.

NastÄ™pnie zmodyfikowaÅ‚em nastÄ™pujÄ…ce rzeczy w php.ini:

• Zestaw realpath_cache_size = 4M (lub wiÄ™cej)
• wyÅ‚Ä…czone XDebug caÅ‚kowicie (test z phpinfo)
• realpath_cache_ttl=7200
• wÅ‚Ä…czone i ustawione OPcache (lub APC) poprawnie
• ponownie uruchomiony Apache, aby mieć php.ini reloaded

I voilá, odpowiedzi były poniżej 2 SEK w trybie dev! Mam nadzieję, że to pomoże.

Przed: 6779 ms

Po: 1587 ms

Symfony2 odczytuje klasy z tysięcy plików i jest to powolny proces. Podczas korzystania z małej pamięci podręcznej PHP realpath ścieżki plików muszą być rozwiązywane jeden po drugim za każdym razem, gdy nowe żądanie jest składane w środowisku deweloperskim, jeśli nie znajdują się one w pamięci podręcznej PHP realpath. Pamięć podręczna realpath jest domyślnie zbyt mała dla Symfony2. W prod nie jest to problem oczywiście.

Metadane pamięci podręcznej:

doctrine:
    orm:
        entity_managers:
            default:
                metadata_cache_driver: apc
                query_cache_driver: apc
                result_cache_driver: apc

Musisz wÅ‚Ä…czyć APCu w tym celu. Jest to APC bez bufora bajtowego, ponieważ OPCache już obsÅ‚uguje buforowanie kodu OPC. OPCache jest wbudowany od PHP 5.5.

---- po: 467 ms - - - -

(w środowisku prod ta sama odpowiedź to ~80 ms)

Uwaga, to jest projekt wykorzystuje 30+ pakiety i ma dziesiątki tysięcy linii kodu, prawie sto własnych usług, więc 0.5 s jest dość dobry w lokalnym środowisku Windows za pomocą zaledwie kilku prostych optymalizacji.

W związku z tym, że nie jestem w stanie się z Tobą skontaktować, nie mogę się z Tobą skontaktować. Został zainstalowany przy użyciu macports:

sudo port install php54-xdebug.

Z włączonym xdebug, każda strona kończy się maksymalnym czasem ładowania, z błędem krytycznym przekraczającym maksymalny czas wysyłania wiadomości. Po wyłączeniu wszystko ładuje się dobrze w rozsądnym przewidywanym czasie. W związku z tym, że nie jestem w stanie się z Tobą skontaktować, nie mam żadnych pytań. Mogę zmienić na inny debugger, to pitty, bo xdebug wcześniej działało dobrze.

Config:

• MacOSX 10.6.8
• macports 2.1.3
• Apache 2.2.24
• php 5.4

Mamy ten sam problem. Tutaj mamy 10 sekund i więcej na każde żądanie. Widzę, czy usuwam następujące linie w bootstrap.php.cache all times zwraca stan normalny (298 ms).

foreach ($meta as $resource) { 
if (!$resource->isFresh($time)) {
return false;
}
}

Jest możliwe, że mamy złe czasy modyfikacji, ale nie wiemy, jak to naprawić. Ktoś zna rozwiązanie?

Jak napisano w https://stackoverflow.com/a/12967229/6108843 powodem takiego zachowania mogą być Ustawienia maszyn wirtualnych Ubuntu. Należy zsynchronizować datę i godzinę między systemem operacyjnym hosta i gościa, jak wyjaśniono na https://superuser.com/questions/463106/virtualbox-how-to-sync-host-and-guest-time .

Data modyfikacji pliku zmienia wartość hosta podczas przesyłania pliku do maszyny wirtualnej przez FTP. Dlatego filemtime() zwraca złą wartość.

Możesz przenieść APP/var/cache /dev/shm/YourAppName/var/cache. Ale dobrze jest mieć wbudowany kontener w plikach lokalnych również dla autouzupeÅ‚niania IDE i walidacji kodu. W app/AppKernel.php:

public function getCacheDir()
{
    return $this->getVarOrShmDir('cache/' . $this->getEnvironment());
}

public function getLogDir()
{
    return $this->getVarOrShmDir('logs');
}

private function getVarOrShmDir($dir)
{
    $result = dirname(__DIR__) . '/var/' . $dir;

    if (
        in_array($this->environment, ['dev', 'test'], true) &&
        empty($_GET['warmup']) && // to force using real directory add ?warmup=1 to URL
        is_dir($result) && // first time create real directory, later use shm
        file_exists('/bin/mount') && shell_exec('mount | grep vboxsf') // only for VirtualBox
    ) {
        $result = '/dev/shm/' . 'YourAppName' . '/' . $dir . '/' . $this->getEnvironment();
    }

    return $result;
}

Wyłączyłem xdebug i spowodowało to skrócenie czasu ładowania z 17s (tak..) do 0,5 s.

Miałem również problemy z powolnym ładowaniem stron w rozwoju, co może być bardzo frustrujące, gdy poprawiasz CSS lub coś podobnego.

Po odrobinie kopania odkryłem, że dla mnie problem był spowodowany przez Assetic, który rekompilował wszystkie zasoby przy każdym załadowaniu strony:

Http://symfony.com/doc/current/cookbook/assetic/asset_management.html#dumping-asset-files-in-the-dev-environment

Wyłączając korzystanie z kontrolera Assetic byłem w stanie drastycznie zwiększyć obciążenie mojej strony. Jednak, jak stwierdza powyższy link, wiąże się to z kosztami regeneracji zasobów za każdym razem, gdy wprowadzasz do nich zmiany (lub ustawiasz na nich zegarek).

W app_dev, wszystkie pamięci podręczne i automatyczne ładowanie zaczyna się od zera, a to, co znalazłem najbardziej powolne w dev jest orm. Unikam używania orm i skupiam się głównie na dbal z tego powodu, chociaż chyba nie powinienem. Orm jest używany dość często w sf2. Myślę, że orm jest tym, co spowalnia Cię najbardziej w dev. Spójrz na różnicę między konfiguracją dev a konfiguracją prod. Jednak niektóre poprawki do konfiguracji deweloperów mogą sprawić, że rozwój będzie przyjemniejszy i przyjemniejszy.. Po prostu staraj się być świadomy tego, co twoja sprawka. na przykład wyłączenie kontrolera gałązki, a następnie modyfikacja wielu szablonów, będzie frustrujące. Musisz czyścić pamięć podręczną. Ale jak wspomniałeś, jego dev tylko i kiedy jego czas, aby przejść na żywo, symfony przyspieszy dla Ciebie.