6

数日前にMagentoがリリースした最近のOptimizingMagentoForPeakPerformanceホワイトペーパーにすでに気付いている方もいらっしゃるかもしれません。これは主にEEユーザー向けに書かれていますが、Communityエディションのヒントのほとんども使用できると思います。

よく読んだ後、私は先に進み、提案されたNginx + fastcgi /proxyキャッシュ構成をMagentoの標準仮想ホスト構成といくつかのマイナーな改善とマージしました。これが私が思いついたものです：

fastcgi_cache_path /tmp/fcgi levels=1:2 keys_zone=MAGE:64m max_size=128m inactive=10h;

server {
listen  99999; ## Nginx port
server_name  domain.com www.domain.com;
root  /www/magento; ## App folder
index  index.php;

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires  max;
    access_log  off;
    log_not_found  off;
}

location /index {
    try_files  $uri @fcgi_nocache;
}

location /checkout {
    try_files  $uri @fcgi_nocache;
}

location / {
    try_files  $uri @fcgi_cache;
    if ($cookie_frontend) { return 413; }
    if ($cookie_CUSTOMER_AUTH) { return 413; }
    if ($request_method = POST ) { return 413; }
    error_page 413 = @fcgi_nocache;
}

# Deny access to hidden files
location ~ (/(app/|includes/|/pkginfo/|var/|report/config.xml)|/\.svn/|/.hta.+) {
    deny  all;
}

# Forward paths like /js/index.php/x.js to relevant handler
location ~ .php/ {
    rewrite ^(.*.php)/ $1 last;
}

# Manually purge pages
location ~ /purge(/.*) {
    fastcgi_cache_purge MAGE "$scheme$request_method$host$1";
}

location @fcgi_cache {
    #if (!-e $request_filename) { rewrite / /index.php last; } ## Catch 404s that try_files miss
    fastcgi_pass  unix:/var/spool/phpfpm.sock; ## php-fpm socket
    include  fastcgi_params;
    fastcgi_connect_timeout  60;
    fastcgi_send_timeout  60;
    fastcgi_read_timeout  60;
    fastcgi_buffer_size  4k;
    fastcgi_buffers  512 4k;
    fastcgi_busy_buffers_size  8k;
    fastcgi_temp_file_write_size  256k;
    fastcgi_intercept_errors  off;        
    fastcgi_param SCRIPT_FILENAME  $document_root/index.php;
    fastcgi_param SCRIPT_NAME  /index.php;
    #fastcgi_keep_conn  on; # NGINX 1.1.14        
    fastcgi_temp_path  /tmp/fcgi2 1 2;

    fastcgi_cache  MAGE;
    #fastcgi_cache_key  "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; ## Original
    fastcgi_cache_key  "$scheme$request_method$host$request_uri$http_if_modified_since$http_if_none_match";
    #fastcgi_cache_lock  on 5s; # NGINX 1.1.12
    fastcgi_cache_valid  200 301 302 304 1h;
    fastcgi_hide_header  "Set-Cookie";

    if ($http_cookie !~ "X-Store=1" ) {
        add_header Set-Cookie "X-Store=1; path=/";
    }

    fastcgi_ignore_headers  "Cache-Control" "Expires" "Set-Cookie";
    fastcgi_cache_min_uses  1;
    fastcgi_cache_valid  30m;
    fastcgi_cache_use_stale  updating error timeout invalid_header http_500;
    fastcgi_cache_bypass  $cookie_EXTERNAL_NO_CACHE $cookie_CUSTOMER_AUTH;
    fastcgi_no_cache  $cookie_EXTERNAL_NO_CACHE $cookie_CUSTOMER_AUTH;

    #add_header  X-Cache-Status $upstream_cache_status; # Test
}

location @fcgi_nocache {
    #if (!-e $request_filename) { rewrite / /index.php last; } ## Catch 404s that try_files miss
    fastcgi_pass  unix:/var/spool/phpfpm.sock; ## php-fpm socket
    include  fastcgi_params;
    fastcgi_connect_timeout  60;
    fastcgi_send_timeout  60;
    fastcgi_read_timeout  60;
    fastcgi_buffer_size  4k;
    fastcgi_buffers  512 4k;
    fastcgi_busy_buffers_size  8k;
    fastcgi_temp_file_write_size  256k;
    fastcgi_intercept_errors  off;        
    fastcgi_param SCRIPT_FILENAME  $document_root/index.php;
    fastcgi_param SCRIPT_NAME  /index.php;
    #fastcgi_keep_conn  on; # NGINX 1.1.14        
    fastcgi_temp_path  /tmp/fcgi2 1 2;

    if ($http_cookie !~ "X-Store=1" ) {
        add_header Set-Cookie "X-Store=1; path=/";
    }
    #add_header  X-Cache-Status $upstream_cache_status; # Test
}

}

いくつかのテストの後、結果はABを介して印象的であるように見えますが、それらが正確であり、キャッシュシステムが期待どおりに完全に機能しているかどうかは、実際にはそれほど自信がありません。誰かが@fcgi_cacheと@fcgi_nocacheとCookieの背後にある実際のロジックを詳しく説明できますか？キャッシュされたページを実際に取得しているのは誰ですか？PHP-FPMがオフ（？）の場合、古いキャッシュは機能していないようです。私は少し立ち往生していて、取得しているさまざまなヘッダーと多少混乱しています。

誰か提案？

4

2 に答える 2

2

このタイプの構成は、magento にはまったく役に立たず、最大の「ダミー」スループットを得るためにのみ使用され、この構成ロジックはいくつかの場所で壊れます。ホール パンチング フル ページ キャッシュ拡張機能を構成することをお勧めします。これにより、動的ブロックが再挿入され、サイトが常にキャッシュに保持されます。新しく追加された製品や数量の変更などのキャッシュの更新も必要です。

于 2012-11-14T11:50:59.240 に答える
0

これは古い質問であることは承知していますが、誰かがこのスレッドに出くわした場合に備えて、最新の Magento リリース (>=1.13 エンタープライズ & >=1.8 コミュニティ) がこの nginx キャッシング方法を破ることを指摘したかっただけです。

アップグレードしてキャッシュを有効にすると、キャッシュされたページを見ているユーザーはカートに追加できなくなります。この背後にある理由は、クロス サイト スクリプティングを防ぐために、Magento が [カートに追加] ボタンの URL フォーム キーに追加したためです。nginx キャッシュをオンにすると、最初の URL フォーム キーがキャッシュされ、次のユーザー セットはセッションに関連付けられていない無効なフォーム キーをロードします。私が知る限り、パンチnginxキャッシュに穴を開ける方法もありません。これにより、（ADMを引用すると）「nginxキャッシングはまったく役に立たなくなります」。パンチ nginx キャッシュに穴を開ける方法があるかどうかを誰かが知っているなら、私はすべて耳にします。

nginx キャッシュを引き続き使用する場合は、キャッシュを無効にせずに立ち上がる方法を確認することを強くお勧めします。これにより、最新の Magento リリースにアップグレードする際の多くの頭痛の種が解消されます。

于 2014-06-03T15:09:27.460 に答える