5

私の Zend アプリは 3 つの ini 構成ファイルを使用しており、合計で 200 行を超える解析行があり、100 を超える命令が含まれています。これらのファイルはリクエストごとに解析されますか? あると言う人もいます (ここやここのように)。もしそうなら、これは効率の問題ではありませんか？

これらのリンクのコメントにはさまざまな意見があります。ini 構成ファイルを避けて PHP で構成を行うべきだと言う人もいれば、Zend_Cache_Frontend_File を使用できると言う人もいれば、問題ではないと言う人もいます。しかし、大量のトラフィックが予想される場合、1 回のリクエストで 200 行のテキストを解析するのはすぐに問題になるのではないでしょうか?

キャッシュ技術の使用をお勧めする場合、それをどのように実装するかを正確に説明していただけますか?

4

4 に答える 4

10

はい、キャッシュしない限り、毎回解析されます。それは本当に時間を節約します（私は自分のプロジェクトでそれをチェックしました）.

では、どのようZend_Cache_Frontend_Fileに ini ファイルをキャッシュするのでしょうか? さて、私はあなたに例を提供することができます. 私のプロジェクトには、多数のカスタム ルートを含む route.ini ファイルがあります。

ルート.ini

routes.showacc.route = "/@show/:city/:id/:type"
routes.showacc.type = "Zend_Controller_Router_Route" 
routes.showacc.defaults.module = default
routes.showacc.defaults.controller = accommodation
routes.showacc.defaults.action = show
routes.showacc.defaults.city = 
routes.showacc.defaults.type = 
routes.showacc.defaults.id = 
routes.showacc.defaults.title = 
routes.showacc.reqs.id = "\d+" 

;and more

私のBootstrap.phpでは、キャッシュを使用してそれらをロードします (可能な場合):

protected function _initMyRoutes() {
    $this->bootstrap('frontcontroller');
    $front = Zend_Controller_Front::getInstance();
    $router = $front->getRouter();

    // get cache for config files
    $cacheManager = $this->bootstrap('cachemanager')->getResource('cachemanager');
    $cache = $cacheManager->getCache('configFiles');
    $cacheId = 'routesini';

    // $t1 = microtime(true);
    $myRoutes = $cache->load($cacheId);

    if (!$myRoutes) {
        // not in cache or route.ini was modified.
        $myRoutes = new Zend_Config_Ini(APPLICATION_PATH . '/configs/routes.ini');
        $cache->save($myRoutes, $cacheId);
    }
    // $t2 = microtime(true);
    // echo ($t2-$t1); // just to check what is time for cache vs no-cache scenerio

    $router->addConfig($myRoutes, 'routes');
}

キャッシュは私のapplication.iniで次のように設定されています

resources.cachemanager.configFiles.frontend.name = File
resources.cachemanager.configFiles.frontend.customFrontendNaming = false
resources.cachemanager.configFiles.frontend.options.lifetime = false
resources.cachemanager.configFiles.frontend.options.automatic_serialization = true
resources.cachemanager.configFiles.frontend.options.master_files[] = APPLICATION_PATH "/configs/routes.ini"    
resources.cachemanager.configFiles.backend.name = File
resources.cachemanager.configFiles.backend.customBackendNaming = false
resources.cachemanager.configFiles.backend.options.cache_dir = APPLICATION_PATH "/../cache"
resources.cachemanager.configFiles.frontendBackendAutoload = false

お役に立てれば。

于 2011-07-27T11:46:30.957 に答える
4

ZF のようなフレームワークをロードすると、数千行のコードを含む数十のファイルがロードされます。ファイルは、すべてのユーザーとリクエストごとに読み取る必要があります。サーバー側では、ディスクコントローラーなどでキャッシュを使用しているため、ファイルを毎回ディスクから実際に読み取る必要はありません。また、オペレーティング システムのメモリ マネージャはそれを追跡し、メモリにキャッシュを提供するため、これを毎回メモリに読み込む必要はありません。次に、データベースが最終的にハード ドライブ上のファイルに格納されるため、多かれ少なかれ同じことが起こるデータベースがあります。DBサーバーはファイルとほぼ同じストーリーを読み込みます。

では、構成ファイルの数行について心配することはありますか? 確かに、アプリケーションが機能するためにデータが必要だからではありません。それがどこから来ているかは二次的なものです。

Zend_Cache によるキャッシングについて。Zend_Config のファイルのようにコンパクトで多くの処理を必要としないデータがある場合は、わずかなマイクロ秒を節約できます。基本的に、コンパクト形式を別のコンパクト形式に保存しています。再度シリアル化を解除する必要があるシリアル化された文字列。データベースへのアクセスを避けるためにデータをキャッシュしたり、すべてのデータ リクエストを含むビュー全体をレンダリングしてモデルをギアに入れたりできる場合は、まったく別の話になります。

于 2011-07-27T14:16:40.500 に答える
3

PHP ファイルがメモリにキャッシュされているのに対し、解析された ini ファイルもメモリにあると仮定すると、Zend_Config_Ini クラスと解析プロセスをスキップしながら、ini ファイルを php ファイルに変換するパフォーマンスを得ることができます。

# public/index.php
$cachedConfigFile = APPLICATION_PATH.'/../cache/application.ini.'.APPLICATION_ENV.'.php';

if(!file_exists($cachedConfigFile) || filemtime($cachedConfigFile) < filemtime(APPLICATION_PATH . '/configs/application.ini'))
{
    require_once 'Zend/Config/Ini.php';
    $config = new Zend_Config_Ini( APPLICATION_PATH . '/configs/application.ini', APPLICATION_ENV );
    file_put_contents($cachedConfigFile, '<?php '.PHP_EOL.'return '.var_export($config->toArray(),true).';' );
}

$application = new Zend_Application(
    APPLICATION_ENV,
    $cachedConfigFile // originally was APPLICATION_PATH . '/configs/application.ini'
);

$application->bootstrap()
        ->run();

私はabでテストしました。非キャッシュ構成:

ab -n 100 -c 100 -t 10 http://localhost/
Requests per second:    45.57 [#/sec] (mean)
Time per request:       2194.574 [ms] (mean)
Time per request:       21.946 [ms] (mean, across all concurrent requests)
Transfer rate:          3374.08 [Kbytes/sec] received

vs キャッシュされた設定:

Requests per second:    55.24 [#/sec] (mean)
time per request:       1810.245 [ms] (mean)
Time per request:       18.102 [ms] (mean, across all concurrent requests)
Transfer rate:          4036.00 [Kbytes/sec] received

つまり、パフォーマンスが 18% 向上します。

于 2014-06-08T17:50:32.823 に答える