Symfony2 Firewall dauert Alter

Question

Ich habe ein Problem mit Symfony2 Firewall-Komponente dauert ewig bei einigen Anfragen.

Ich habe festgestellt, dass es hauptsächlich während AJAX-Anfragen passiert, und sehr spezifische - wenn ich nach einer Entität mit LIKE% ..% Aussagen in Lehre (nicht sicher, dass es darauf ankommt, aber das ist, was ich bemerkt habe;)) .

Der Aufruf der gleichen URL etwas später (1 oder 2s später) führt zu einer "normalen" Firewall-Verarbeitungszeit.

Ich verwende keine externen Datenquellen für die Authentifizierung, alles ist in PostgreSQL gespeichert.

Blick auf die folgenden Zeitplan:

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

Gibt es eine Möglichkeit direkt die Firewall zu debuggen?

Meine Config sieht wie folgt aus:

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 

I Symfony\SecurityBundle und JMSSecurityExtraBundle verwende.

Answer 1

Es ist eher ungewöhnliches Verhalten (es sei denn, Sie tun etwas, naja ... ungewöhnlich;).

Probieren Sie einen der PHP-Profiler, um zu sehen, was vor sich geht. Ich kann XHProf mit XHProf GUI empfehlen. Es ist einfach einzurichten und zu verwenden.

Ich rate nur, aber das Problem könnte mit der von Ihnen erwähnten Datenbankabfrage zusammenhängen. Überprüfen Sie, ob für die in einer Abfrage verwendeten Felder die entsprechenden Indizes gesetzt sind.

Edit: Ich zu diesem Artikel versehentlich stolperte aus dem Blog Symfony verbunden: http://12wiki.blogspot.com.es/2012/11/why-does-symfony-2-firewall-take-so.html

Es scheint ein DNS-Problem zu sein.

Answer 2

Verwenden Sie einen anderen Sitzungshandler. Ich hatte das gleiche Problem in meiner Vagrant Box. Nicht sicher, was es verursacht hat. Einzelheiten finden Sie unter http://ctors.net/2014/04/21/symfony_slow_in_vagrant.

Answer 3

Ich hatte das gleiche Problem und möchte die Lösung mit euch teilen.

Problem verursacht durch Symfony \ Component \ Security \ Http \ Firewall ~ 107.406 ms

Lösung;

In unserem Fall war das Problem Session-Handler, die wir in der Datei php.ini verwendet wurden.

Vorherige Konfiguration;

session.save_handler = files 

Neue Konfiguration;

;session.save_handler = files 

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

Ich habe den Session-Handler in memcached geändert.Da ich Memcached bereits verwendet habe, brauchte ich eine zweite Instanz von memcached oder, wenn ich einen zusätzlichen Port implementiert habe, der von memcached gehört wurde, löste ich dieses Problem;

laufen zu lassen Memcached zwei Ports zu hören, ich memcached.conf

vorherige Konfiguration bearbeiten;

-p 11211 
-l 127.0.0.1 

Neue Konfiguration

#-p 11211 
#-l 127.0.0.1 

-l 127.0.0.1:11211 
-l 127.0.0.1:11212 

und nur Memcached-Instanz neu zu starten, begann Memcached zwei Ports auf derselben Instanz zu hören.

service memcached restart 

Um zu validieren, dass memcached auf neuen Ports lauscht und antwortet, können Sie telnet command ausführen;

telnet 127.0.0.1 11211 
telnet 127.0.0.1 11212 

erwartete Ausgabe ist;

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

Das Ergebnis ist eine sehr schnelle Anwendung;

Ich hoffe, dass diese Lösung würde Ihnen helfen.