Symfony2 防火墙需要很长时间

问题描述

Symfony2 防火墙组件在处理某些请求时遇到问题.

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

我注意到它主要发生在 AJAX 请求期间，而且是非常具体的请求 - 当我在学说中使用 LIKE %..% 语句搜索实体时(不确定是否重要，但这就是我注意到的；)).

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 ;)).

稍后(1 或 2 秒后)调用相同的 URL 会导致正常"的防火墙处理时间.

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

我没有使用任何外部数据源进行身份验证，所有内容都存储在 PostgreSQL 中.

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

请看以下时间表:

有没有办法直接调试防火墙?

Is there a way to debug the firewall directly?

我的配置如下:

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

我正在使用 Symfony\SecurityBundle 和 JMSSecurityExtraBundle.

推荐答案

我遇到了同样的问题，想与大家分享解决方案.

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

Symfony\Component\Security\Http\Firewall 引起的问题 ~ 107406 ms

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

解决办法；

在我们的案例中，问题是我们在 php.ini 文件上使用的会话处理程序.

On our case the problem was session handler that we were use on php.ini file.

之前的配置；

session.save_handler = files

新配置；

;session.save_handler = files

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

我将会话处理程序更改为 memcached.因为我已经在使用 memcached，所以我需要第二个 memcached 实例，或者当我实现了 memcached 侦听的额外端口时解决了这个问题；

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;

为了运行 memcached 来监听两个端口，我编辑了 memcached.conf

To run memcached to listen two ports, I edit memcached.conf

之前的配置；

-p 11211
-l 127.0.0.1

新配置

#-p 11211
#-l 127.0.0.1

-l 127.0.0.1:11211
-l 127.0.0.1:11212

刚刚重启memcached实例，memcached开始监听同一个实例上的两个端口.

and just restarting memcached instance, memcached started to listen two ports on same instance.

service memcached restart

要验证 memcached 在新端口上侦听和响应，您可以运行 telnet 命令；

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

预期输出为；

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

结果是应用非常快；

希望这个解决方案能帮到你.

I hope this solution would help you.

这篇关于Symfony2 防火墙需要很长时间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！