Оптимизация проекта на Zend Framework

Настал момент, когда самописный проект на ZF под нагрузкой начал сбоить. И как обычно - RTFM. наткнулся на инересную статейку. Ну и дело стало за малым - реализовать на проекте. В первую очередь полез в стартовый скрипт bootstrap.php и поправил set_include_path вместо относительных путей для подключения библиотек на абсолютные :
set_include_path('.'
. PATH_SEPARATOR . realpath(dirname(__FILE__) . '/../library')
. PATH_SEPARATOR . realpath(dirname(__FILE__) . '/../application/default/models')
. PATH_SEPARATOR . realpath(dirname(__FILE__) . '/../../zf-1.9.4/library')
. PATH_SEPARATOR . get_include_path());
 Как и написано в мануале - подключил файлик с инклюдами(там прописываются все необходимые инклюды, для ускорения загрузки классов/библиотек:
$classFileIncCache = realpath(dirname(__FILE__) . '/../cache') . '/pluginLoaderCache.php';
if (file_exists($classFileIncCache)) {
include_once $classFileIncCache;
}

require_once 'Zend/Loader/Autoloader.php';

Zend_Loader_Autoloader::getInstance()->setFallbackAutoloader(true);
Zend_Loader_PluginLoader::setIncludeFileCache($classFileIncCache);

Далее лезем в файл инициализации Initializer.php. В нем прописываем кэш для БД -(по дефолту при создании модели таблицы происходит запрос describe table, который можно записать в кэш):
$cache = Zend_Cache::factory('Core',
'File',
array(
'lifetime' => null,
'automatic_serialization' => true,
'ignore_user_abort' => true
),
array(
 'cache_dir' => '/path/to/cache/',
'cache_file_umask' => '0666')
);
Zend_Db_Table::setDefaultMetadataCache($cache);
Можно так же использовать кэш не в файлах, а в хранилище Memcached  что еще увеличит скорость работы.
Еще одним узким местом оказались файлы с настройками, которые хранились в формате XML - очень удобно для правки. Конфигурация кэшировалась при помощи того же Zend_Cache. Прочтя статейку на хабре, в результатах сравнения видно, что для небольших конфигурационных файлов сериализованный конфиг работает ненамного быстрее Ini, на значительно шустрее чем XML в результате чего было принято решение отказаться от конфигурационных файлов в XML+FileCache в пользу Ini файлов.

 

Оптимизация MySQL

Пролог.
Случилось намедни так, что под нагрузкой начал загибаться один из самописных проектов и один из сторонних проектов на PHP+MySQL. В самописном проекте, так же как и в стороннем - узким местом стола БД MySQL(исходя из показателей top).
Как говориться - RTFM - в настройках MySQL можно указать логирование медленных запросов и запросов, которые не используют индексы.  Сия затея выполняется нехитрым способом:
добавляем в секцию [mysqld] файла my.conf( по дефолту в /etc ) строчки

slow_query_log_file = /path/to/slow_query.log
log_queries_not_using_indexes = true
slow_query_log = true
long_query_time = 3

В зависимости от мощности тестового сервера можно изменять long_query_time.
После перезагрузки сервера MySQL (/etc/init.d/mysql reload) и нагрузки на проект(важно отключить внутреннее кэширование запросов/данных) можно мониторить неугодные запросы и оптимизировать оные и/ или оптимизировать индексы таблиц.

Для оптимизации обработки логов интернет подсказал утилитку maatkit, и при помощи mk-query-digits можно привести лог к удобочитаемому виду для анализа

Восстановление MBR под Linux

Пролог
Случилось намедни после рабочего дня поковыряться с больной головой в любом компьтере, в результате чего была нищадно затерта MBR диска, на котором находилась система и вся информация. Сложность восстановления заключалась в том, что на жестком диске коряво были размечены разделы и стояли бок о бок WinXP и OpenSUSE, в результате чего диски были различных типов: NTFS, Ext3, Ext4.

Восстановление.
На руках имелись только LiveCD Opensuse и установочный DVD OpenSUSE. С одного можно было загрузиться и выползти в тырнет, почитать направление в котором копать, а со второго можно была заново накатить ситему, затерев все данные, что было неуместно в данном случае. При поиске в интернете наткнулся на упоминание утилитки testdisk, которая была найдена в репозитории packman, однако она упорно не хотела ставиться в память при загрузке с LiveCD.  В результате поисков нашел на одном из форумов ссылку на загрузочный диск с утилиткой testdisk - sysresccd. Скачав последний релиз образа залил его на болванку и запустился с оного диска. В результате появилось меню с выбором типа загрузки. Т.к. у меня 64-разрядный процессор и довольно таки большой объяем оперативной памяти я выбрал  rescue64 - docache(квикгайд находиться здесь). В результате загрузилась консоль из которой был запущен testdisk. Далее все делалось согласно инструкции: Файл лога не создавался(т.к. все запускалось из оперативной памяти, и смысла копаться в данном логе я не видел), выбран тип разделов Intel, сделан первоначальный анализ диска, который показал, что у меня нету ниодного раздела, выполнен полный поиск разделов. В результате поиска было найдено 11 разделов, вместо 7 положенных - лишние разделы были дубляжом/предположением о местоположении затертых разделов. Изначально все найденный разделы были помечены как удаленные. При помощи встроенного просмоторщика файлов на найденных разделах(который держит множество типов логических дисков) были найдены затертые разделы. Всю сложность восстановления составляло то, что я  не помнил какие разделы были основными, какие логическими. Методом научного тыка были расттавлены все точки над i и назначены разделам соотвествующие типы(хотя и отличные от исходных) и записана таблица разделов на диск. Стоит заметить, что при неправильном выборе типов логических дисков снизу появлялась едва заметная надпись о том, что разделы выставлены неправильно и если не обратить на неё внимание - то разделы не восстановятся и придется сканировать винчестер по новой. При перезагрузке естественно никакая из ОС не загрузилась, т.к. был затерт загрузчик.
Восстановление загрузчика осуществлялось при помощи Recovery console c установочного DVD. Грузимся с установочного DVD, входим в консоль,на запрос логина отвечаем root. Изначально при помощи fdisk -l смотрим на свои восстановленные разделы и запускаем для каждого e2fsck, для проверки на ошибки, после - монтируем корневой диск в /mnt( в моем случае - mount /dev/sda7 /mnt. При помощи vi редактируем /etc/fstab и правим точки монтирования в соответствии с новым расположением разделов. После - запускаем grub -и пишем следующее
find /boot/grub/stage1 -- выдает нам раздел (hdX,Y)
root (hdX,Y)
setup (hd0)
quit
 После перезагрузки - вуаля - загрузчик установлен, система загружается, данные целы.
Эпилог.
Нельзя ковыряться глубоко в компьютере поздно вечером, во избежания приключений с восстановлением данных, необходимо хранить бэкапы нужных  данных.

Яблофон

очередной халивар разведен на Хабре по пововду яблок вот здесь