Insight IT

Горячая замена кода

Иван Блинков — Mon, 29 Apr 2013 10:47:00 +0400

Относительно недавно почитывая RSS через доживающий свои дни Google Reader, о предстоящем закрытии которого не написал только самый ленивый IT-блоггер (к слову, любопытно насколько сильно просядет счетчик RSS-подписчиков Insight IT с текущих 16870, боюсь, что очень сильно...), я наткнулся на статью под заголовком "Горячее обновление кода не нужно?" и с выводом, что мол и правда особо не нужно, которая и подтолкнула меня поделиться своими мыслями на эту тему.

Для начала давайте разберемся в том, что же вообще такое "горячая замена кода" (hot code replacement или hot code swapping)? По сути это возможность обновить (или откатить) код работающей программы без её перезапуска и, как следствие, периода недоступности, потери состояния и повторной инициализации.

В каких ситуациях это может быть полезно? Ответ следует из моего импровизированного определения выше:

Когда простой (downtime) неприемлем
Когда есть какое-то состояние в памяти, которое не хочется терять
Когда инициализация процесса трудоемка и занимает много времени, что чаще всего связано с восстановлением состояния с диска или других внешних источников

Ко многим клиент-серверным приложениям, в том числе и веб-сайтам, предъявляют очень высокие требования по отказоустойчивости, то есть простои как таковые не допустимы даже в экстренных случаях, не говоря уже о регулярном обновлении компонентов системы. Но чтобы обеспечить высокой уровень доступности, измеряемый количеством девяток после запятой в 99.(9)%, одной горячей замены кода не достаточно, нужно в любом случае обеспечить доступность всех данных и ключевых серверных компонентов системы даже в случае выхода из строя сервера, стойки, маршрутизатора и даже целого датацентра. Обычно это делается "на уровень выше" относительно самого кода приложения, путем добавления в систему как минимум резервных (активных или пассивных) копий всех компонентов и балансировщика нагрузки, способного обнаруживать неполадки и соответствующим образом перенаправлять поток запросов. Балансировщик нагрузки также нуждается в выделении под него как минимум двух серверов с переключением на уровне DNS. Возвращаясь к изначальной теме: если уж приложение способно пережить экстренный сбой любого компонента, то и без всякой горячей замены спокойно переживет его плановый перезапуск в связи с обновлением. Хотя на практике даже при резервировании всех компонентов небольшая доля запросов может быть потеряна или обработана за неприемлемо длинный срок в процессе перемаршрутизации их потока.

Казалось бы клиент-серверные приложения чаще всего не имеют состояния, в том плане, что все состояние находится в какой-то внешней сущности вроде СУБД, так что инициализировать особо нечего и состояние потерять не жалко. И на самом деле часто так и бывает, в том же мире PHP довольно популярна практика: положить новую версию кода в соседнюю папочку, поменять document root в конфиге nginx, попросить nginx перечитать свой конфиг - максимум сбросится кэш APC или xcache, что мало кого волнует, так как побочным эффектом будет просто несколько ответов на запросы медленнее обычного.

А как быть с самой СУБД? Например, Redis при запуске зачитывает в память все данные прежде чем начать принимать запросы, что может занимать сколько-то минут. Другие СУБД, которые могут отвечать на запросы и по данным на диске, стартуют относительно быстро, но провал в их производительности до того, как разогреется встроенный в них кэш, заметен невооруженным глазом. Очень похожа ситуация и с брокерами сообщений вроде RabbitMQ: если они и хранят данные на диске, то скорее как резервную копию. А memcached, Redis без персистентности и другие хранилища данных в памяти вовсе могут разогреваться после перезапуска неопределенно долго, так как наполняются по мере поступления запросов на запись.

В языках программирования, основанных на байт-коде и виртуальных машинах, зачастую есть возможность осуществлять горячее обновление кода без перезапуска самой виртуальной машины. Когда говорят про Erlang, очень часто упоминают эту возможность как одно из ключевых преимуществ платформы, так как она хорошо сочетается с её системой легковесных не зависящих от ОС процессов и встроенного в виртуальную машину эффективного хранилища данных в памяти (ETS). В мире Java это тоже возможно, но используется намного реже и позиционируется скорее как инструмент для отладки. В момент подмены кода в работающей виртуальной машине языка программирования с точки зрения ОС ничего не меняется: все открытые соединения, файловые дескрипторы и выделенная оперативная память остаются за ней, то есть она выступает своего рода посредником между одновременно загруженными двумя версиями кода, одна из которых будет выгружена из памяти, как только закончит свою работу и передаст все "дела" новой. Хотя это очень поверхностное описание, на практике всплывает масса нюансов вроде миграции состояний процессов в обе стороны, совместимости протоколов взаимодействия и пр. Плановый перезапуск в данной схеме нужен лишь для обновления самой виртуальной машины, что обычно требуется намного реже, чем обновление кода приложения.

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

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

Основы Erlang: синтаксис и пунктуация

Иван Блинков — Fri, 22 Jun 2012 01:27:00 +0400

Мои теоретичесие рассуждения о месте Erlang в ~~современном мире~~ Интернете Вы можете почитать в отдельной статье. Если сомневаетесь интересно Вам это все или нет - то прочтите сначала её. Сегодня я постараюсь вернуться с небес на землю и пройтись по азам этого пугающего многих языка программирования. Коротко и по делу.

Установка ничем особым не выделяется, дистрибутив рекомендую брать отсюда, если до сих пор пользуетесь отсутствующей в списке ОС - лучше сначала исправить этот факт.

После установки в $PATH окажутся исполняемые файлы:

erl - одновременно интерактивная консоль и запуск приложений;
erlc - компилятор в байт-код для виртуальной машины BEAM или нативный код посредством HiPE, напрямую использовать не придется практически.

Со всем что будет обсуждаться в этой статье можно эксперементировать просто в интерактивной консоли, которая запускается просто командой erl без аргументов.

Пунктуация

Сразу скажу, что пунктуация в Erlang довольно своеобразна, больше похожа на русский язык, чем на другие языки программирования. По крайней мере я именно этой ассоциацией пользовался, когда запоминал.

Все функции заканчиваются точкой
После каждого выражения в функции - запятая;
Все ветви кода (case, if, ...), кроме последней, заканчиваются точкой с запятой
После заголовка функции и условий ветвления пишется стрелка ->

Маленькая демонстрация:

foo(X, Y) ->
  Z = X * X,
  if
    Y > 0 ->
      Z + Y;
    true ->
      Z - Y
  end.

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

Синтаксис

Foo - все что начинается с английской заглавной буквы - переменная, специально объявлять ничего не нужно
_ - сам знак нижнего подчеркивания и все что с него начинается - особый случай переменной, значение которой не значимо для программы и при первой возможности "выкидывается"
Цифры в основном как обычно, есть научная нотация в духе 1.23e4 (1.23 умножить на 10 в степени 4) и системы исчисления с другим основанием, скажем двоичная - 2#101010
foo - с строчной буквы начинаются атомы, по сути константы, используются повсеместно:
- названия функций и модулей
- true и false - булевые значения
- ok - типичный результат успешный результат выполнения
?FOO - хоть официально и называются константами, но по сути - макросы, перед компиляцией заменяются на заранее определенный кусок кода
{foo, bar} - кортеж, набор данных фиксированной длины
[foo, bar] - простой однонаправленный список произвольной длины
"foo" - текстовая строка, представленная в виде однонаправленного списка (что не эффективно с точки зрения потребления памяти, до 4 байт на символ)
<<"foo">> - бинарная строка, может содержать что угодно, в.т.ч. и текст; все что не цифры по возможности лучше хранить в этом типе данных.

Сопоставление (pattern matching)

Очень мощная концепция сопоставления используется в Erlang на каждом углу. В базовом варианте работает примерно так:

{ok, Result} = foo().

Если в функции foo все прошло нормально, то она возвращает, например {ok, 123}, и переменной Result окажется лишь значение 123.

Если же возникла какая-то проблема, то она вернет что-то другое, скажем {error, timeout}, приложение столкнется с несоответствием левой и правой части (атомы ok и error разные) и прекращает свое выполнение (если бы было чего выполнять).

Базовый принцип, надеюсь, понятен. Подобным образом выбирается какую из реализаций функции использовать, в какую ветвь case идти и т.п. В общем есть много других более сложных применений, но о них в другой раз.

Списки

Со списками есть три особые операции:

[Head | Tail ] = [1, 2, 3, 4] - вытащить элемент с головы списка, работает по принципу сопоставления, в Head окажется 1, а в Tail - [2, 3, 4]
[1, 2] ++ [3, 4] - конкатенация, результатом будет [1, 2, 3, 4]
[N * N || N <- [1, 2, 3], N > 1] - выглядит замороченно, по сути это обычный отображение (map) с фильтрацией (filter) - то есть выражение перед || применяется к каждому элементу списка, значение которых попадает в переменную N, а после запятой - условие, накладываемое на N; таким образом результат будет [4, 9]

Бинарные строки

C ними намного больше всяких трюков и преобразований, приведу наиболее значимые:

Binary = <<Integer:64>> - преобразовать целое число Integer в бинарную строку Binary длиной 64 бита (для примера, может быть любой
<<Integer1:32, Integer2:32>> = Binary - распокавать обратно бинарную строку в целые числа, но уже два по 32 бита; чем-то похоже на операцию [H | T] у списков, но намного более гибко
Binary3 = <<Binary1/binary, Binary2/binary>> - конкатенация бинарных строк, результат окажется в Binary3
<< <<(N * N)/integer>> || <<N>> <= <<1, 2, 3>>, N > 1 >> - аналог последнего примера для списков, только для бинарных данных; результат аналогичен - <<4, 9>>; к слову официально это называется binary comprehensions, а для списков - list comprehensions

Заключение

Очень многое пришлось опустить, иначе самое главное затерялось бы, да и объем статьи сильно вырос. Подробности всегда можно найти на официальном сайте, в man'ах, да и просто погуглив.

Удачного освоения Erlang!

Как работает epoll?

Иван Блинков — Fri, 17 Feb 2012 16:27:00 +0400

Слово epoll сейчас определенно на слуху, в первую очередь благодаря росту популярности неблокирующих HTTP-серверов. При этом мало кто пытается разобраться в том, что, собственно, за ним стоит и почему использующие этот механизм продукты, среди которых достойное место занимают, например, nginx, node.js и Tornado, так значительно выигрывают в производительности у ближайших альтернатив. Хотите копнуть глубже?

О чем пойдет речь?

epoll является масштабируемой неблокирующей системой уведомления о собятиях ввода-вывода в Linux. В отличии от более старых механизмов, у epoll время срабатывания не зависит от количества открытых файловых дескрипторов.
epoll используется для обработки событий неблокирующих TCP-сокетов, операционная система оповещает приложение когда один из сокетов "под наблюдением" готов получить или отправить сообщение. В традиционном же подходе на каждый сокет выделяется поток выполнения (thread), который блокируется до возвращения обращения к соответствующему сокету.

Сразу хочу предупредить, хоть на практике epoll и используется чаще, существуют и альтернативные реализации схожего подхода, например kqueue в BSD системах. Конечные продукты обычно используют библиотеку, абстрагирующуе низкоуровневые вызовы, наиболее распросраненные - libev и libevent.

Что это дает?

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

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

Потоки выполнения в блокирующей модели имеют относительно короткий жизненный цикл и рано или поздно освобождают выделенную им память, процесс обработки неблокирующих соединений живет существенно дольше и намного более уязвим для утечек памяти.
Использование одного системного процесса без пула потоков выполнения ограничивает приложение использованием лишь одного процессорного ядра, что делает такой подход менее пригодным для приложений, в значительной мере использующих вычислительные ресурсы. В большинстве же случаев приемлемым решением является запуск нескольких одинаковых копий приложения на одном сервере по количеству процессорных ядер.
Ошибки в коде могут негативно повлиять на работу всего процесса приложения, в то время как в блокирующей модели потоки выполнения обычно достаточно изолированы друг от друга.

На пальцах

Вернемся к изначальному вопросу статьи: Как работает epoll? Давайте попробуем разобрать на простом примере.

Представьте себе пиццерию (физический сервер). Вы (приложение или HTTP-сервер) получаете заказы (обращения на сокет, например HTTP-запрос) на выпечку пиццы (ответы на обращение, например HTML-документы). Есть два сценария, по которым можно их обрабатывать.

Блокирующий (традиционный)

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

Вы ограничены как количеством печей, так и количеством помощников, которые могут поместиться в вашей пиццерии.

Неблокирующий (epoll и аналоги)

Вы принимаете заказ, ставит пиццу в печь и ставите таймер (операционная система посредством epoll), чтобы узнать когда пицца испечется. После чего Вы возвращаетесь к приему заказов. Как только прозвенел таймер - Вы идете к соответствующей печи, достаете пиццу и отдаете заказчику, после чего снова возвращаетесь к приему заказов.

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

Заключение

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

Буду рад услышать дополнения и поправки в комментариях, до новых встреч!

Новое поколение MapReduce в Apache Hadoop

Иван Блинков — Sat, 19 Feb 2011 21:23:00 +0300

В большом бизнесе использование нескольких больших кластеров с финансовой точки зрения более эффективно, чем много маленьких. Чем больше машин в кластере, тем большими наборами данных он может оперировать, больше задач могут выполняться одновременно. Реализация MapReduce в Apache Hadoop столкнулась с потолком масштабируемости на уровне около 4000 машин в кластере. Разрабатывается следующее поколение Apaсhe Hadoop MapReduce, в котором появится общий планировщик ресурсов и отдельный мастер для каждой отдельной задач, управляющий выполнением программного кода. Так как простой оборудования по техническим причинам обходится дорого на таком масштабе, высокий уровень доступности проектируется с самого начала, ровно как и безопасность и многозадачность, необходимые для поддержки одновременного использования большого кластера многими пользователями. Новая архитектура также будет более инновационной, гибкой и эффективной с точки зрения использования вычислительных ресурсов.

Предистория

Текущая реализация Hadoop MapReduce устаревает на глазах. Основываясь на текущих тенденциях в размерах кластеров и нагрузок на них, JobTracker требует кардинальных доработок, чтобы исправить его дефекты в области масштабируемости, потребления памяти, многопоточности, надежности и производительности. С точки зрения работы с Hadoop при каждом обновлении кластера (даже если это просто багфикс), абсолютно все компоненты кластера, так и приложений, которые на нем работают, должны быть обновлены одновременно. Это так же очень неудобно, так как каждый раз необходимо тестировать все приложения на совместимость с новой версией.

Требования

Прежде чем кардинально что-то менять в Hadoop mapreduce, необходимо понять какие же основные требования предъявляются к вычислительным кластерам на практике. Наиболее значительными требованиями к Hadoop следующего поколения являются:

Надежность
Доступность
Масштабируемость - кластеры из как минимум 10 тысяч машин, 200 тысяч вычислительных ядер и даже больше
Обратная и прямая совместимость - возможность быть уверенным, что приложение будет работать на новой версии так же, как оно работало на старой
Контроль над обновлениями
Предсказуемые задержки
Эффективное использование ресурсов

Среди менее значительных требований:

Поддержка альтернативных парадигм разработки (помимо MapReduce)
Поддержка сервисов с коротким жизненным циклом

Если учесть перечисленные выше требования, то становится очевидно, что инфраструктура обработки данных в Hadoop должна быть кардинальным образом изменена. В сообществе Hadoop люди в целом приходят к общему мнению, что текущая архитектура MapReduce не способна решить текущие задачи, которые перед ней ставится, и что требуется кардинальный рефакторинг кодовой базы.

MapReduce следующего поколения

Фундаментальной идеей смены архитектуры является разделение двух основных функций JobTracker'а на два отдельных части:

управление ресурсами;
планирования и мониторинга задач.

В итоге появляется несколько новых ролей:

ResourceManager управляет глобальным распределением вычислительных ресурсов между приложениями;
ApplicationMaster управляет планированием и координацией внутри приложения;
NodeManager управляет процессами в рамках одной машины.

ApplicationMaster представляет собой библиотеку, с помощью которой можно получить у ResourceManager квоту на вычислительные ресурсы и работать с NodeManager(ами) для выполнения и мониторинга задач.

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

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

По одному ApplicationMaster запускается для каждого приложения, они ответственны за запрос необходимых ресурсов у планировщика, запуск задач, отслеживание статусов, мониторинг прогресса и обработку сбоев.

Архитектура

Улучшения по сравнению с текущей реализацией MapReduce

Масштабируемость

Разделение управления ресурсами и прикладными задачами позволяет горизонтально расширять кластер более просто и эффективно. JobTracker проводит значительную часть времени пытаясь управлять жизненным циклом каждого приложения, что часто может приводить к различным происшествиям - переход к отдельному менеджеру для каждого приложения является значительным шагом вперед.

Масштабируемость особенно важна в свете текущих трендов в оборудовании - на данный момент Hadoop может быть развернут на кластере из 4000 машин. Но 4000 средних машин 2009го года (т.е. по 8 ядер, 16Гб памяти, 4Тб дискового пространства) только вдвое менее ресурсоемки, чем 4000 машин 2011го года (16 ядер, 48гб памяти, 24Тб дискового пространства). Помимо этого с точки зрения операционных издержек было выгоднее работать в еще больших кластере от 6000 машин и выше.

Доступность

ResourceManager использует Apache ZooKeeper для обработки сбоев. Когда ResourceManager перестает работать, аналогичный процесс может быстро запуститься на другой машине благодаря тому, что состояние кластера было сохранено в ZooKeeper. При таком сценарии все запланированные и выполняющиеся приложения максимум лишь перезапустятся.
ApplicationMaster - поддерживается создание точек восстановления на уровне приложений. ApplicationMaster может восстановить работу из состояния, сохраненного в HDFS, в случае сбоя.

Совместимость протокола

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

Инновационность и гибкость

Основным плюсом предложенной архитектуры является тот факт, что MapReduce по сути становится просто пользовательской библиотекой. Вычислительная же система (ResourceManager и NodeManager) становятся полностью независимыми от специфики MapReduce.

Клиенты получат возможность одновременного использования разных версий MapReduce в одном и том же кластере. Это становится тривиальным, так как отдельная копия ApplicationMaster'а запускается для каждого приложения. Это дает гибкость в исправлении багов, улучшений и новых возможностей, так как полное обновление кластер перестает быть обязательной процедурой. Это позволяет клиентам обновлять их приложения до новых версий MapReduce вне зависимости от обновлений кластера.

Эффективность использования вычислительных ресурсов

ResourceManager использует общую концепцию для управления ресурсами и планирования по отношению к каждому конкретному приложению. Каждая машина в кластере на концептуальном уровне рассматривается просто как набор ресурсов: память, процессор, ввод-вывод и др. Все машины взаимозаменяемы и приложение может быть назначено на любую из них, основываясь на доступных и запрашиваемых ресурсах. При этом приложения работают в контейнерах, изолированно от других приложений, что дает сильную поддержку многозадачности.

Таким образом эта схема избавляет от текущего механизма map и reduce слотов в Hadoop, который негативно влияет на эффективную утилизацию вычислительных ресурсов.

Поддержка других парадигм программирования помимо MapReduce

В предложенной архитектуре используется общий механизм вычислений, не привязанный конкретно к MapReduce, что позволит использовать и другие парадигмы. Имеется возможность реализовать собственный ApplicationMaster, способный запрашивать ресурсы у ResourceManager и использовать их в соответствии с задачей, при этом сохраняются общие принципы изоляции и гарантированного наличия полученных ресурсов. Среди потенциально поддерживаемых парадигм можно назвать MapReduce, MPI, Мaster-Worker, итеративные модели. Все они могут одновременно работать на одном и том же кластере. Это особенно актуально для приложений (например К-средний или Page Rank), где другие подходы более чем на порядок эффективнее MapReduce.

Выводы

Apache Hadoop, и в частности Hadoop MapReduce - очень успешный opensource проект по обработке больших объемов данных. Предложенный Yahoo путь его переработки направлен на исправление недостатков архитектуры текущей реализации, при этом повышая доступность, эффективность использования ресурсов и предоставляя поддержку других парадигм распределенных вычислений.

Осталось дело за малым - собственно реализовать задуманное! :)

Источник информации

Подписаться на RSS можно здесь.

Инструменты для минимизации размера изображений

Иван Блинков — Sun, 13 Feb 2011 10:44:00 +0300

В то время как масштабируемость серверной части интернет проекта - сложное дело, требующее тщательного планирования, большинству сайтов можно обойтись существенно более простыми способами для повышения визуального быстродействия с точки зрения пользователей. О небольшой части из них я и хотел Вам сегодня рассказать.

Мотивация

Если воспользоваться инструментами для анализа времени загрузки страницы (например Firebug или Chrome Developer Tools), то не сложно обратить внимание на тот факт, что во многих случаях существенную часть ожидания загрузки страницы проходит в процессе загрузки внешних файлов, требуемых для рендеринга страницы:

Изображения
Файлы стилей
Файлы JS-скриптов

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

Вынести на отдельный (под)домен (позволяет браузеру качать больше файлов одновременно)
Отредактировать HTML для избежания блокировок (так называемого "водопада")
Настроить HTTP-сервер на предмет правильных заголовков Expires и Etags
Воспользоваться для отдачи статики nginx или аналогом
Сменить интернет-канал у сервера или сам сервер
Воспользоваться услугами CDN (Content Delivery Network)
Уменьшить размер передаваемых файлов

Сейчас я хочу остановиться на последнем пункте в отношении изображений, про скрипты, стили и остальные методы стоит поговорить отдельно в другой раз.

Выбор правильного формата изображений

Первым шагом по снижению объемов изображений должен быть выбор адекватного назначению изображения формата:

JPEG - для всех фотографий
GIF - исключительно для анимации (например для крутящейся загрузки)
PNG - для всего, что не является фотографией или анимацией: иконки, графики, элементы интерфейса

GIF

На многих сайтах до сих пор по старинке используется этот формат изображений, не смотря на то, что PNG при таком же качестве имеет меньший размер файлов.

Рецепт лежит на поверхности: конвертируйте все GIF в PNG. Проще всего это сделать с помощью ImageMagick:

# Конкретный файл
$ convert foo.gif foo.png

# Все файлы в директории
$ mogrify -format png *.gif

# Или OptiPNG:
$ optipng *.gif

Дальше все просто: работаем с этими изображениями как и с остальными PNG, о чем пойдет речь ниже.

PNG

К сожалению, многие редакторы изображений сохраняют PNG-файлы совершенно не заботясь об их размере.

Но за многие годы была разработана масса различных утилит, исправляющих данную ситуацию. Основных принципа, на которых они основываются, четыре:

Удаление лишнего: так как PNG - расширяемый формат, далеко не все данные и заголовки требуются для отображения изображения в браузере. Их можно смело выкинуть.
Изменение типа PNG: использование только оттенков серого или произвольной палитры приемлемо для многих случаев, что по сравнению с полной гаммой существенно снижает размер изображения
Использование подходящего "фильтра": они являются шагом перед сжатием изображения, правильный фильтр позволяет компрессии работать эффективнее
Оптимизация самой компрессии: использование более эффективного алгоритма

Примеры использования наиболее эффективных инструментов:

# optipng
$ optipng -o7 foo.png

# pngcrush
$ pngcrush -rem alla -brute -reduce foo.png foo.png.temp
$ mv foo.png.temp foo.png

# pngout
$ pngout foo.png

# advpng
$ advpng -z4 foo.png

JPEG

В отличии от PNG и GIF каждое сохранение JPEG файла приходят к потерям данных и, как следствие, снижению качества фотографии, без потерь могут выполняться только изменение комментариев, метаданных и повороты на 90/180/270 градусов. Основным инструментом для минимизации JPEG без потери качества является jpegtran, используется достаточно просто:

# обычный режим
$ jpegtran -copy none source.jpg > destination.jpg

# режим progressive
$ jpegtran -copy none -progressive source.jpg > destination.jpg

Прогрессивный режим заслуживает отдельного внимания:

Основная особенность - в нормальных браузерах (не IE) такой JPEG быстро отображается в низком качестве, а по мере загрузки файла полностью качество изображения улучшается (обычный JPEG грузится сверху вниз)
По объему файла этот тип JPEG начинает выигрывать у обычного начиная от размера файла в 10Кб
Изображение менее 10Кб все равно слишком маленькое, чтобы от самого процесса прогрессивной загрузки был какой-либо толк
Если хочется подробнее разобраться - читаем здесь

Заключение

Использование простых инструментов, описанных выше, позволяет сократить общий размер используемых на веб-странице изображений порой до 30%, а то и больше. Эффект, который дает этот процесс, конечно же зависит от "запущенности" ситуации, но в большинстве случаев тоже измеряется десятками процентов от общего времени загрузки страницы. Чтобы воспользоваться ими требуется всего несколько минут, что существенно меньше, чем попытки оптимизировать код или запросы к базе данных, не говоря уже о полной переработке архитектуры системы.

Если кто-то знает более эффективные приемы по уменьшению размеров изображений - прошу в комментарии. Про скрипты и стили поговорим отдельно :)

Основным источником информации послужила статья Stoyan Stefanov, которую я сильно подсократил до тех инструментов, которыми пользуюсь сам на практике, и моментов, которые считаю интересными. Желающим покопаться в этой тематике поглубже рекомендую изучить весь его блог - можно найти много интересного. Про подписку на Insight IT тоже не забываем)

Piccolo - построение распределенных систем в 11 раз быстрее Hadoop

Иван Блинков — Sat, 12 Feb 2011 23:49:00 +0300

Piccolo - это система для распределенных вычислений, использующая новую ориентированную на данные модель программирования для разработки приложений по параллельным вычислениям в памяти в масштабах дата-центров. В отличии от существующих моделей, основывающихся на потоках данных, Piccolo позволяет вычислениям выполняться на различных машинах, при этом имея общее изменяющееся состояния через интерфейс таблиц пар "ключ-значение". Традиционные ориентированные на данные модели (такие как используются в Apache Hadoop) предоставляют пользователю для работы лишь единственный объект в определенный момент времени, когда в Piccolo используется глобальная таблица состояний, одновременно доступная для всех частей вычисления. Это позволяет пользователям указывать алгоритм вычисления в интуитивно-понятной манере, очень похожей на разработку программ для одного компьютера.

Использование хранилища, позволяющего хранить в памяти пары "ключ-значение", сильно отличается от канонического подхода map-reduce, который основан на распределенных файловых системах. Результаты впечатляют:

Эксперименты показали, что Piccolo очень быстр и отличные возможности по масштабируемости для многих прикладных задач. Производительность вычисления PageRank и k-средних выросла в 11 и 4 раза, соответственно, по сравнению с Hadoop. Вычисление PageRank для связанного графа из 1 миллиарда страниц заняло лишь 70 секунд на 100 машинах в Amazon EC2. Распределенная система по скачиванию веб-страниц легко может полностью загрузить 100Мбит интернет-канал при работе на 12 машинах.

При разработке на Piccolo программисты создают наборы прикладных функций, которые принято называть ядром. Функции ядра запускаются параллельно на нескольких вычислительных узлах, при этом у них есть доступ к общему изменяемому состоянию, которое реализовано в виде набора таблиц, располагающихся в оперативной памяти различных узлов системы. Для доступа к этому состоянию используется примитивный интерфейс, позволяющий узнать (get) и изменить (put) то или иное состояние. Процесс отправки сообщений удаленным узлам, непосредственно имеющим в памяти требуемые данные, полностью берет на себя сам код Piccolo.

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

Алгоритмы, основанные на общем промежуточном состоянии, могут быть реализованы естественным, логичным и эффективным образом
Асинхронные online приложения получают возможность иметь оперативный доступ к новым и изменившимся данным, расположенным на других узлах системы

В Piccolo используется ряд оптимизаций, обеспечивающий не только удобное использование интерфейса к таблице состояний, но и его быстроту:

Локальность - для обеспечения выполнения локальности исполнения, таблицы явным образом разбиваются на части, располагающиеся на разных машинах. В пользовательском коде при взаимодействии с таблицами доступна настройка локальности, обеспечивающая выполнение кода на том же узле, где располагаются даннын.
Балансировка нагрузки - далеко не вся нагрузка равномерна, часто какая-то часть вычислений требует намного больше ресурсов, чем все остальные. Ожидание без дела пока такая задача будет выполнена впустую тратит ценное время и ресурсы. Для решения данной проблемы Piccolo может мигрировать часть задач с загруженных машин на простаивающие, при этом сохраняя настройки локальности и корректность выполнения программы.
Обработка сбоев - сбои оборудования неизбежны и обычно они случаются в самые критические моменты. Piccolo делает создание контрольных точек и восстановление простым и быстрым, обеспечивая быстрое восстановление в случае сбоев.
Синхронизация - управление корректной синхронизацией и обновлениями в условиях распределенной системы может быть сложным и медленным. Piccolo позволяет пользователям поручить реализацию логики синхронизации системе. Вместо явной блокировки таблиц при выполнении обновлении данных, пользователи могут присоединять аккумулирующие функции к таблицам: они используются автоматически системой для корректного комбинирования параллельных обновлений ячеек таблиц.

Проект реализован в виде библиотеки для Python и C++. Более детально примеры использования и принципы работы системы разбираются в источниках информации (правда на английском), не поленитесь - загляните. Вместо заключения хотелось бы по традиции порекомендовать подписаться на RSS блога, если Вы еще этого не сделали.

Источники информации

Russell Power - автор проекта Piccolo
Piccolo: Building Fast, Distributed Programs with Partitioned Tables
Проект был презентован на OSDI10: презентация и видео

HighLoad++ 2010

Иван Блинков — Sun, 31 Oct 2010 23:24:00 +0300

25-26 октября прошла конференция HighLoad++ 2010, посвященная разработке высоконагруженных систем. После конференции у меня сразу родились планы на два поста: типичный отчет и описание архитектуры Вконтакте. С порядком написания я, видимо, не прогадал - получился один из самых успешных постов на Insight IT. Остальные доклады на мероприятии были, пожалуй, существенно менее животрепещущими для общественности, но все же не менее интересными. Приступим.

Организационные моменты

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

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

Во-вторых, удивила ситуация со связью со внешним миром: интернет был на очень хорошем для конференций уровне - тупил местами, но в целом стабильно работал, а вот мобильная связь не работала практически совсем - уезжал домой с почти севшим телефоном.

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

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

Еще очень порадовало, что презентации первого дня конференции были уже доступны участникам еще за пару часов до окончания первого дня. Но вот с оставшимися презентациями и видео с мероприятия видимо произошла какая-то заминка и я так и не получил ссылку на них до сих пор, судя по всему они так и не доступны.

День первый

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

После приветственного слова Олега Бунина (одного из основных организаторов конференции) слово взял Joe Damato, которого позиционировали как известного хакера, активно работающего над развитием Ruby. Темой выступления был обзор различных инструментов и приемов для анализа ситуации в серверном Linux-окружении. Некоторые моменты были мне известны и ранее, но в целом больше половины доклада было для меня очень интересно и ново. Перечислять упомянутые им приемы я, честно говоря, не вижу смысла - будет просто дублирование презентации. Если ранжировать доклады первого дня по интересу лично для меня, то это выступление заняло бы, пожалуй, второе место.

Вторым докладчиком был также приверженец секты Рубистов, James Golick, один из основателей социальной сети для фетишистов (простите за отсутствие ссылки). Основной фишкой доклада было "разоблачение мифов", в частности об облачных вычислениях и NoSQL. Количество пользователей этой социальной сети, но они очень активны и генерируют достаточно много контента (особенно по Российским меркам). Проект изначально располагался в компании, которая предоставляла услуги managed hosting (хостинг на арендуемых серверах + за тебя администрируют), но они посчитали, что слишком много переплачивают за этот самый "managed", и решили поддаться тренду и переехать в облако (Amazon EC2). По деньгам получилось не сильно дешевле, но больше всего из расстроила производительность виртуальных машин (кажется, был слайд со скоростью доступа к дисковой подсистеме, выставляющий облако не в лучшем свете). Второй эпопеей в их проекте были попытки оптимизировать подсистему хранения данных путем перенесения ее части в NoSQL хранилище: пробовали MongoDB (выкинули из-за блокировок на операциях удаления) и Cassandra (выкинули из-за медленного случайного чтения). Финальным решением стал Redis + MySQL, просто и со вкусом - их всецело устраивает на данный момент, как я понял.

Третьим выступал Robert Johnson из Facebook, доклад был практически таким же, как и в ГУ-ВШЭ за несколько дней до этого - о нем я уже писал, так что подробно останавливаться не буду. Основным отличием были дополнительные технические детали, но подавляющее большинство из них и так уже были описаны в статье "Архитектура Facebook".

После обеда выступал Patrice Pelland из Microsoft, доклад был о том, как работают их облачные сервисы (видимо live, skydrive и прочие). Естественно все на их же продуктах, большинство названий я даже не слышал. Единственное, что запомнил из выступления - у мелкомягких есть даже клон memcached, но с какими-то дополнительными плюшками. Это был единственный доклад, после которого никто не захотел задать даже одного вопроса, что в целом наглядно продемонстрировало незаинтересованность аудитории в платных решениях. В твиттере после этого выступления проскользнула обиженная фраза докладчика, что-то в духе: "До них просто не дошло, о чем я говорил".

После этого недоразумения от MS началась длинная серия докладов от людей, причастных к созданию PostgreSQL:

Simon Riggs из 2nd Quadrant
Robert Treat из Omni TI
Bruce Momjian из EnterpriseDB

Было 5 выступлений о PostgreSQL подряд:

Повышение производительности
Управление репликацией
Масштабирование
Быстрая смена версии средствами pg_update
Потоковая репликация

В целом очень актуальные доклады, если Вы плотно работаете с PostgreSQL в своем проекте или на своей работе. Я вообще тоже когда стоит выбор между доступными реляционными СУБД чаще всего склоняюсь к PostgreSQL, но доклады были детализированными не там, где нужно, и было скучновато. В этой секции порадовали три вещи:

очень качественный английский у докладчиков
забавная манера выступления Роберта, особенно про красные кроки (что-то типа галош)
активная реклама новых вкусностей PostgreSQL 9.0, релиз которой я по каким-то причинам проворонил - надо будет обязательно попробовать ее в деле

После кофе-брейка я пошел на больше всего понравившийся мне доклад (за первый день) - выступал Stoyan Stefanov из Yahoo! Темой доклада была заявлена неочевидная формулировка "Progressive Downloads and Rendering", хотя на самом деле все свелось к грамотно построенному докладу о клиентской оптимизации: несколько вводных картинок, один слайд с базовыми приемами и много-много примеров очевидных и не очень случаев, когда с точки зрения пользователя сайт начинает тупить, даже если серверная часть проекта написано грамотно и работает достаточно быстро. По некоторым аспектам, в частности про кроссбраузерному использованию data:URL+MHTML, он ссылался на русские источники, а также очень позитивно отзывался о Николае Мациевском.

Последним, что я посетил в первый день, была "открытая встреча" c James Golick и Joe Damato про сам Ruby. Ожидал большего: в итоге Joe вообще не выступил, а большая часть времени ушла на разжёвывание базовых возможностей языка и несколько мелких холиваров.

День второй

На второй день я немного проспал и приехал ближе к концу первого доклада: оказалось, что я не один такой - людей было раза в три меньше, чем за день до этого. Выбор потока куда пойти был легок: в первом зале все утро было посвящено Python, с которым я последнее время довольно плотненько работал.

После докладов на английском "отечественные" выступления смотрелись совсем блекло. Конец выступления Андрея Смирнова про Twisted не принес мне хоть какой-либо полезной информации, тем более мне все равно больше по душе Tornado. Вопрос про их сравнение от одного из слушателей вызвал у докладчика рассказать историю о том, как будущий автор Tornado тусовался в сообществе Twisted, а потом взял и сделал свой продукт.

Следующий доклад был про профилирование памяти в Python от Антона Грицая - начал он историю очень издалека, с того что такое утечки памяти, какие бывают "сборщики мусора", какие есть варианты искать утечки в Python и чем они плохи, собственно до "дела" он дошел лишь к концу доклада. Было предложено пользоваться продуктом под названием heapy, который обладает широким спектром возможности, но при этом документация сильно хромает.

Последним докладом в секции про Python было выступление трех бравых ребят из HeadHunter, которые рассказывали про их внутренний продукт под названием Frontik, представляющий собой надстройку над Tornado, аггрегирующую данные с нескольких HTTP-сервисов. В целом идея мне понравилась, но ввиду исторических причин реализация у них накручена очень муторно:

основной формат передачи данных - XML по HTTP
генерация HTML посредством XSLT
регулярные выражения где надо и где не надо (для повышения производительности)

Основным событием оставшейся части второго дня, как Вы уже наверное поняли, был аншлаг с участием Вконтакте и лично Павлом Дуровым в главной роли. Результаты подробно расписаны в статье "Архитектура Вконтакте", повторяться не буду, с Вашего позволения.

Остальные доклады я застал лишь частями, так как блуждал по залам без особого энтузиазма, да и в толпе вокруг Павла чуток потусовался. Расскажу вкратце запомнившиеся моменты:

Юрий Востриков из Mail.ru рассказывал про Tarantool/Silverbox - еще после их технологического форума подумываю попробовать этот продукт в деле, но после этого выступления понял, что пока рановато: не известно ни об одном успешном применении вне компании-разработчика, да и библиотеки с реализацией полноценного протокола есть далеко не под все языки программирования.
На доклад про реализацию одного из топовых приложений Вконтакте на Rails я попал почти к самой сессии вопросов-ответов, запомнился только тот факт, что после того как компания, в которой работал докладчик, передала приложение заказчику - они почти сразу же переписали его на PHP. Заставляет задуматься.
В третьем, дополнительном, зале во второй половине дня расположился тренинг Start in Garage для людей, планирующих сделать свой стартап; ребята рассказывали весело и непринужденно, но по сути все было очень примитивно - ушел минут через 20 после начала на аншлаг вконтакте.
Про Scalaxy было бы интересно написать отдельную статью, больно часто они всплывают на конференциях и в онлайн-сообществах. На этот раз рассказывали о том, как они выделяют избыточные дисковые массивы для виртуальных машин (которые они собственно в аренду сдают). Технология называется Vast Sky, родом откуда-то из Азии, позволяет легко выделять заданное количество блоковых устройств на разных дисковых системах и подключать их к виртуальной машине в виде софтверного RAID. В сочетании с их QDR Infiniband от Voltaire работает очень даже шустро (по крайней мере если верить их бенчмаркам по сравнению с альтернативными технологиями).
Scalaxy же запускает сервис ddosme, предназначенный для нагрузочного тестирования интернет-проектов. Попал опять только на вопросы-ответы, из них понял, что они предлагают через прокси походить по своему ресурсу, затем на основе логов составляются маршруты движения ботов по сайту и тестирование запускается на нужных мощностях. Сколько стоит не понял.
Последним докладом, который я застал краем глаза, было обсуждение основных косяков, мешающих 1С-Битрикс обслуживать пристойное количество пользователей - для меня совершенно не актуальный вопрос, так что после этого я начал собираться в сторону выхода и отправился смотреть "Социальная сеть".

Заключение

Впечатления от конференции очень положительные: большинство докладов хотя бы немного полезны, рекламы вообще минимум, организация на уровне. По-прежнему не знаю стоит ли она своих денег, но потраченного времени точно стоит. Надеюсь в следующем году будет по-проще попасть.

Хотелось бы видеть больше докладов не о конкретных инструментах и технологиях, а о их применении в рамках построения общей архитектуры проекта или решения конкретных нетривиальных задач. Доклады в духе "у нас вот такая классная штука есть, но стоит денег" и "приходите к нам работать, чтобы попробовать в деле эту технологию" как обычно скучны, но вроде их было довольно мало (надеюсь докладчики хотябы платят организатором за возможность порекламироваться?). Приглашенные иностранные гости - ход очень классный, мне кажется основной ключ успеха прошедшего мероприятия, в этом направлении определенно стоит двигаться - хотелось бы увидеть представителей известных проектов (Google, Ebay, Amazon, Flickr, Twitter, Baidu, QQ и.т.д.) и людей, решающих реально нетривиальные задачи, вроде Joe Damato.

В любом случае спасибо организаторам за два с толком проведенных дня :)

Да, думаю Вы уже заметили, что блог Insight IT снова потихоньку возвращается к жизни, так что подписываться на RSS никогда не поздно.

Facebook: how we scaled to 500 000 000 users by Robert Johnson

Иван Блинков — Sat, 23 Oct 2010 01:23:00 +0400

Буквально только что вернулся после насыщенного дня, большую часть которого я провел на RIW2010 (о котором я надеюсь успеть полноценно написать в воскресенье), а вечером я очень рад что собрался таки съездить на выступления Robert Johnson под названием "Facebook: how we scaled to 500 000 000 users" в ГУ-ВШЭ (где я собственно на данный момент и учусь в магистратуре). Сейчас же я хотел бы сосредоточиться именно на последнем мероприятии, благо оно мало того что было существенно более качественным, чем остальные выступления, на которых я был последнее время, так еще и очень сильно коррелирует как в целом с общей нитью данного блога, так и с последним постом в частности.

Прежде чем читать дальше, настоятельно рекомендую ознакомиться с архитектурой Facebook (которую я обновил немного), здесь я постараюсь особо не повторяться и рассказать лишь об общих впечатлениях и новых фактах, которые мне удалось услышать и выяснить.\

Само выступление длилось всего пол часа, было абсолютно без технических подробностей - немного понтов о своих достижениях в плане аудитории и нагрузки (собственно говоря первым слайдом был график роста аудитории по годам), а затем базовые вещи оb построении высоконагруженных систем в духе мол, что масштабироваться надо горизонтально, внимательно следить за SPOF, быстро двигаться вперед с использованием небольших итераций в разработке и.т.п. Аудитория слушала с очень напряженными лицами - для многих определенно было много незнакомых слов и вообще довольно суровое скороговорочное американское произношение мало кому давалось легко на слух.

Технических вопросов было довольно мало (что впрочем не удивительно, т.к. мероприятие проходило в гуманитарном ВУЗе) - превалировали вопросы в духе "что вы делаете с профилями умерших людей" (есть процедура когда друзья/родственники сообщают и если оказывается правдой то специальным образом перенастраивают аккаунт, чуть ли не несколько миллионов таких случаев было), "как работает фича Х" (из интересных фич - скрытие фоток твоих бывших boy/girl friend'ов через face recognition), "как выглядит типичный день разработчика в Facebook" (2/3 пишут код, остальное - всякие остальные виды деятельности), "какие планы развития в России и мире" или "что думаете о конкурентах" (их позиция - делать лучший продукт на рынке и аудитория сама подтянется), еще спрашивали снимался ли он в фильме, о котором последнее время в рунете слухи ходят. Недавно еще у них открылся небольшой венчурный фонд для инвестиций в социальные проекты. Вообще сессия публичных ответов-вопросов длилась около часа и потом еще где-то с полчаса он активно общался с людьми лично, тоже с ним поговорил немного. Под конец общение почти превратилось в фотосессию, я тоже вот решил за компанию сфотографироваться:

Пожалуй хватит воды, перейдем к делу, собственно что же нового для себя я узнал на мероприятии:

С примерно первой половины года их официальная активная аудитория повысилась с 400 до 500 миллионов человек
Штат инженеров (т.е. по-нашему разработчиков и сис. администраторов) увеличился до \~500 человек, примерно стало понятно как они распределены:
- Основной принцип: много небольших узкоспециализированных команд, которым даны полномочия принимать решения и проводить полностью продукт от стадии идеи до стадии реализации
- Около половины работают в "продуктовых" командах, до 5-10 человек в каждой (фотографии, поиск, личные сообщения, и.т.п.)
- Ряд команд, занимающихся общими вопросами (например 4 человека работают над оптимизацией MySQL, еще есть команды по безопасности, приватности, производительности)
- Нестрогий менеджмент, 2 уровня управления
Используются аппаратные балансировщики нагрузки от F5 + некое опенсорсное решение, сказал что возможно nginx, но он не уверен
Виртуализация совсем не используется - на таком масштабе она не актуальна
MySQL-сервера используют подключенные напрямую массивы дисков (direct attached storage)
По вопросам мониторинга кое-где используются nagios и ganglia, но большая часть данной подсистемы написано самостоятельно
Десятки тысяч серверов и десятки гигабит трафика, более точных цифр, к сожалению, не дали
Коммерческого программное обеспечение практически не используется, по большей части собственные разработки и в ключевых местах opensource
Сам спросил про датацентры:
- Santa Clara, California - master (названия мест плохо расслышал, поправьте если ошибаюсь)
- Ashburn, Virginia - read-only slave
- За пределами США присутствие очень небольшое, по паре стоек в нескольких странах - если я правильно понял, то для кэширования статики, т.е. своя CDN
Помимо этого мне было интересно про репликацию между ними:
- Используется модифицированный механизм встроенной репликации MySQL
- Основные доработки: передача помимо собственно данных списка идентификаторов объектов, которые следует инвалидировать из-за текущего обновления + какая-то хитрая система расстоновки флагов о текущем состоянии процесса репликации
DDoS их особо не волнует - сколько-либо серьезных попыток они не встречали, защита аппаратная на уровне ДЦ, как я понял
Намного больше внимания уделяется модерации контента и борьбе со спамом
Развертывание делается максимально плавно, как в плане обновления софта, так и в плане выкатывания новых версий кода сайта (упоминал в статье про архитектуру)
Их позиция касательно opensource:
- Активно использовать и возвращать взамен с улучшениями
- Facebook выгодно возвращать вносимые изменения в популярные opensource проекты, так как они не считают их конкурентным преимуществом (ну и лицензии никто не отменял)
- Если это не делается, то чаще всего т.к. либо используются "грязные хаки и костыли", которые никому кроме них не нужны, либо так как разработчикам не хватает времени привести патч в удобоваримый вид
- Свои проекта также активно публикуются, так как организации вроде Apache Software Foundation берут на себя многие вопросы по поддержке и развитию кода
Apache Hadoop как уже многие писали используется как хранилище и оффлайновый обработчик данных вроде логов, Hive родился как надстройка для упрощения доступа
Хоть сотрудники Facebook и реализовали проект Cassandra, про который активно спрашивали в комментариях как тут, так и на хабре, но они его практически не используют у себя. Как известно он опубликован в opensource и поддерживается ASF. В Facebook он используется (использовался?) только как хранилище для поиска по внутренним сообщениям, мотивация: очень быстрая запись, недостаточная производительность операций случайного чтения
На вопрос про основной дистрибутив линукс и вендоров оборудования он был не особо уверен, но сказал что скорее всего использутся CentOS и они работают с несколькими основными вендорами серверов (HP, IBM, Dell) - свое оборудование (как Google) они не изобретают, так как не считают целесообразным
Используется довольно сильно модифицированное ядро ОС, особенно по части сетевого стека

Мероприятия всякие разные

Иван Блинков — Sat, 02 Oct 2010 17:44:00 +0400

Не знаю как во всем в мире, но в Москве пора айтишных и не очень конференций и мероприятий - это осень. Посещать их я еще не совсем обленился, а вот с написанием отчетов все как-то не складывалось. К сожалению, бюджет не позволил сходить на платные мероприятия, особенно Highload++. В общем в итоге я решил написать этот краткий обзорный пост по мероприятиям, на которые меня занесло этой осенью. Обо многом пишу спустя большое количество времени - возможны неточности и провалы в памяти.

Mail.ru Technology Forum

14 сентября

Честно говоря я подъехал на мероприятие лишь к обеду и не досидел до конца, так что могу лишь прокомментировать середину, то есть самый разгар.

В первую очередь я пошел в технологическую секцию, где Tom Preston-Werner, сооснователь и тех. директор проекта GitHub, рассказывал о том, как устроен их проект, какие технологии и костыли они используют. Если в двух словах, то у них используются три протокола: http, git и ssh, для каждого используется свой маршрут обработки запроса внутри системы. Основными продуктами, которые они используют являются Ruby on Rails, Unicorn, HAProxy, и собственно git и sshd. Вообще возможно стоило бы под эту историю написать отдельный пост - детали явно выходят за рамки данного повествования, а доклад и правда был интересным. Постараюсь вернуться к этой истории как только появится возможность.

Следующими в этом зале выступали представители самого mail.ru - честно говоря у меня хватило терпения слушать их очередное расхваливание Imagine Framework, который можно посмотреть только устроившись к ним на работу, только первые минут 15 наверное и я благополучно перекочевал во второй зал, где основной тематикой были социальные игры. Вообще за последний год мне довелось немного поработать в данной области и секция могла бы оказаться интересной, но качество докладов тоже было не на высоте - ничего нового ни про монетизацию, ни про привлечение аудитории услышать не удалось. В основном доклады представляли собой либо кейсы, основанные на конкретных не очень успешных приложениях, либо на каких-то общих рекомендациях и так лежащих на поверхности.

Кстати еще на одном из докладов представители мэйла заикались о некой NoSQL базе данных их разработки, которую они опубликовали под opensource лицензией - впоследствии попытался найти, но на http://opensource.mail.ru какая-то другая муть расположена, а гуглится что-то совсем не то. Если кто в курсе - поделитесь ссылкой, пожалуйста.

"MIT Way" by Richard Kivel

20 сентября

Ричард в целом продемонстрировал себя как успешного бизнесмена в сфере информационных и био технологий, но при этом практическая ценность его выступления была невелика. Он является презедентом MIT Enterprise Forum, а также председателем правления Rhapsody Biologics. Выступление проходило в здание ГУ-ВШЭ при поддержке HSE Inc.

Основными моментами его выступления были следующие тезисы:

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

Все просто и понятно, но все же еще раз обратить внимание на данные вопросы не помешало, да и дополнительная возможность послушать вживую выступление на качественном английском никогда не бывает лишней.

В итоге правда оказалось, что основная цель данной лекции была вовсе не научить делать технологический бизнес, а привлечь дополнительных участников в сообщество MIT EF, представительство которого недавно открылось и в России. Мотивацией для присоединения к сообществу было как раз расширение сети бизнес-знакомств и контактов, особенно зарубежом. Членские взносы составляют довольно приличную сумму по меркам московских студентов (которых было большинство в зале) - что-то в районе 150\$/год.

Startup Weekend Brainstorm

25 сентября

Мероприятие являлось по сути подготовкой к самому Startup Weekend, о котором я напишу чуть ниже. Организатором обоих мероприятий является компания Главстарт, целью которой является расширение рынка технологических стартапов, для чего они проводят эти самые мероприятия, занимаются подбором экспертов и менторов, а также помогают проектам получить посевные инвестиции.

Как не трудно догадаться, подготовительная часть под названием Брейншторм направлена на генерацию идей для интернет-проектов. Участников мероприятия разбили на группы по интересам, около 20 человек на группу, где под руководством массовика-затейника и эксперта они придумывали различные идеи проектов, сервисов, целевых аудиторий и их потребностей и проблем. За почти целый день у каждой группы получилось около 10 более-менее продуманных идей, из которых гипотетически могли бы вырости проекты на следующем этапе - самом Startup Weekend.

Сами идеи проектов позвольте не озвучивать - многое не помню, да и большинство из не прошедшх отбор были на грани бреда.

Yet Another Conference

1 октября

Наверное самое серьезное из мероприятий, попавших в данный обзор. Организатором конференции являлся Яндекс, попал я опять не к самому открытию ибо пробки и проблемы с парковкой. С организационной точки зрения все замечательно, особенно для бесплатной конференции, разве что еду в перерывах сметали слишком быстро :).

Первый доклад, на который я пришел где-то к середине, вел инженер из Google и рассказывал про data races и инструмент для их поиска ThreadSanitizer - вроде все понятно и на самом деле слабо пересекается с областью моих интересов. Вторым докладом в этой секции шел Intel и уже через 15 секунд после начала стало понятно, что будет сплошная реклама их линейки проектов для разработки многопоточных приложений - сразу же встал и сбежал в соседнюю секцию.

В другом зале была самореклама уже продукта Яндекса, но уже несколько более завуалированная. Речь шла об их собственном веб-сервере Phantom, который они используют в баннерокрутилке. Основной его фишкой является приоритезация хэндлеров запросов в рамках одного сервера. Написан с нуля на плюсах, с использованием корутин и чуть ли не вообще без использования каких-либо библиотек. Основной плюс: в отличии от других докладчиков, рекламирующих свое детище, они хотябы обещали открыть исходные коды продукта как только допилят поддержку протокола FastCGI.

После перерыва я вернулся в первый зал, где началась длинная секция про системы хранения и обработки большого объема данных, я прослушал три доклада:

Apache Hadoop и прочие проекты вокруг него, выступал Константин Швачко из Yahoo. Жалко, что в этом проекте так мало всего изменилось за тот год, что я с ним не работал, даже решение проблемных ситуаций с NameNode толком не решили видимо. Слушал и думал "сколько же я уже раз это все слышал и сам рассказывал другим".
Собственная реализация Map Reduce от Яндекса, Александр Дмитриев. Визуально красиво сделанная презентация, судя по твиттеру очень многим понравилось, правда за этим всем терялась суть доклада - слушал честно говоря краем уха, так как судя по всему публиковать в opensource данный проект они пока не планируют. Специфичная реализация публично-известного подхода, реально приспособленная только под конкретные задачи Яндекса - впечатление осталось именно такое.
Евгений Поляков из Яндекса рассказывал о распределенной хэш-таблице Elliptics Network. Об Эллиптикс я ни разу ранее не слышал, а докладчик рассказывал очень вкусно о данном проекте. Основным плюсом данной системы хранения данных является модульность: особенно интересна возможность использовать различные технологии записи данных на диск, а также различные интерфейсы и протоколы, с помощью которых можно получать доступ к данным. Постараюсь на досуге подробнее изучить вопрос и если обнаружится что-то интересное - опубликовать свое более детальное впечатление о данном проекте.

Поводом сбежать с данной секции стал некий разработчик системы статистики для ЖЖ из SUP Fabrik - молодой человек еле ворочал языком, что делало практически невозможным понимание сути доклада. В другом зале как раз началась медийная секция, опять полная саморекламы. Докладчик из проекта videomost.com (видео-конференции) в целом сосредоточил свое внимание на том, что видео-конференции - это очень сложно, что популярные технологии, часто используемые в видео-трансляциях, там работают плохо - и вообще будущее за проприетарными специализированными протоколами, кодеками и системами. В повестке доклада значились способы обхода firewall'ов и NAT'а - но в докладе все ограничилось лишь большой красивой диаграммкой и фразой что-то в духе "в нашем проекте аж 14 способов решать эти проблемы", без каких-либо деталей.

Второй доклад медийной секции вел Richard Cole, продукт менеджер из Skype, показывал много красивых фотографий с людьми, пользующимися Skype в разных ситуациях. По делу у него был только одно сообщение: скоро для широкой публики будет доступен их SDK, который сейчас находится в стадии бета-тестирования.

Startup Weekend

1-3 октября

Это мероприятие еще не закончилось, я написал этот пост как раз во второй день - по идее в самый разгар. Как уже возможно стало понятно: основная суть мероприятия заключается в превращении идей интернет-проектов в готовые команды и прототипы. По идее здесь можно найти недостающих членов команды, получить советы экспертов, заключить менторское соглашение и найти посевного инвестора. Вчера были выступления представителей идей/проектов, сегодня - приехали "эксперты": сначала выступали в elevator pitch, потом общение с представителями проектов в формате speeddating, потом консультации по расписанию. Выглядит это все хаотично, организаторы пытаются каким-то образом способствовать созданию проектов, но все равно мотивации явно не хватает, чтобы по сути с незнакомыми людьми сделать хоть сколько-нибудь стоящий проект. Что из всего этого выйдет станет ясно завтра, возможно обновлю пост, если будет что сказать.

Заключение

В целом это очень здорово, что количество и качество подобных мероприятий в России лишь растет с каждым годом. Полезность конечно не всегда высока, но часто выносишь что-то новое и интересное для себя. Расстраивает разве что тот факт, что количество откровенно рекламных докладов очень велико, но для бесплатных мероприятий это вполне объяснимо и терпимо.

В планах посещения мероприятий в этом году остался разве что Google Developer Day, подтверждение участия еще не пришло, но надеюсь все же попасть и не забыть написать отчет.

Если Вы дочитали до конца, но не подписаны на RSS - сейчас самое подходящее время, чтобы это сделать :)

Hadoop для разработчика

Иван Блинков — Tue, 26 Feb 2008 00:15:00 +0300

Для разработки приложений, работающих с использованием Hadoop, или же алгоритмов для MapReduce framework'а совсем не нужен полномасштабный кластер. На самом же деле для запуска всей системы, описанной мной в одном из предыдущих постов, вполне достаточно одного компьютера и буквально минут 15 свободного времени, как потратить их для решения этой задачи я Вам и поведаю. Рассказывать я буду на примере своего Gentoo Linux, но большая часть этого повествования будет справедлива и для других unix-like операционных систем.

Подготовка

Перед тем, как приступить собственно говоря к установке Hadoop, необходимо выполнить два элементарных действия, необходимых для правильного функционирования системы:

открыть доступ одному из пользователей по ssh к этому же компьютеру без пароля, можно например создать отдельного пользователя для этого hadoop:
```
$$ useradd -m -n hadoop
```
Далее действия выполняем от его имени:
```
$$ su hadoop
```
Генерируем RSA-ключ для обеспечения аутентификации в условиях отсутствия возможности использовать пароль:
```
$$ hadoop@localhost ~ $ ssh-keygen -t rsa -P ""
Generating public/private rsa key pair.
Enter file in which to save the key (/home/hadoop/.ssh/id_rsa):
Your identification has been saved in /home/hadoop/.ssh/id_rsa.
Your public key has been saved in /home/hadoop/.ssh/id_rsa.pub.
The key fingerprint is:
7b:5c:cf:79:6b:93:d6:d6:8d:41:e3:a6:9d:04:f9:85 hadoop@localhost
```
И добавляем его в список авторизованных ключей:
```
$$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
```
Этого должно быть более чем достаточно, проверить работоспособность соединения можно просто написав:
```
$$ ssh localhost
```
Не забываем предварительно инициализировать sshd:
```
$$ /etc/init.d/sshd start
```
Помимо этого необходимо убедиться в наличии установленной JVM версии 1.5.0 или выше, а также узнать директорию, где она располагается, вариантов сделать это множество, я нашел ее просто заглянув в самое логичное место - /usr/lib, но при желании никто не может Вам помешать воспользоваться услугами, например, slocate. Найденную директорию с JVM лучше запомнить или записать куда-нибудь, для меня она оказалась: /usr/lib/jvm/sun-jdk-1.6

Установка

Установка начинается с получения копии исходного кода системы, способов для этого существует несколько. Я перепробовал практически все, самую адекватную версию мне удалось получить из SVN. Для ее получения необходимо выполнить следующую команду:

$ svn checkout http://svn.apache.org/repos/asf/hadoop/core/branches/branch-0.16 ~

branch-0.16 - последняя доступная версия на данный момент, для определения ее номера достаточно заглянуть по тому же адресу браузером. Предполагается, что Hadoop будет располагаться прямо в /home/hadoop, но запросто можно использовать и другую директорию.

Сразу же стоит скомпилировать различные дополнительные компоненты системы, особенно это актуально из-за HBase, но и помимо него соберется много чего интересного, например plug-in для отличной IDE под названием Eclipse или Hadoop On Demand. Задача также элементарна:

$ cd ~ && ant clean jar compile-contrib

Настройка

Конфигурационные файлы можно редактировать в произвольном порядке, самое главное ничего не забыть :)

conf/hadoop-env.sh

export JAVA_HOME=/usr/lib/jvm/sun-jdk-1.6

Единственная обязательная переменная окружения - JAVA_HOME, здесь как раз пригодится заранее найденный путь до JVM, все остальное - по желанию.

conf/hadoop-site.xml

<property>
  <name>hadoop.tmp.dir</name>
  <value>/home/hadoop/data/${user.name}</value>
  <description>A base for other temporary directories.</description>
</property>
<property>
  <name>fs.default.name</name>
  <value>hdfs://localhost:54310</value>
  <description>The name of the default file system.  A URI whose
  scheme and authority determine the FileSystem implementation.  The
  uri's scheme determines the config property (fs.SCHEME.impl) naming
  the FileSystem implementation class.  The uri's authority is used to
  determine the host, port, etc. for a filesystem.</description>
</property>
<property>
  <name>mapred.job.tracker</name>
  <value>localhost:54311</value>
  <description>The host and port that the MapReduce job tracker runs
  at.  If "local", then jobs are run in-process as a single map
  and reduce task.
  </description>
</property>
<property>
  <name>dfs.replication</name>
  <value>1</value>
  <description>Default block replication.
  The actual number of replications can be specified when the file is created.
  The default is used if replication is not specified in create time.
  </description>
</property>

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

src/contrib/hbase/conf/hbase-site.xml

<property>
  <name>hbase.master</name>
  <value>localhost:60000</value>
  <description>The host and port that the HBase master runs at</description>
</property>
<property>
  <name>hbase.rootdir</name>
  <value>/hbase</value>
  <description>location of HBase instance in dfs</description>
</property>

Как не сложно заметить, этот файл необходим для функционирования HBase, по-моему все просто и очевидно, <description> говорят сами за себя.

Запуск

Начать стоит с ознакомления с кратким описанием доступных команд Hadoop, сделать это можно просто набрав ~/bin/hadoop:

Usage: hadoop [--config confdir] COMMAND
where COMMAND is one of:
  namenode -format     format the DFS filesystem
  secondarynamenode    run the DFS secondary namenode
  namenode             run the DFS namenode
  datanode             run a DFS datanode
  dfsadmin             run a DFS admin client
  fsck                 run a DFS filesystem checking utility
  fs                   run a generic filesystem user client
  balancer             run a cluster balancing utility
  jobtracker           run the MapReduce job Tracker node
  pipes                run a Pipes job
  tasktracker          run a MapReduce task Tracker node
  job                  manipulate MapReduce jobs
  version              print the version
  jar             run a jar file
  distcp   copy file or directories recursively
  daemonlog            get/set the log level for each daemon
 or
  CLASSNAME            run the class named CLASSNAME
Most commands print help when invoked w/o parameters.

Первым делом необходимо отформатировать Namenode:

$ ~/bin/hadoop namenode -format

И дело останется лишь за малым, запустить на выполнение пару bash-скриптов, которые без вашего дальнейшего участия инициализируют всю систему, включая HBase:

$ ~/bin/hadoop/start-all.sh && ~/src/contrib/hbase/bin/start-hbase.sh

Как только они закончат все необходимые действия, у Вас появится возможность удостовериться, что все в порядке. Самым простым способом является запуск клиента Hbase Shell:

$ ~/bin/src/contrib/hbase/bin/hbase shell

Если в ответ Вы получили соответствующее приглашение клиента, значит все было сделано верно!

Вот собственно говоря и все, псевдо-кластер функционирует, доступ к HBase имеется, можно приступать к разработке :)

P.S.: Остановка системы производится по тому же принципу скриптами stop-all.sh и stop-hbase.sh.

Шаблонизация

Иван Блинков — Sat, 26 Jan 2008 15:25:00 +0300

Наверняка Вы часто замечали, что в пределах одного сайта все (или покрайней мере большинство) страниц имеют много общего: структуру, расположение элементов, дизайн и так далее. Основным различием обычно является лишь содержание. Естественно, что делается это не спроста: именно общие компоненты сайта создают в голове посетителей тот самый образ, который производит общее подсознательное впечатление о сайте, а также позволяет посетителям отличать сайт А от сайта Б.

Продолжая разговор, начатый еще в одной из предыдущих статей, рассмотрим организацию интерфейса между двумя другими составляющими практически любого интернет-проекта: скриптов (все так же на примере PHP) и страницами, отправляемыми посетителям посредством http-сервера.

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

Наверняка у Вас уже возникло два вполне логичных вопроса:

Как можно разделить таким образом контент?
Как потом восстановить страницу в исходном виде?

Вариантов ответа на каждый из них можно придумать множество: начиная с банальных вариаций на тему применения echo, заканчивая применением достаточно серьезных готовых решений вроде широкораспространенного Smarty или существенно более эффективного Blitz. Каждый из них имеет свои сильные и слабые стороны, но в целом любой из них можно оценить по двум критериям: производительности и удобстве организации кода.

Какие-либо цифры оценки производительности приводить не буду, так как, во-первых, в Сети можно найти много benchmark'ов, посвященных этой теме, а, во-вторых, просто-напросто вовсе не о цифрах я хотел с Вами поговорить. Как известно самым производительным по крайней мере с теоретической точки зрения является метод под названием php mess, заключается он в следующем: вся страница размещается в рамках одного файла, при этом статическая часть документа пишется просто "как есть" в соответствии с необходимым стандартом, а изменяемые части организуются размещенным в необходимых местах PHP-кодом, окруженным стандартной конструкцией <?php ?>. Но огромнейший недостаток очевиден - огромное количество информации расположенной в одном файле, при отсутствии какого-либо более четкого разделения PHP-кода и остального содержимого, чем указанная выше конструкция, приводит к постоянной путанице в коде, а также существенным затратам времени программиста при попытках исправить ту или иную часть документа.

На противоположной стороне нашей шкалы удобство-производительность я бы расположил уже упомянутое выше решение под названием Smarty. Представляет оно собой целую систему, реализованную также на PHP, и предоставляющую огромное количество возможностей по решению нашей задачи. Шаблоны хранятся в отдельных файлах, для определения мест расположения динамического контента используется специальный синтаксис, который прост как три копейки, так как разрабатывался с расчетом не на программистов, а по принципу "чем проще, тем лучше". Именно этот факт сделал Smarty одним из самых (если не самым) распространенных движков шаблонизации (или как их принято правильно называть "Template Engine"). Но, к сожалению, за удобство приходится платить, в этом случае производительностью: вся система сама по себе громоздка и состоит из множества файлов, между которыми все данные так или иначе передаются, а так как написано она на PHP (который является далеко не самым производительным языком программирования, в основном в силу своей интерпритируемости и некоторых других особенностей), конкуренции в плане производительности многим другим вариантам решения нашей задачи Smarty составить не в состоянии.

Одним из лучших "компромиссных" вариантов, которые доступны на данный момент, могу назвать также упомянутый выше Blitz. Реализован он в виде модуля PHP, написанного на языке C, что является залогом его отличной производительности. При этом общая его концепция близка к Smarty: шаблоны также хранятся в отдельных файлах и подчинены незамысловатому синтаксису (который вообще можно понять и запомнить буквально за 15-20 минут, прочитав статью, ссылку на которую я уже приводил выше), а в PHP-скриптах после установки становится доступен специальный класс для управления модулем. Но основное достоинство этого решения является одновременно и его основным недостатком - редкий хостинг имеет этот модуль в списке предустановленных (видимо в силу своей не очень обширной известности, обусловленной ), а доступ к http-серверу и PHP-интерпретатору, который необходим для установки PHP-модулей, предоставляется чаще всего только на дорогих тарифах виртуального хостинга или на различных вариантах VPS или арендуемых серверов.

Помимо этого некоторые энтузиасты берутся на написание "собственных" Template Engine, базирующихся на различных вариантов использования PHP-функций вроде preg_replace. Если честно такие попытки редко заканчиваются успехом: в лучшем случае удается добиться удобства использования самим разработчиком, но чаще всего в ущерб производительности. Заниматься подобными экспериментами я Вам не советую, вместо этого я предлагаю написать "обертку" к приглянувшемуся распространенному Template Engine, что позволит не только сделать его использование более удобным конкретно для Вас, но и позволит заменить его на другой с минимальными затратами сил и времени (например в случае, если модуль Blitz недоступен).

Разрабатываем "обертку"

Сразу скажу, что цели привести конкретный пример пригодного для реального использования кода я перед собой не ставлю в этой части моего повествования. Я лишь хочу показать направление, в котором можно провести разработку с целью облегчения собственной же жизни, т.е. предоставить Вам альтернативу простому использованию тех или иных решений в том виде, в котором они предоставлены разработчиками.

Если Ваш выбор всетаки пал на написание "оболочки", не смотря на принесение в жертву несущественной части производительности, то стоит для начала определиться: а что же мы будем "заворачивать"? В качестве примера я, пожалуй, буду использовать Blitz, как самый оптимальный вариант (по крайней мере с моей точки зрения). Начать стоит как обычно с пустой заготовки для класса.

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

В любом случае понадобится переменная для его хранения:

<?php
class TemplateEngine
{
  {
    array=array();
    //можно сразу указать указать путь к папке с шаблонами
    $this->engine=new Blitz('./template/'.$template.'.tpl');
  }
}
?>

А также метод, переопределяющий стандартный set на метод, добавляющий новые значения к нашему массиву (хотя можно и любое другое понравившееся название использовать):

<?php
function set($caption,$value)
{
  $this->array[$caption]=$value;
}
?>

После чего оригинальный set можно использовать уже непосредственно перед parse, с указанием уже собранного массива в качестве параметра. За компанию позволю произвести себе еще одну модификацию: в подавляющем большинстве случаев parse используется в совокупности с echo, чтобы не указывать каждый раз это слово - можно включить его прямо в наш класс:

<?php
function parse()
{
  if(count($this->array))$this->engine->set($this->array);
  echo $this->engine->parse();
}
?>

Еще одним возможным вариантом модификации может стать обработка всех (или какой-то части, если есть необходимость) динамических данных с помощью какой-либо функции, например это актуально для htmlspecialchars:

<?php
function set($caption,$value)
{
  $this->array[$caption]=$this->html($value);
}
function rawset($caption,$value)
{
  $this->array[$caption]=$value;
}
private function html($array)
{
  if(is_array($array))
  {
    foreach($array as $caption => $value)
    $value=$this->html($value);
    return $array;
  }
  else return htmlspecialchars($array,ENT_QUOTES);
}
?>

Как нетрудно заметить, в методе используется рекурсия, так как структура передаваемых параметром массивов неизвестна.

Надеюсь написанный выше текст подтолкнет Вас к действию или хотябы заставит задуматься над имеющимся выбором, если же Вы читали его лишь "для общего развития", то тем более хочется сказать Вам огромное Спасибо за то, что дочитали до конца это повествование.