Joomla 1.5のラジカルキャッシング

無料のCMSは常に妥協であり、多くの明らかな要素間の妥協です。 彼らはすべての人に長い間知られています。 もちろん、さまざまな無料CMSの中から、スピード、初心者の開発のしやすさなど、いくつかの個別のノミネートで優れているか悪いかを区別できます。 しかし、この記事はそれについてではありません。 キャッシングを使用してJoomlaのページ生成速度の問題をうまく解決した経験を共有したいだけです。 さらに、 "レベル" index.phpでのキャッシングは非常に過激です。

この話は根本的な革新ではなく、栄冠を装うわけではないことをすぐにお知らせしたいと思います。 私のソリューションが、少なくとも誰かが「小さな血」で古いJoomlaプロジェクトの寿命を延ばすのに役立つことを願っています。


すぐに私の住所に対する批判を未然に防ぎ、いくらかの寛大さを求めたいです。 事実、私はプロのプログラマーではありません。 私は小さな印刷会社のテクニカルディレクターです。 プログラミングの分野での私の努力はすべて、会社のITコストを削減するための試みに過ぎません。

私には、次の状況が非常に典型的であるように思われます（いずれにせよ、アマチュアプログラマーの間では、私は自分自身を考慮しています）。 一度、自分用のサイトを書き始めて、私はJoomlaを選びました。 それほど先見的ではありませんが、明らかな決定でした。 時間が経つにつれて、Joomlaのいくつかの制限に遭遇しました。その1つはページ生成の時間でした。

トピックに参加している人にとっては、ヘビーウェイトフレームワーク、プラグイン、モジュールのロードにより、一般的なCMSの汎用性に対する支払いとして、一般的なページ生成時間が約1〜2秒になることはおそらく秘密ではありません。 より強力な鉄の使用は、特に問題を解決しません。 CMSがリクエストごとにデータベースに対して数十（または100）の呼び出しを行う場合、鉄（およびそのすべてのコンポーネント）のパフォーマンスを1桁向上させる必要があります。

私は、joomla 1.5自体もキャッシングに関して何かできると言わなければなりません。 残念なことに、私は正確に何を覚えていません、なぜなら 長く掘り下げました。 しかし、このキャッシングには実質的に意味がないことを私は間違いなく覚えています。

最適化と高速化の最初の試みは、Joomla Virtuemartコンポーネントをキャッシュするための松葉杖を書くことでした。 Virtuemartは、Joomlaのオンラインストアのよく知られている（「ジャンルの古典」と言えます）コンポーネントです。 もちろん、彼についての多くの卑劣な言葉を言って読むことができます。 それには、立派な年齢、そこにリファクタリングが存在しないこと、開放性と普遍性で終わることなど、多くの理由で決定された多くの欠点があります。 それにもかかわらず、それ（Virtuemart）は機能し、多くの人にとっては、いわば「電子ビジネスの世界」への簡単な入り口です。 とにかく、Joomlaを「適切に調理する」方法、どのコンポーネントとそれらを使用するかに焦点を当てたくない。 それどころか、すでに間違って調理されている場合の対処法を共有したいと思います。 このソリューションは、「何にも触れないで、何も変更しないで、より速く動作させるためにもっと速くするだけ」と簡単に説明できます。

私の場合、Virtuemartはディレクトリモードで使用されます。これにより、キャッシング松葉杖の作成タスクが多少簡素化されます。 私がそれをどのようにしたかを説明するのは意味がありません、tk。 その結果、ダウンロード速度に大きな影響はありませんでした。 結局のところ、私はJoomlaにリソースを愛するコンポーネント、たとえばJoomFishがまだあります。 さらに、Virtuemartがキャッシュを放棄するためには、Joomlaフレームワーク全体をダウンロードする必要がありますが、それ自体には時間がかかります。

ダウンロードを高速化するソリューションを探し始めました。 共有ホスティングの問題により状況が悪化しました。隣人には最適なサイトがあったため、サーバーが非常にビジーであり、生成時間が10〜20秒に達することがありました。
熟考すると、少なくとも合理的な領域では、joomlaの最適化は行われません。その後、joomlaはjoomlaのままであるため、時々加速しません。つまり、この目標は私の前に立っていました。 したがって、フロントエンドの作成を検討することが決定されました。 私はすぐに拒否し、既製のソリューションを持つオプションを検討しませんでした（それらがあるかどうかさえ知りません） 欲望も時間もありませんでした。 さらに、私のjoomlaのコピーは適切な場所で完成しており、典型的な（Joomlaの典型的な）ソリューションはそのままで機能するという事実ではありません。

結果として何が起こったのか：

• サイトのほぼすべてのページを不正ユーザーとしてキャッシュする
• 100-200 msのオーダーの生成速度
• キャッシュからページを返すときのデータベース呼び出しの最小数は1〜2個です。ページに動的（または定期的に更新され、ページ自体よりも少ないTTL）モジュールが含まれる場合はさらに多くなります
• joomlaフレームワーク自体を起動せずにjoomlaセッションメカニズムに統合します。これにより、キャッシュされたページ内のすべての非同期機能が正常に機能するため、 サイトのキャッシュを（単一のフレームワークをロードせずに）歩いているユーザーからPOSTまたはGETを受信すると、joomlaはデータベースでセッションを確認し、すべてが正常に機能します。 少なくとも標準のAJAXコンポーネントであるJCommentsとProofReaderが奇跡的に私を獲得しました。また、自作のAJAXコンポーネントもいくつか獲得しました。

実装を検討する

• 私の場合、フロントエンド全体をindex.phpファイルに収めています。これは、生成が開始および終了するのがその中にあるためです。
• まず、URLを分析して、このページでキャッシュが許可されているかどうかを確認します。 私の場合、joomlaはSEFリンク生成モジュールを使用します。このモジュールは、サイトのほぼすべてのページのリンクをキリル文字のページに置き換えます。 したがって、私の場合、/ index.phpがあるすべてのリンクはキャッシュすることを禁止されています
  
  $fe_disalolwed_urls_array = array(
"/index"
);
.........................

if (fe_check_url($fe_disalolwed_urls_array,$fe_uri_cp1251)) {}

.........................

function fe_check_url($a, $i)
{
foreach ($a as $aa)
{
if (substr($i,0,strlen($aa)) == $aa)
{
return false;
}
}
return true;
}
  
  この操作にはデータベースへのアクセスは必要ありません。すべてがindex.phpファイルで行われます。
  ページのキャッシュが禁止されている場合は、フレームワークの読み込みなどの通常のページ生成に進みます。 など
  
  
• また、リクエストに特別なCookieが存在するかどうかもチェックします。これは、joomlaが「remember me」鳥でログインしたユーザーに設定します。 このCookieの名前はmd5（ '_ secret_JLOGIN_REMEMBER'）として定義されています。ここで、_secret_はjoomlaインスタンスのインストール中に生成されるランダムな行で、管理パネルでこの行を見つけることができます。
  
  このようなCookieが見つかった場合、「偉大で恐ろしい」コントロールも転送します。暗号化されたCookieの残りから「記憶」する必要があるユーザーを判断させます。
  また、この操作ではデータベースとファイルシステムへのアクセスは必要ありません。index.phpのままです。
  
  
• まだここにいる場合は、先に進みます。 joomlaと同じ名前、つまりmd5（md5（ '_ secret_site'））でダミーセッションを作成し、jos_sessionテーブルにそのidのセッションが存在するかどうかを確認します。 。 また、この場所では、不要なセッションをデータベースから削除する必要がありますが、これは必要ではありません-要求の一部がそれを起動する場合、joomla自体がこれを処理できます。
  
  これはデータベースへの最初のアクセスであることに注意してください。
  
  チェックの結果に基づいて、次に何をすべきかを決定します。 そのようなセッションが存在しない場合（およびそのようなセッションが存在し、登録ユーザーに属していない場合）、次の段落に進み、キャッシュからページを読み取る機能を決定します。 セッションが登録ユーザーに属している場合、標準生成のために「離脱」しています。 原則として、この場所では、さらに「掘る」ことができます-許可されたユーザーのページをキャッシュしますが、私はこれには入りませんでした。 私のサイトの特異性は、登録ユーザーのページをキャッシュするフロントエンドのサイズが大幅に増加するという事実にもかかわらず、未登録ユーザーが前代未聞の訪問を共有するようなものです。 さらに、現時点では、新しいホスティングに移行しました。キャッシュがない場合でも、生成時間は非常に安定しています。
  
  
• 次に、このページのキャッシュバージョンがあるかどうかを判断する必要があります。 存在する場合はキャッシュを提供し、存在しない場合は結果を生成してキャッシュに保存し、クライアントに提供します。 生成の場合、セッションを削除することを忘れないでください。 joomlaは自分で作成します！
  
  また、「キャッシュを放棄」し、joomlaにその名前のセッションがない場合、joomlaセッションテーブルにセッションを追加することが重要です。 これは、ユーザーがキャッシュされたゾーンからキャッシュされていないゾーンに移動する場合、AJAXモジュールなどの場合、joomla自体の正しい動作を保証するために必要です。 さらに、動的モジュールをクライアントに送信する前に、動的モジュールのキャッシュ処理を実行する必要があります。詳細は以下をご覧ください。
  
  この時点で、動的モジュールに関連する多くのニュアンスがあります。
  私の場合、これらは次のモジュールです。
  
  • 過去1時間のサイトのユーザー数
  • 最新のサイトニュース
  • 生産ニュース（このモジュールは、オフィスERPの最新の開発状況を表示します）
  • ランダムなjoomlaユーザーを表示するモジュール（この場合、会社のランダムな従業員の写真が表示されます）
  • joomla許可、それ自体は静的ですが、スプーフィング保護があります（Community Builderコンポーネントを使用する場合、fe_cbSpoofString関数がこれを担当します-joomlaソースで検索します）
  
  正しい動作を保証するために、次のことが行われました。
  
  • キャッシュに入れられるjoomla生成を開始すると、いくつかの定義を行います
  • 上記のモジュールの生成コードで、この定義が表示される場合、モジュール本体の代わりに、応答本体に魔法の言葉を表示します
  • フロントエンドでは、フレームワークをロードせずにモジュールのテキストを生成する関数を（Ctrl-C、Ctrl-Vおよび小さなファイルを使用して）記述します
  • 生成の結果（モジュールの代わりにマジックワードを含む）をキャッシュに入れます
  • キャッシュからコンテンツを配信するとき、私たちは平凡なstr_replace（）マジックワードを定義した関数の結果に変更します
  
  

それだけです。 その結果、ほぼ1桁（ほぼ10倍）の加速度が得られました。



ホストトラッカーの結果
物理的なホスティングはキエフにあり、ターゲット視聴者の99％がそこにいます。
サイトの速度を評価できます： リンク

下の画像-Googleウェブマスターツールの画面



2月の急増は1つの問題によって引き起こされました。その解決策として、2〜3日ごとにフロントエンドキャッシュ全体を削除する必要がありました。 しかし、この問題自体はフロントエンドとは何の関係もありませんでした。

フロントエンドキャッシュは、joomla管理パネルからクリアされます。キャッシュ自体を/ cache / FrontEnd daddyに入れる以外は、何もする必要はありませんでした-joomlaは自分自身を見て、クリアできるようにしました...

PS：このアプローチは、Joomla 1.5のフレームワーク内だけでなく、Joomlaのフレームワーク内でも適用できると確信しています。 もちろん、これにはいくつかのスキルが必要になりますが、同時に、学習しやすい無料のCMSの範囲を広げることができます。

ご清聴ありがとうございました。