本文介绍了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\SecurityBundleJMSSecurityExtraBundle.

推荐答案

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

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 防火墙需要很长时间的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-06 06:33