Введение
С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:
0. Зачем вообще что-то оптимизировать? 1. Оптимизация ОС (FreeBSD) 1.1 Переход на 7.х 1.2 Переход на 7.2 1.3 Переход на amd64 1.4 Разгрузка сетевой подсистемы 1.5 FreeBSD и большое кол-во файлов 1.6 Softupdates, gjournal и mount options 2. Оптимизация фронтенда (nginx) 2.1 Accept Filters 2.2 Кеширование 2.3 AIO 3. Оптимизация бэкенда 3.1 APC 3.1.1 APC locking 3.1.2 APC hints 3.1.3 APC fragmentation 3.2 PHP 5.3 4. Оптимизация базы данных 4.1 MySQL 4.1.1 Переход на 5.1 4.1.2 Переход на InnoDB 4.1.3 Встроеный кеш MySQL - Query Cache 4.1.4 Индексы 4.2 PostgreSQL 4.2.1 Индексы 4.2.2 pgBouncer и другие. 4.2.3 pgFouine 4.3 Разгрузка базы данных 4.3.1 SphinxQL 4.3.2 Не-RDBMS хранилище 4.4 Кодировки 4.5 Асинхронность Приложение. Мелочи. 1. SSHGuard или альтернатива. 2. xtrabackup 3. Перенос почты на другой хост 4. Интеграция со сторонним ПО 5. Мониторинг 6. Минусы оптимизации
В Kohana я обычно использую класс Template_Controller. Очень удобно — layout один, изменяешь только контент. Но как быть если на одной какой-то странице нам понадобилось подключить CSS- или JS-файл?! C js- файлом еще ладно, его можно подключить посредине страницы (но это как-то некрасиво), а как же css?! — это невалидно. Подключать на весь layout тоже неохота. Хочу подключать не в контроллере, а в шаблоне к примеру так:
