4

注意: これは、見掛け倒しの CMS についての不満ではありません。

Apache Bench をいじって、カスタム CMS でひどい結果を得ました。より正確には、次のようになりました。

Requests per second:    0.37 [#/sec] (mean)

プレーンphpファイルで別のテストを実行すると、次の結果が得られました。

Requests per second:    4786.07 [#/sec] (mean)

以前のバージョンの CMS を使用した別のテスト:

Requests per second:    6068.66 [#/sec] (mean)

ウェブサイトは正常に機能しており、問題は検出されませんでした。Google のウェブマスター ツールは、私たちのサイトがページの 80% よりも高速であると報告しています。これは問題ないと思います。

テストは次のとおりです。

ab -t 30 -c 10 http://example.com/

多分ある種のApacheの問題ですか？悪い.htaccess設定、または同様の？

アップデート：

ソケットで簡単なテストを実行しただけで、結果は似ています。ページの読み込みが非常に遅い。別の Web サイトでスクリプトを実行した場合、すべて問題ありません。

また、チャンクの長さの問題についての小さなヒントもあります。(Apache ヘッダー、または行末が間違っていますか?)

サイトは gzip で圧縮されており、詳細ログをオンにすると、応答に次の行が表示されます。

LOG: Response code = 200
LOG: header received:
HTTP/1.1 200 OK
Date: Tue, 04 Oct 2011 13:10:49 GMT
Server: Apache
Set-Cookie: PHPSESSID=ibnfoqir9fee2koirfl5mhm633; path=/
Expires: Sat, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Cache-Control: post-check=0, pre-check=0
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

2ef6

常に同じ場所、HTML ソースの真ん中、そして<!DOCTYPE HTML>また。

助けてください。

更新 #2:

Rex Swain の HTTP ViewerでHTTP ヘッダーをチェックしたところ、次の結果が得られました。

HTTP/1.1·200·OK(CR)(LF)
Date:·Wed,·05·Oct·2011·08:33:51·GMT(CR)(LF)
Server:·Apache(CR)(LF)
Set-Cookie:·PHPSESSID=n88g3qcvv9p6irm1fo0qfse8m2;·path=/(CR)(LF)
Expires:·Sat,·26·Jul·1997·05:00:00·GMT(CR)(LF)
Cache-Control:·no-store,·no-cache,·must-revalidate(CR)(LF)
Pragma:·no-cache(CR)(LF)
Cache-Control:·post-check=0,·pre-check=0(CR)(LF)
Vary:·Accept-Encoding(CR)(LF)
Connection:·close(CR)(LF)
Transfer-Encoding:·chunked(CR)(LF)
Content-Type:·text/html;·charset=UTF-8(CR)(LF)
(CR)(LF)

何か異常に気づきましたか？

4

1 に答える 1

4

通常の Web ブラウザで問題なく動作する場合 (コメントで述べたように)、CMS は Apache Benchmark からのリクエストを別の方法で処理します。

簡単なチェックリスト:

  • AFAIK Apache Benchmark は、Cookie を処理せずに単純なリクエストを送信するだけなので-C、有効な Cookie を設定してみてください (Web ブラウザーから値をコピーします)。
  • Web ブラウザが送信するのとまったく同じヘッダーを CMS に送信してみてください。netcat、HttpFox、またはパケット スニファーを使用して有効な要求のダンプを保存し、欠落しているヘッダーを で設定し-Hます。
  • Apache Benchmark でリクエストを送信している間に、サーバー上の CMS をプロファイリングします。ボトルネックを見つけたのかもしれません。(またはテストされたスクリプトのエントリ ポイント)の最初と最後の行にタイムスタンプがある2 つの貧弱な人のerror_logindex.php呼び出しは、PHP スクリプトがどれほど高速であるかを示し、Apache HTTP サーバーとネットワークのオーバーヘッドを計算するのに役立ちます。
  • HostnameLookups異なるマシンからソケット テストとブラウザ テストを実行すると、DNS の問題である可能性があります ( Apache でオフにします)。同じマシンからそれらを実行してみてください。
  • ab -k ...またはを試してくださいab -H "Connection: close" ...。

CMS は、セッションを初期化するときにコストのかかる初期化を行い、最初の要求を処理するときに発生すると思います。Apache Benchmark は Cookie を CMS に送り返さないため、リクエストごとに新しいセッションが作成され、応答が遅くなります。

2 番目の推測は、CMS が着信 http ヘッダーを異なる方法で処理し、Apache Benchmark によって送信された (またはヘッダーがない) ヘッダーが、コストのかかる/遅い処理をトリガーすることです。Google の Webmaster Tools の報告以来、より適切に見えます。

Apache Benchmark は HTTP 1.0 リクエストを送信します。例:

GET / HTTP/1.0
Host: localhost:9100
User-Agent: ApacheBench/2.3
Accept: */*

あなたのサーバーは Keep-Alive 設定に関する http ヘッダーを送信していないように見えますが、クライアントが HTTP 1.0 を使用している場合、クライアントは keep-alive を使用していると想定しています。これは RFC 準拠の動作ではありません。

RFC 2616、19.6.2 Compatibility with HTTP/1.0 Persistent Connectionsから:


一部のクライアントとサーバーは、HTTP/1.0 クライアントとサーバーでの永続的な接続の以前の実装との互換性を望む場合が
あります。HTTP/1.0 での永続的な接続は
、既定の動作ではないため、明示的にネゴシエートされます。

デフォルトでは、Apache Benchmark はキープアライブを使用しないため、ソケットを閉じるために応答が到着するまで待機します。サーバーは、15 秒間アイドル状態になると閉じます。wget を使用したメイン ページのダウンロードにも 15 秒かかります。Wget もリクエストで HTTP 1.0 を使用します。

ab単純なphpファイルを使用して同じサーバー上でうまく機能するため、CMSのPHPコードのバグだと思います。-kとにかく、キープアライブ接続 ( )を使用して回避できます。

ab -k -t 30 -c 10 http://example.com/

または永続的な接続を明示的に無効にする:

ab -H "Connection: close" -t 30 -c 10 http://example.com/

しかし、それはまだサーバー側の問題であり、元のabコマンドは正しいです。

このバグは、おそらく HTTP 1.0 クライアント (Apache Benchmark、wget など) のみに影響し、通常のブラウザーを使用するクライアントは気付かないことに注意してください。

于 2011-10-10T17:00:56.560 に答える