2012-11-19 10 views
6

Ho un problema con il componente firewall Symfony2 che impiega anni su alcune richieste.Il firewall Symfony2 impiega anni

Ho notato che succede principalmente durante le richieste AJAX, e molto specifiche - quando cerco un'entità usando le dichiarazioni LIKE% ..% in dottrina (non sono sicuro che importi, ma è quello che ho notato;)) .

Chiamare lo stesso URL un po 'più tardi (1 o 2 secondi dopo) determina il tempo di elaborazione del firewall "normale".

Non utilizzo alcuna origine dati esterna per l'autenticazione, tutto è archiviato in PostgreSQL.

Guardate il seguente calendario:

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

C'è un modo per eseguire il debug direttamente il firewall?

mio config si presenta così:

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 

Sto usando Symfony\SecurityBundle e JMSSecurityExtraBundle.

+2

Provare a utilizzare un indirizzo IP effettivo (anziché il nome host) per il server del database. http://12wiki.blogspot.com.es/2012/11/why-does-symfony-2-firewall-take-so.html – Cerad

+1

Ci sono molte richieste AJAX che elaborano contemporaneamente o è l'unica? – AlterPHP

+0

Sì, è l'unico. Anche se ... È una ricerca dal vivo, es. cerca come tipi di utente (con ritardo di 100 ms quando l'utente interrompe la digitazione) e tutte le precedenti richieste AJAX vengono interrotte. Ma in effetti potrebbe essere possibile che le richieste vengano interrotte, ma sono ancora in fase di elaborazione da parte del server. –

risposta

1

È un comportamento piuttosto insolito (a meno che tu non stia facendo qualcosa, beh ... insolito;).

Prova a utilizzare uno dei profiler PHP per vedere cosa sta succedendo. Posso consigliare XHProf con XHProf GUI. È facile da configurare e utilizzare.

Sto solo supponendo, ma il problema potrebbe essere correlato alla query del database che hai menzionato. Verifica se i campi utilizzati in una query hanno set di indici appropriati.

Edit: ho accidentalmente imbattuto in questo articolo collegato dal blog Symfony: http://12wiki.blogspot.com.es/2012/11/why-does-symfony-2-firewall-take-so.html

Sembra essere un problema di DNS.

+0

Sì, l'ho trovato prima, ma sfortunatamente non era una soluzione per me :( –

+0

In tal caso, iniziare la profilatura;) –

3

Ho avuto lo stesso problema e voglio condividere la soluzione con voi ragazzi.

Server Response Time increase

problema causato da, Symfony \ Component \ Security \ Http \ Firewall ~ 107406 ms

Application Timeline

Solution;

Nel nostro caso il problema era il gestore di sessione che usavamo sul file php.ini.

Configurazione precedente;

session.save_handler = files 

Nuova configurazione;

;session.save_handler = files 

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

Ho modificato il gestore di sessione in memcached.Poiché già utilizzavo memcached, avevo bisogno di una seconda istanza di memcached o mentre implementavo la porta aggiuntiva ascoltata da memcached risolto quel problema;

per eseguire memcached per ascoltare due porte, modifico memcached.conf

configurazione precedente;

-p 11211 
-l 127.0.0.1 

Nuova configurazione

#-p 11211 
#-l 127.0.0.1 

-l 127.0.0.1:11211 
-l 127.0.0.1:11212 

e proprio riavvio esempio memcached, memcached iniziato ad ascoltare due porte stessa istanza.

service memcached restart 

Per convalidare che memcached ascolta e risponde alle nuove porte, è possibile eseguire il comando telnet;

telnet 127.0.0.1 11211 
telnet 127.0.0.1 11212 

uscita prevista;

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

Il risultato è un'applicazione molto veloce;

Final Application Timeline

spero che questa soluzione avrebbe aiutato.

Problemi correlati