2017-12-04 15 views
-1

Google PageSpeed Insightsを使用してウェブサイトの掲載結果を分析していますが、主な問題はサーバーの応答時間が遅く、平均で約1.5-2秒です。 Googleは200msを達成しようとすることをお勧めします。中速テキストを使用したパフォーマンスの問題

私が確立したことは、データベースからデータを取得するためのクエリが非常に重要なパフォーマンスの問題を引き起こしていることです。私のウェブサイトは、ウェブサイトのセクションを取得するためにキャッシュを広範に利用しています。ウェブページ全体は、通常、キャッシュテーブルからの5つのデータベースクエリから生成することができます。

私はハードコードこれに対する私の戻り値は(注意して選択「これはテストです」)とき:

$sql = "SELECT 'This is a test' 
     FROM cache 
     WHERE url = ? 
     AND language = ? 
     AND currency = ?"; 
$stmt = $conn->prepare($sql); 
if (!$stmt) { 
    ThrowDBError($conn, $stmt, $sql); 
} 
$stmt->bind_param('sss', $url, $language, $currency); 
if (!$stmt->execute()) { 
    ThrowDBError($conn, $stmt, $sql); 
} 
$stmt->bind_result($cache); 
$stmt->fetch(); 
$stmt->close(); 

サーバーの応答速度が0.5秒に低下します。 - ウェブサイトは、キャッシュテーブルになります問い合わせる5のために2秒

$sql = "SELECT page_body 
     FROM cache_copy 
     WHERE url = ? 
     AND language = ? 
     AND currency = ?"; 

$stmt = $conn->prepare($sql); 
if (!$stmt) { 
    ThrowDBError($conn, $stmt, $sql); 
} 
$stmt->bind_param('sss', $url, $language, $currency); 
if (!$stmt->execute()) { 
    ThrowDBError($conn, $stmt, $sql); 
} 
$stmt->bind_result($cache); 
$stmt->fetch(); 
$stmt->close(); 

サーバーの応答時間が1.5に一貫ジャンプ:私はこのような実際のデータ列page_bodyを、選択するために、それを元に戻すとき。

キャッシュテーブルには8,000行しか含まれていないため、正しくインデックスを作成したと思います。ページの列column_bodyは中文です - 誰でもmediumtextを使用してパフォーマンス関連の問題を知っていますか?私はなぜそれがロード時間に1.5秒を追加するのか理解できません。

CREATE TABLE `cache` (
    `id` int(11) NOT NULL AUTO_INCREMENT, 
    `url` varchar(255) NOT NULL, 
    `language` varchar(2) NOT NULL, 
    `currency` varchar(3) NOT NULL, 
    `page_body` mediumtext NOT NULL, 
    `cached_time` datetime NOT NULL, 
    PRIMARY KEY (`id`), 
    UNIQUE KEY `url, language, currency` (`url`,`language`,`currency`) USING BTREE, 
    KEY `cached_time` (`cached_time`) USING BTREE 
) ENGINE=MyISAM AUTO_INCREMENT=1 DEFAULT CHARSET=utf8; 

任意のアイデア:ここ

は、キャッシュテーブルのDDLのですか? 多くのお礼ありがとうございます

+0

1つのページを生成するために5つのクエリを実行する必要がある場合は、この長い時間がかかります。コードには何も問題はありませんが、キャッシングに対する貧弱なアプローチが使用されます..キャッシュでのキャッシュは、クライアント側で共有されています..データベース側のビューは自動的にクエリをキャッシュするために使用されます..場合によっては、Webサーバー上で高CPUが見える場合はload ballancerを使用する必要があります..多くの最適化はフロントエンドjs/css/imagesのブラウザgzip圧縮とキャッシュ..また、これを確認してくださいhttps://stackoverflow.com/a/7875699/3254405 – numbtongue

+0

返信いただきありがとうございます。私の営業では、ハードコーディングされたテキストを返す5つのクエリをテストしました(これはテストです)、レスポンスタイムには何の違いもありませんでした。問題は、クエリ自体を実行するオーバーヘッドではなく、実際のデータを返すようです。問題は、私がテーブルから実際のデータを取得したときのようです。 – BigMeaty

+1

追加のテストとして、レビューコメントにvarchar(1000)を使用するレビューを格納するために使用されるテーブルを複製しました。重複テーブルでは、タイプをmediumtextに変更します。 varcharで高速応答。中文字では遅い。問題は間違いなくデータ型としてmediumtextを使うことにあります。 – BigMeaty

答えて

0

返される行の数はいくつですか? 1行しか返さない場合は、200ミリ秒以下でなければなりません。

ああ!問題を参照してください。あなたはMyISAMを使用しています。しないでください。 InnoDBに切り替えます。

実際のテーブルがcacheのようなものであれば、実質的に同じ速度が得られます。私はあなたのキャッシュを取り除くことをお勧めします。

+0

この問題は、ここで説明するように、mysqliの既知の制限に起因しています。 https://bugs.php.net/bug.php?id=51386 解決策は、次のようにstore_result()を使用することです。 if(!$ stmt-> execute()){ ThrowDBError($ conn、$ stmt、$ sql); } $ stmt-> store_result(); $ stmt-> bind_result($ cache); – BigMeaty

関連する問題