Zapora Symfony2 ma wiek

Question

Mam problem z komponentem zapory Symfony2, biorąc wieki na niektóre żądania.

Zauważyłem, że dzieje się tak głównie podczas żądań AJAX, i bardzo konkretnych - kiedy szukam podmiotu używającego LIKE% ..% stwierdzeń w doktrynie (nie jestem pewien, czy to ma znaczenie, ale to właśnie zauważyłem;)) .

Wywołanie tego samego adresu URL nieco później (1 lub 2 sekundy później) powoduje "normalny" czas przetwarzania zapory.

Nie używam zewnętrznych źródeł danych do uwierzytelniania, wszystko jest przechowywane w PostgreSQL.

Spójrz na poniższy osi czasu:

timeline http://f.cl.ly/items/1a2Y0T062E0H2Z3t0g27/Zrzut%20ekranu%202012-11-19%20o%2018.26.11.png

Czy istnieje sposób debugować zapory bezpośrednio?

Mój config wygląda następująco:

security: 
firewalls: 
    admin_area: 
     provider: db_users 
     pattern: ^/admin 
     anonymous: ~ 
     form_login: 
      login_path: /admin/login 
      check_path: /admin/login-check 
     logout: 
      path: /admin/logout 
      target: /admin 
     switch_user: { role: ROLE_SUPERADMIN, parameter: _become_user } 

    secured_area: 
     pattern: ~ 
     anonymous: ~ 
     http_basic: 
      realm: "Secured Demo Area" 

access_control: 
    - { path: ^/admin/clip-manager/clip/encode/*, roles: IS_AUTHENTICATED_ANONYMOUSLY, ip: 127.0.0.1 } 
    - { path: ^/admin/login, roles: IS_AUTHENTICATED_ANONYMOUSLY } 
    - { path: ^/admin/login-check, roles: IS_AUTHENTICATED_ANONYMOUSLY } 
    - { path: ^/admin, roles: [ROLE_ADMIN_LOGIN, ADMIN_AREA] } 

providers: 
    db_users: 
     entity: { class: Webility\Bundle\AppUserBundle\Entity\User, property: username } 

encoders: 
    Webility\Bundle\AppUserBundle\Entity\User: 
     algorithm:   sha256 
     iterations:   3 
     encode_as_base64: false 

acl: 
    connection: default 

Używam Symfony\SecurityBundle i JMSSecurityExtraBundle.

Answer 1

To dość niezwykłe zachowanie (chyba, że ​​robisz coś, cóż ... nietypowe;).

Spróbuj użyć jednego z profilerów PHP, aby zobaczyć, co się dzieje. Mogę polecić XHProf z XHProf GUI. Jest łatwy w konfiguracji i obsłudze.

Po prostu zgaduję, ale problem może być związany z zapytaniem bazy danych, o którym wspomniałeś. Sprawdź, czy pola używane w zapytaniu mają ustawione odpowiednie indeksy.

Edit: I przypadkowo natknął się na temat tego artykułu związanego z bloga symfony: http://12wiki.blogspot.com.es/2012/11/why-does-symfony-2-firewall-take-so.html

wydaje się być kwestią DNS.

Answer 2

Spróbuj użyć innej procedury obsługi sesji. Miałem ten sam problem w moim pudełku Vagrant. Nie jestem pewien, co go spowodowało. Aby uzyskać szczegółowe informacje, patrz: http://ctors.net/2014/04/21/symfony_slow_in_vagrant.

Answer 3

Miałem ten sam problem i chcę podzielić się z Wami rozwiązaniem.

Problem spowodowanych przez Symfony \ Komponent \ Security \ http \ Zapora ~ 107406 ms

rozwiązania;

W naszym przypadku problemem był program obsługi sesji, z którego korzystaliśmy w pliku php.ini.

Poprzednia konfiguracja;

session.save_handler = files 

Nowa konfiguracja;

;session.save_handler = files 

session.save_handler = memcached 
session.save_path = "127.0.0.1:11212" 

Zmieniłem obsługę sesji na memcached.Ponieważ już używałem memcached, potrzebowałem drugiej instancji memcached lub gdy zaimplementowałem dodatkowy port słuchany przez memcached rozwiązał ten problem;

Aby uruchomić memcached słuchać dwa porty, edytować memcached.conf

poprzedniej konfiguracji;

-p 11211 
-l 127.0.0.1 

Nowa konfiguracja

#-p 11211 
#-l 127.0.0.1 

-l 127.0.0.1:11211 
-l 127.0.0.1:11212 

i właśnie ponownym memcached instancji memcached zaczął słuchać dwa porty na tej samej instancji.

service memcached restart 

Aby sprawdzić, czy memcached nasłuchuje i odpowiada na nowe porty, możesz uruchomić polecenie telnet;

telnet 127.0.0.1 11211 
telnet 127.0.0.1 11212 

oczekiwane wyjście;

Trying 127.0.0.1... 
Connected to 127.0.0.1. 
Escape character is '^]'. 

Wynikiem jest bardzo szybka aplikacja;

Mam nadzieję, że to rozwiązanie będzie pomóc.