Уменьшаем кол-во запросов requestAction-ов с помощью Cache

    В документации Cakephp 1.2 говорится о том что если requestAction используется без кеширования, то это может уменьшить производительность.
    If used without caching requestAction can lead to poor performance. It is rarely appropriate to use in a controller or model.
    И правда, сами подумайте, каждый раз при просмотре сайта, кроме основных запросов, к базе делается куча мелких, с помощью requestAction-ов, например…
    И как истинные политики, они говорят ЧТО может произойти, при этом не говоря КАК этого избежать.
    Привожу пример того, КАК с этим разбираюсь я.

    Коротко, о том как работает requestAction:
    requestAction обычно используется вo view-файле (папка views). из view-файла, вы делаете запрос на другую страницу, и получаете значение.
    синтаксис requestAction-а таков: $this->requestAction('/articles/home');
    который говорит Cakephp что надо сделать запрос по адресу адрес.сайта.сom/articles/home
    в самом контроллере к которому обращается requestAction надо прописать return;
    function home(){
    $out = $this->Article->find('all');
    Cache::write('articleHome', $out);
    return $out;
    }


    теперь мы можем смело дописать к $this->requestAction('/articles/home'); следующие строки

    $out = Cache::read('articlesHome');
    if(empty($out)){
    $out = $this->requestAction('/articles/home');
    }

    После этого, мы один раз делаем запрос к базе, пишем все в файл. и остальные разы читаем из файла. Если в результате какие-то проблем со стороны НЛО мы не сможем прочитать файл из кеша, ничего страшного. Опять делаем запрос к базе, и опять пишем в файл (у попа была собака...)

    и теперь при каждом обновлении этого списка, если мы что-то добавили/изменили не забываем перезаписывать Cache:
    Cache::write('articleHome', $out);
    crosspost с моего блога

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 6

      +1
      В документации упирают на кэшируемость элементов.
      То есть кусок который обращается к requestAction — мы делаем отдельно, элементом, а потом вызываем из view, как $this->element('elementName', array('cache' => true));

      Настройки кэша у элемента довольно гибкие.

      Ну а после серьезных обновлений (хотя я ставлю обновления кэша элемента на 2-5 минут, и он сам прочищается к этому времени), есть еще команда Cache::clear(), правда довольно злая.
        0
        На практике часто встречался с тем что кешировать надо было не весь элемент, а только сам запрос. который очень легко модифицировался в элементе.
          0
          То есть один запрос, а результат вывода меняется в зависимости от какого либо параметра?
          Можно вложить элемент внутрь другого элемента.
            0
            Например показ списка баннеров, которые хранятся в базе. и надо ох показывать вразброску.
        0
        ну ясное дело, что без кэширования будет медленнее, чем с кэшированием. тем не менее requestAction не медленнее ClassRegistry::init('Model'). другое дело, что с реквестэкшеном могут быть трудности с отладкой, потому что для него создается новый экземляр диспатчера. ну и нужно следить, чтобы у пользователя был доступ ко всем экшенам, которые используются в одном запросе.
        и насчет кэширования элементов, хотелось бы увидеть пример того, как нельзя закэшировать его целиком, а только результат запроса.
          0
          Кештрование результата запроса я привел в статье выше,
          а кештрование всего элемента приведено в документации, как сказал пользователь Hellbot
          надо в объявлении элемета указать продолжительность кеширования:
          $this->element('latest_comments', array('cache'=>'+1 hour'));

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое