Symfony2 Firewall Takes Time

Question

I have a problem with a Symfony2 firewall component that accepts some requests.

I noticed that this mainly happens during AJAX requests, and very specific ones - when I look for an entity using LIKE% ..% statements in a doctrine (not sure if this is important, but this is what I noticed;)).

Calling the same URL a little later (after 1 or 2 seconds) leads to the "normal" firewall processing time.

I do not use any external data sources for authentication, everything is stored in PostgreSQL.

Look at the following timeline:

Is there any way to debug the firewall directly?

My config looks like this:

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 am using Symfony\SecurityBundle and JMSSecurityExtraBundle .

Answer 1

I had the same problem and I want to share with you guys.

Symfony \ Component \ Security \ Http \ Firewall ~ 107406 ms problem

Decision

In our case, the problem was the session processing that we used in the php.ini file.

Previous configuration;

 session.save_handler = files 

New configuration;

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

I changed the session handler to memcached. Since I already use memcached, I need a second instance of memcached, or when I implemented the additional port that memcached listened to, I solved this problem;

To start memcached to listen on two ports, I edit memcached.conf

Previous configuration;

 -p 11211 -l 127.0.0.1 

New configuration

 #-p 11211 #-l 127.0.0.1 -l 127.0.0.1:11211 -l 127.0.0.1:11212 

and just restarting the memcached instance, memcached started listening on two ports in the same instance.

 service memcached restart 

To verify that memcached is listening and responding to new ports, you can run the telnet command;

 telnet 127.0.0.1 11211 telnet 127.0.0.1 11212 

Expected Result:

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

The result is very fast,

I hope this solution helps you.

Answer 2

Try using a different session handler. I had the same problem in my box of strollers. Not sure what caused this. See http://ctors.net/2014/04/21/symfony_slow_in_vagrant for more details.

Answer 3

This is a rather unusual behavior (if you are not doing something, well ... unusual;).

Try using one of the PHP profilers to see what happens. I can recommend XHProf with the XHProf GUI . It is easy to configure and use.

I just guess, but the problem could be related to the database query you were talking about. Check if the fields used in the query are set with the corresponding indexes.

Edit: I accidentally stumbled upon this article related to the Symfony block: http://12wiki.blogspot.com.es/2012/11/why-does-symfony-2-firewall-take-so.html

This seems to be a DNS issue.