Публикую текст своего доклада для Друпалконфа, который прошел 4 июня 2012 года в Москве. Хочу акцентировать внимание на том, что этот текст не адаптирован под блогпост и публикуется в том виде, в котором я рассказывал его на конференции.

Введение

В текущем Drupal 6 проекте, над которым я работаю последние 2 года, в пике мы отдаем до 2 млн просмотров страниц в день и забиваем полностью наш 200-мегабитный интернет-канал. Судя по отчетам нашей системы мониторинга с текущей архитектурой и железом (6 серверов: 2 фронтэнда с nginx, 2 бэкенда с Varnish + Apache + Drupal и 2 MySQL-сервера с master-slave репликацией) мы можем выдерживать втрое большую нагрузку, если решим вопрос с каналом.

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

Я хочу рассказать о том, какие для Друпала существуют средства оптимизации скорости отдачи контента и сравнить их плюсы и минусы. Я не буду вдаваться в детали и приводить примеры конфигов, это все можно найти в интернете (я у себя в блоге выложу в ближайшее время пример конфига, используемого в наших проектах). Я не буду рассказаывать об оптимизации конфигов MySQL, установке систем кеширования опкода, так как это большая тема достойная отдельного доклада, она хорошо раскрыта, в интернете можно найти много статей по оптимизации окружения, в котором работает сайт. Кроме того, эта тема имеет мало отношения к Друпалу и больше должна быть интересна системным администраторам, чем программистам (хотя программистам тоже неплохо бы в ней разбираться).

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

Описание проблемы

На сайте используется Drupal 6 и модуль theme key, который позволяет задавать разный дизайн для разных страниц. Столкнулся с неприятной и трудноуловимой проблемой: есть 2 полностью идентично настроенных (как казалось изначально) сервера, на одном из которых theme key отрабатывает корректно, а на втором нет — все время отображает контент в дефолтной теме оформления. Похожая проблема также встречалась в другом проекте, не использующем theme key, на странице управления блоками.

После некоторых экспериментов удалось выяснить, что сервера отличаются настройкой PHP error_reporting. На глючащем сервере она была задана так:

error_reporting = E_ALL & ~E_DEPRECATED

на работающем так:

error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTICE

Обновление этой настройки на некорректно работающем сервере решало проблему. Может показаться что это магия какая-то, мне так изначально и показалось: ну какое отношение имеют сообщения, выводимые в лог, к работе модулей и выбору темы оформления Друпала? В итоге, оказалось, имеют самое непосредственное отношение. Ниже описание причины проблемы и её решение.

Вдохновленный вот этой серией статей об Ардуино, ставлю разные эксперименты над Ардуино, сегодня таки сумел подружить её с Bluetooth-модулем (скетч взял прямо из документации), но столкнулся с проблемой. При попытке загрузить скетч в Ардуино, когда схема уже собрана вот так:

получал ошибку:

avrdude: stk500_getsync(): not in sync: resp=0x00

Не ожидал такого от Гугла. Теперь встала задача придумать способ восстановить свои аккаунты толпе юзеров, которые использовали Google Friend Connect для авторизации на сайте и не знают свои пароли, и не могут вспомнить свои логины.

Задача

Создать эффект "ластика" с помощью html5 тэга canvas. Суть эффекта простая: выводится картинка, поверх картинки выводится полупрозрачный фон, если пользователь нажимает на левую кнопку мыши и начинает двигать курсор по холсту, то полупрозрачный фон должен стираться. Конечный результат можно увидеть тут.

Задача будет разбита на 3 части:
1. сначала мы зальем картинку равномерным фоном и научимся стирать этот фон ластиком квадратной формы.

23 апреля 2011 года принял участие в конференции DrupalConfMoscow 2011. Вместе с Тарасом Савчуком рассказал о том, как мы настраивали Друпал и системное окружение, чтобы сайт forbes.ru мог выдержать нагрузку 250 тысяч уников в сутки. Ниже видео и текстовая версия моей части доклада.

Отчет о путешествии по Перу и Боливии. Часть 2.

Это вторая часть отчета о путешествии по Перу и Боливии. Первая часть доступна здесь.

В Ла Пас мы прилетели около 10 утра (2 часа полета) и без промедления поехали на автовокзал где купили билеты до Оруру, откуда дальше поездом должны быль добраться до Уюни. Боливийские автобусы не отличаются комфортом. Духота, спертый воздух, орущие дети, дребезжащая музыка, доносящаяся из дешевых наушников десятка пассажиров. В общем, эта четырехчасовая поездка не доставила удовольствия.

Добравшись до Оруру мы поехали на железнодорожный вокзал где у нас были забронированы (но не выкуплены) билеты на вечерний поезд до Уюни. Как-то так получилось, что о нашей брони кассиру было ничего не известно, билетов в самый комфортный вагон уже не было, пришлось ехать в вагоне среднего класса (40 боливианов). Хотя обратно мы ехали в самом дорогом вагоне (90 боливианов) разницы между ним и вагоном среднего класса я не увидел, за исключением того, что в дорогом вагоне бесплатно раздали по бутерброду.

До Уюни мы добрались в 2 часа ночи, заселились в первый попавшийся отель, а утром купили билеты на обратный поезд. Здесь у нас была зарезервирована трехдневная экскурсия по окрестностям Уюни и, на этот раз, эта бронь внезапно не исчезла.

Отчет о путешествии по Перу и Боливии

С 23 февраля по 10 марта укатил в отпуск, на этот раз, впервые жизни, решил поехать в Южную Америку и посетить Боливию и Перу. Когда-то давно, лет 5 назад, я прочитал в «Максиме» о солончаке Уюни (Salar de Uyuni) и загорелся желанием увидеть его. Солончак Уюни — это самое большое в мире высохшее соляное озеро, в июне-августе оно выглядит как гигантская белая пустыня с идеально ровной поверхностью. В декабре-марте эта пустыня покрывается слоем выоды, глубиной в несколько сантиметров, от чего вся её превращается в гигантское зеркало, в котором отражается чистое небо и облака. Люди, стоящие на этом зеркале, выглядят так, будто ходят по поверхности воды.

Во время путешествия по Боливии и Перу сделал несколько панорам.

Куско

Солончак Уюни (Salar de Uyuni)

Пустыни в окрестностях Уюни

Закат в горах

Разработчики ВКонтакте.ру не так давно открыли доступ к OpenAPI — интерфейсу, позволяющему обычным пользователям авторизоваться на сторонних сайтах с использованием своих учетных записей ВКонтакте.ру.

Я выкладываю первую версию модуля vk_openapi, который интегрирует Drupal 6 с Open API. Демонстрацию работы модуля вы можете увидеть на этом сайте. Кнопка для авторизации с помощью учетной записи вКонтакте находится в форме авторизации (в правой колонке внизу) и на странице с формой входа.

Особенности модуля

• из учетной записи ВКонтакте выбираются все доступные поля и сохраняются в объекте $user;
• каждому созданному модулем пользователю автоматически может быть назначена роль;
• в качестве аватара нового пользователя может быть использован автар из профиля пользователя ВКонтакте;
• созданный модулем пользователь может быть связан с существующим на сайте аккаунтом.

В ближайших планах: обновление статуса пользователя на основе данных из профиля ВКонтакте.

Скачать модуль можно на drupal.org. В продолжении более подробное описание модуля и инструкция по его установке.