AJAXとパフォーマンス

サーバーへの非同期要求により、サイトでのユーザーの作業が大幅に簡素化されることは周知の事実です。 また、非同期要求によってサイトのパフォーマンスが向上することも秘密ではありません。 実際、基本的なスタイル、jsスクリプト、画像、フォントなどを一度だけダウンロードし、AJAXを使用して必要なコンテンツのみをロードするのは非常に魅力的です。



AJAXを使用してサイトのパフォーマンスを最大限に引き出したい場合、必要なアイデアは1つだけです。



AJAXの個別のコードを記述します。



はい、そのように、それはもっと簡単に見えるでしょう。



しかし、ほとんどのプログラマーは自分自身を含めて怠け者であり、余分なコードを書くことを好みません。 これにより、コントローラー（または特定のスクリプト）で会って、デザインのようなサイトページ、ニュース、ブログ記事を表示できます。

//   //    if(isset($_POST['ajax'])) { //      // AJAX exit(); } else { //          //    }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ほぼすべてのシステムは、単一のエントリポイントの原則に基づいて構築され、動作します。 人気のあるシステムからこれらには、Drupal、ShopScript（WebAsystを備えたバージョン）、CodeIgniterなどが含まれます。



多くのエントリポイントがあるシステムの場合、通常、単一のシステム初期化スクリプトが作成されます。 そのため、たとえば、各エントリポイントの先頭には、次のようなものがあります。

 <?php require_once('includes/application_top.php'); //   
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この原理により、osCommerce、DokuWiki、WordPress、Joomla、Bitrixなどが機能します。



一般に、そのような振る舞いには何も問題はなく、大多数ではそのように動作する方が良いです。 ただし、コンテンツの必要な部分を取得するには、システム全体をロードする必要があります。 そして、これは最初は生産性が低いかもしれません。



生産性を向上させるための良い解決策は、システム全体ではなく、その基本部分と問題の解決に必要なコンポーネントだけをロードすることです。 たとえば、サイトで静的なページを表示している場合にブログの機能を読み込む理由。



PrestaShop、ShopScript、Bitrixなど、多くのシステムがこのように機能します。



しかし、システムの基本的な部分は非常に重いことがあることを理解する必要があります。 この場合、パフォーマンスが最初になると、システムを起動せずに実行できます。



私の練習では、Bitrixに非常に明らかになる例が1つあります。 私はすぐにこれがBitrix開発者の庭の石ではないことを予約したいと思います。 誰がこのシステムを頻繁に使用し、その問題とこれらの問題を回避する方法を知っています。 そして、ここでそのような方法の一つについてお話します。



だから、与えられた：



Bitrixには特定のオンラインストアがあります。 店舗カタログには22,000以上の製品が含まれています。 製品は400を超えるカテゴリで配布されています。 各製品には約70のプロパティがあります。 各製品には、独自のサプライヤのセットと、これらのサプライヤの倉庫の残高に関する情報があります。



必須：商品を含めるという重要なロジックを持つYandexのYMLを生成するスクリプトを記述します。 標準のBitrixモジュールはこのロジックに対応していません。



このようなデータの配列を一度に処理することは不可能であり、反復でプロセスに勝つ必要があることは明らかです。 これは、AJAXが助けになる場所です。

ソリューション1、標準

商品の一部の処理へのリクエストをAJAXサーバーに送信するユーザーエージェント用のモジュールを作成しています。

サーバー側スクリプトはリクエストを受け入れ、システムを接続し、必要な商品ブロックを処理し、YMLファイルの一部を形成します。 すべてが非常に標準的です。



すべてが美しく、公式文書に従って機能します。 はい、それはまさにそのような大量のデータであり、すべて25分程度で動作します。 そのような時間は、各反復（各50製品の440反復）でのシステムのロードに加えて、データベースサンプルの内部コストのために実行されます。

解決策2、リクエストを処理するための個別のコードを記述する

私が理解している解決策は（使用されているプラ​​ットフォーム以外では）美しいものではないが、パフォーマンスが大幅に向上したことをすぐに言わなければなりません。



サーバー側のスクリプトでは、Bitrixの読み込みを削除し、代わりにシステム構成ファイルを接続します。 標準のPDOを使用して、商品に関する必要なデータを直接取得します。



はい、コードはメインフレームワークの外で動作しますが、同じ量のデータが40秒で処理されます。 これは、リクエストを処理するための個々のコードが一般に受け入れられている実装方法よりもはるかに高速に動作できるという事実の非常に重要な例です。



別のシステムおよび/または他のデータ量では、パフォーマンスの差はそれほど大きくないことを理解しています。 そして、それほど重要ではない生産性のために、護衛の便利さを犠牲にして動物園を繁殖させるべきではないという事実ではありません。 しかし、突然パフォーマンスが決定的な役割を果たす場合は、AJAXリクエストを処理するコードを個別に作成することを検討する必要があります。