Я использую традиционное приложение среды Zend, сгенерированное с помощью Zend tool . У меня есть несколько модулей в моем приложении, все созданные с помощью Zend tool . Я намерен использовать default routes по default routes в структуре Zend в своем приложении.
Например: www.host.com/module/controller/action/param1/value1/param2/value2
Вот мои вопросы:
Заметка:
Я понимаю процесс маршрутизации и как он работает в среде Zend. Однако, поскольку я не буду использовать большинство доступных функций, я подумал, что пришло время для тонкой настройки 🙂
Заранее спасибо.
1. Производительность с использованием маршрутов по умолчанию является самым быстрым решением, не так ли?
Правильно, но без использования какой-либо системы маршрутизации является самым быстрым решением (очевидно).
2. Поскольку я никогда не изменю маршруты, есть ли способ сделать процесс маршрутизации еще быстрее? кэширование, например? полностью пропускать процесс маршрутизации? или любой другой метод?
Ну, вот что, маршруты в основном используются для гибкости, интернационализации, SEO.
Проблема с Zend Framework Router заключается в том, что она зависит и обертывает экземпляр Front Controller, поэтому трудно (а возможно, afaik) кэшировать маршрутизатор, поскольку сам FC обертывает другие вещи, такие как экземпляры PDO, которые не кэшируются.
Таким образом, все маршруты вычисляются снова и снова для каждого запроса.
Возможное решение при использовании сложных маршрутов при избегании вычисления маршрута – это сброс всех маршрутов в собственные правила исправления Apache, он будет быстро сверяться по сравнению с ZF, основная проблема с этим решением заключается в том, что вам нужно вручную вычислять обратные маршруты и всякий раз, когда вы делаете изменение маршрута, вам нужно будет отредактировать его вручную.
Как часто, это масштабируемость и производительность .
3. В чем преимущества создания пользовательских маршрутов? это лучше для SEO?
Ну, это «зависит» ™:
/list?type=products vs /products , выигрывает второй маршрут.
Тем не менее, /products/page/1 vs /products?page=1 является беспроигрышной (ну, на самом деле это не так, но это еще одна история).
Другие профи:
4. Могу ли я пропустить процесс маршрутизации вызовов AJAX? (Я знаю, что ответ в основном НЕТ, но, возможно, я могу еще больше оптимизировать мой вызов для звонков AJAX)
Я не вижу никаких против этого. Я часто занимаюсь этим, за исключением RESTfull API.
Вы профилировали производительность компонента маршрутизации ZF или это предположение, что это «узкое место» вашего приложения ?!
На мой взгляд, если вам нужна эта низкая задержка, оптимизация скорости страницы путем отключения наиболее удобных функций – это не лучшая попытка получить цель. Можете ли вы начать оптимизировать свои SQL-запросы (slowlog – это ключевое слово здесь) или другие вещи (xdebug может действительно помочь вам профилировать ваше приложение и обнаруживать узкие места).
Это все о сроках …
Как насчет кэширования до внедрения zend-инфраструктуры ? Как насчет кэширования и доставки до того, как ваш интерпретатор (php) начнет? Звучит хорошо? Возможно, вы захотите использовать прокси, например, Varnish, чтобы реализовать хорошую реакцию с малой задержкой и сделать что-то подобное.
И даже если вы получите пропущенную кэш-память из своего прокси-сервера, вы хотите использовать кеш-код опциона PHP (например, APC, XCache, …). Чтобы узнать, как ускорить и оптимизировать структуру zend, вы хотите прочитать Руководство по производительности Zend .
У вас есть два способа расширить Zend_Front_Controller и переопределить его метод отправки и установить свой собственный фронт или внести изменения в сам код zend.
открыто
Zend/Controller/Front.php
внутри метод dispatch()
найти и удалить следующий код
$router = $this->getRouter(); $router->setParams($this->getParams());
а также
$this->_plugins->routeStartup($this->_request); try { $router->route($this->_request); } catch (Exception $e) { if ($this->throwExceptions()) { throw $e; } $this->_response->setException($e); } /** * Notify plugins of router completion */ $this->_plugins->routeShutdown($this->_request);
После этого возьмите объект запроса $ this -> _ request и установите контроллер, действие, имя модуля на основе параметров URL.
$this->_request()->setModuleName($get[0]);