7

Symfony2 ファイアウォール コンポーネントが一部のリクエストで時間がかかるという問題があります。

主にAJAXリクエスト中に発生することに気付きました-教義でLIKE %..%ステートメントを使用してエンティティを検索するとき(それが重要かどうかはわかりませんが、それは私が気づいたことです;))。

少し後 (1 または 2 秒後) に同じ URL を呼び出すと、「通常の」ファイアウォール処理時間になります。

認証に外部データ ソースを使用していません。すべてが PostgreSQL に保存されています。

次のタイムラインを見てください。

タイムライン

ファイアウォールを直接デバッグする方法はありますか?

私の設定は次のようになります：

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います。

4

3 に答える 3

5

私は同じ問題を抱えていたので、解決策を皆さんと共有したいと思います。

サーバーの応答時間の増加

Symfony\Component\Security\Http\Firewall が原因の問題 ~ 107406 ms

申請スケジュール

解決;

私たちの場合、問題は、php.ini ファイルで使用していたセッション ハンドラーでした。

以前の構成。

session.save_handler = files

新しい構成;

;session.save_handler = files

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

セッション ハンドラを memcached に変更しました。すでに memcached を使用しているため、memcached の 2 番目のインスタンスが必要でした。

memcached を実行して 2 つのポートをリッスンするには、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 は同じインスタンスで 2 つのポートをリッスンし始めました。

service memcached restart

memcached が新しいポートをリッスンして応答することを検証するには、telnet コマンドを実行します。

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 '^]'.

その結果、アプリケーションは非常に高速になります。

最終申請スケジュール

このソリューションがお役に立てば幸いです。

于 2016-11-15T19:28:45.450 に答える
2

それはかなり異常な動作です (あなたが何かをしていない限り、まあ... 異常です;)。

PHP プロファイラーの 1 つを使用して、何が起こっているかを確認してみてください。XHProf GUIでXHProfをお勧めします。セットアップと使用は簡単です。

推測ですが、問題はあなたが言及したデータベースクエリに関連している可能性があります。クエリで使用されるフィールドに適切なインデックスが設定されているかどうかを確認してください。

編集: Symfony ブログからリンクされているこの記事を偶然見つけました: http://12wiki.blogspot.com.es/2012/11/why-does-symfony-2-firewall-take-so.html

DNSの問題のようです。

于 2012-11-19T21:13:04.993 に答える
2

別のセッション ハンドラを使用してみてください。Vagrant ボックスでも同じ問題が発生しました。何が原因なのかわからない。詳細については、 http://ctors.net/2014/04/21/symfony_slow_in_vagrantを参照してください。

于 2014-04-21T19:31:38.290 に答える