Symfony2 firewall takes ages

Question

I have a problem with Symfony2 firewall component taking ages on some requests.

I've noticed that it mainly happens during AJAX requests, and very specific ones - when I search for an entity using LIKE %..% statements in doctrine (not sure it matters, but that's what I noticed ;)).

Calling the same URL a little later (1 or 2s later) results in "normal" firewall processing time.

I am not using any external data sources for authentication, everything is stored in PostgreSQL.

Look at the following timeline:

Is there a 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 want to share the solution with you guys.

Problem caused by, Symfony\Component\Security\Http\Firewall ~ 107406 ms

Solution;

On our case the problem was session handler that we were use on 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. As I already using memcached I needed second instance of memcached or as I implemented additional port listened by memcached solved that issue;

To run memcached to listen 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 memcached instance, memcached started to listen two ports on same instance.

service memcached restart

To validate that memcached listens and responds on new ports you can run telnet command;

telnet 127.0.0.1 11211
telnet 127.0.0.1 11212

expected output is;

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

The result is very fast application;

I hope this solution would help you.

Answer 2

It's rather unusual behaviour (unless you're doing something, well... unusual ;).

Try using one of the PHP profilers to see what's going on. I can recommend XHProf with XHProf GUI. It's easy to set up and use.

I'm just guessing, but the problem might be related to the database query you mentioned. Check if fields used in a query have appropriate indexes set.

Edit: I accidentally stumbled on this article linked from the Symfony blog: http://12wiki.blogspot.com.es/2012/11/why-does-symfony-2-firewall-take-so.html

It seems to be a DNS issue.

Answer 3

Try using a different session handler. I had the same issue in my Vagrant box. Not sure what caused it. See http://ctors.net/2014/04/21/symfony_slow_in_vagrant for details.