Взялся за перевод на русский язык книги “PHP Internals Book”. Книга посвящена внутренней логике работы интерпретатора PHP и в первую очередь будет интересна разработчикам на языке C, которые хотят научиться писать расширения для PHP, но и PHP-разработчики, думаю, найдут для себя немало полезной информации.

Перевод является неофициальным (хотя и сделан с разрешения авторов), так что все камни о качестве перевода кидать в меня.

Почитать книгу онлайн можно тут: http://romka.gitbooks.io/php-internals-book-ru/, скачать в формате для читалок тут: https://www.gitbook.io/book/romka/php-internals-book-ru, помочь с переводом тут: https://github.com/romka/phpinternalsbook-ru.

На данный момент переведена только одна глава, но я продолжаю работу.

Важно учитывать, что структуры данных, описанные в книге, актуальны для современных версий PHP (на данный момент это PHP 5.5). Если один из следующих релизов будет слит с веткой phpng, то часть структур и алгоритмов, описанных в текущей версии книги, устареют.

Цитата из книги Стива Макконелла “Совершенный код”:

Разница между философией «удобства» и философией «интеллектуальной управляемости» сводится к различию между ориентацией на написание программы и ориентацией на ее чтение. Максимизация области видимости может облегчить написание программы, но программу, в которой каждый метод может вызвать любую переменную в любой момент времени, сложнее понять, чем код, основанный на грамотно организованных методах. Сделав данные глобальными, вы не сможете ограничиться пониманием работы одного метода: вы должны будете понимать работу всех других методов, которые вместе с ним используют те же глобальные данные. Подобные программы сложно читать, сложно отлаживать и сложно изменять.

Столкнулся с интересной проблемой, которую удалось повторить и в Drupal 6, и в Drupal 7. В модуле вне тела функции была объявлена константа:

define('TEST_CONST', drupal_get_path('module', 'test_module'));

(тут дело даже не в самой константе, а в использовании апишной функции drupal_get_path() вне тела функции).

Этот модуль долгое время корректно работал, до тех пор пока в нем не был объявлен hook_exit(). После этого события Друпал начал отдавать ошибку "PHP Fatal error: Call to undefined function drupal_get_path() in...", где вместо drupal_get_path() можно поставить почти любую функцию из Drupal API, которая была использована в коде, расположенном вне тела функций.

Поиск и исправление причин ошибки осложнился тем, что она стала проявляться не сразу после добавления hook_exit(), а спустя некоторое время.

Суть ошибки оказалась в следующем:

• Друпал в таблице system, модулям которые реализуют hook_exit(), проставляет значение 1 в колонке bootstrap, по умолчанию этот параметр равен нулю.
• В свою очередь модули отмеченные таким образом начинают загружаться Друпалом раньше остальных (на этапе DRUPAL_BOOTSTRAP_LATE_PAGE_CACHE в случае Drupal 6) когда API, в частности файл common.inc, содержащий функцию drupal_get_path(), еще не загружен полностью.
• Загрузка модуля подразумевает include файла модуля и, что логично, исполнение кода, находящегося вне тела функций.

Таким образом, после добавления hook_exit() модуль стал загружаться до полной загрузки API и функция drupal_get_path() на этом этапе действительно еще не была определена. Решилась проблема переносом проблемного кода в hook_init().

Возникла ошибка не сразу от того, что обновление поля bootstrap в таблице system делается не сразу, а при обновлении кеша списка модулей (вызов функции module_rebuild_cache() в Drupal 6). Этот кеш очищается, например, при нажатии кнопки “Сохранить” на странице списка модулей или при срабатывании модуля Update status.

Средняя нагрузка на сайт днем в рабочий день 1000 запросов в минуту (масимум 30-40 в секунду), около 200 тысяч уников в день и около 800 тысяч просмотров. Трафик отдается на скорости до 10 мегабайт в секунду.

В пиках нагрузка раньше доходила до 4 тысяч запросов в минуту (до 120 в секунду), около 350 тысяч уников в день и 2,5 млн. просмотрв. В пиках трафик отдавался на скорости до 50 мегабайт в секунду.

Пятница, 7 июня. В пике сайт отдавал больше 12 тысяч страниц в минуту (250 в секунуду) на скорости около 110 мегабайт в секунду.

Drupal + Varnish отработали на отлично. С учетом нашего канала и железа сайт может держать вдвое большую нагрузку подобного плана.

При работе над Drupal-проектом у меня возникла необходимость сбора детальной статистики о просмотрах материалов и вывода этой статистики в виде блоков, отображающих самые просматриваемые материалы за последние день, неделю и месяц. Стандартный друпальский модуль Statistics (и в шестом, и в седьмом Друпале) для решения такой задачи абсолютно неприменим:

• во-первых он осуществляет сбор статистики на hook_exit() и не будет работать корректно со сколько-нибудь серьезными системами кеширования, например при использовании Varnish или модуля Boost.
• во-вторых модуль Statistics собирает статистику за всё время существования материала, сделать выборку вида: “сколько раз был просмотрен материал за последний день” с этим модулем невозможно. По этому при использовании этого модуля исходную задачу пришлось бы модифицировать к виду: вывести список самых просматриваемых материалов созданных за последние день, неделю или месяц, но этот подход неприемлем, так как на сайте существуют материалы старше месяца, способные попасть в топ по просмотрам.

Таким образом, возникла необходимость внедрить полноценную систему статистики и интегрировать ее с Друпалом. Под полноценными системами я понимаю сервисы типа Google Analytics или Яндекс.Метрика, используя API которых можно запросить статистику просмотров материалов за любой диапазон дат. Достоинством этих сервисов является то, что они у себя хранят всю статистику, а она на посещаемом ресурсе может занимать немало места, их недостаток — все таки это внешние сервисы и неизвестно, что с ними случится завтра: сломаются, станут платными, не захотят внедрять нужную пользователю фичу и т.д.

В итоге я решил установить на собственном сервере open source систему статистики Piwik и интегрировать ее с Друпалом. Да, Пивик пока местами уступает GA и Я.М в гибкости отчетов (хотя есть в нем и отчеты, которых нет ни в ГА, ни в Я.М), но, во-первых, нужную мне задачу он решает, во-вторых он постоянно развивается своими разработчиками и может быть расширен с помощью самописных плагинов.

Для седьмого Друпала есть замечательный модуль Piwik stats, интегрирующий Друпал с Пивиком. Суть модуля состоит в том, что он создает специальное поле, которое может быть прикреплено к любой entity (материалу, пользователю). В настройках поля задается параметр, отвечающий за то, статистика за сколько дней должна быть в этом поле. Одна entity может содержать несколько полей с разными настройками, то есть, например, каждый материал может содержать три поля с информацией о просмотрах за последние день, неделю, месяц, как раз то что мне и требовалось.

Заполнение полей данными осуществляется через Drupal Queue API по крону, но при желании стандартный механизм обработки очереди может быть заменен чем угодно, например Rabbit MQ.

Плюсом хранения статистики в полях является то, что статистика становится прозрачно интегрированной со всем модулями Друпала, например с Views, с помощью которого, в том числе, можно строить блоки с контексто-зависимой статистикой. То есть, например, на главной странице сайта выводить список самых популярных статей со всего сайта, а на странице статьи или раздела — выводить самые популярные статьи текущего раздела.

Основная проблема для меня состояла в том, что модуль Piwik stats работает только под седьмым Друпалом и его разработчик не планировал делать бэкпорт под шестерку, а проект, в котором мне понадобился этот функционал, работает как раз на древней шестой версии Друпала. По этому я сам сделал бэкпорт этого модуля под шестерку. Забрать мою версию модуля можно из sandbox-проекта Piwik_stats, обсуждение этого бэкпорта с автором основного модуля тут: http://drupal.org/node/1736398.

Пока мейнтейнер модуля не хочет делать мою версию модуля официальной, из-за того, что требуется сделать детальный code review. Тем не менее, мой модуль без нареканий больше месяца работает в бою на двух Друпал 6 проектах.