В этом году я побывал на HighLoad++. Event довольно интересный, поэтому я попытаюсь вкратце описать свои впечатления, а так же основные тенденции наблюдаемые на конференции.

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

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

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

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

Основные понравившиеся доклады Link to heading

Performance tweaks and tools for Linux / Joe Damato Link to heading

В этом докладе рассказывается об основных инструментах профилирования под Linux — lsof, strace, ltrace, oprofile. Но об этом знают если не все, то почти все. Интересен этот доклад другим. Joe будучи Ruby хакером создал набор довольно интересных инструментов для профилирования Ruby приложений при помощи этих низкоуровневых инструментов.

Секреты Фейсбука: как выдержать 50 миллионов запросов в секунду / Robert Johnson Link to heading

Robert Johnson — ведущий инженер по разработке ПО в компании Facebook (а по совместительству, как и я, владелец Jackson’а). Роберт много говорил не только о технической стороне масштабирования, но и об организационных мерах и том, каких направлений должен придерживаться коллектив участвующий в разработке высоконагруженного приложения. Основные посылы следующие:

  1. большому проекту рано или поздно прийдется столкнутся с горизонтальным масштабированием;
  2. все изменения должны быть инкрементальными (нет изменений, которые не могут быть отменены);
  3. если вы не можете что-то измерить, вы не можете этим управлять;
  4. работа в небольших независимых коллективах (от 3 до 7 человек) над разными проектами (фотографии, личные сообщения и т.д.);
  5. люди ответственные за что-либо должны иметь контроль над этим.

В личном общении с Робертом я смог узнать следующие вещи:

  • социальные графы очень тяжело partition’ить. Я спросил не пытались ли они заимствовать опыт MMORPG проектов? По идее у них схожие задачи, но гораздо более жесткие требования к latency. Роберт сказал, что это интересная идея, но ничего подобного они не пробовали делать. Так же он не особо верит в том что алгоритмы кластеризации графов смогут помочь им решить эту проблему в общем виде и достичь при этом вменяемой производительности;
  • их custom’ный протокол репликации в mysql, обошелся им в десяток строк кода, что и обусловило использование такого, на мой взгляд, странного решения;
  • в довольно большом проекте в угоду производительности коллектива в целом приходится принимать такие решения, как писать HipHop. Насколько я понял, Роберт не особо верит в его широкий adoption за пределами Facebook. Это довольно специфические решение проблемы в их специфическом окружении.

Быстрое развертывание шаблонов и статики в Mail.ru / Николай Кондратов Link to heading

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

В mail.ru особенности процесса следующие:

  • шаблоны пишутся на псевдоязыке и позже могут быть транслированы в C/Perl; шаблоны и статика доставляются на production отдельно от кода приложения, тем самым код и шаблоны могут меняться независимо. Схема выглядит довольно хрупко. На мой вопрос: “как вы избегаете несовместимых изменений между кодом и шаблонами?”, они ответили: “мы внимательно следим за этим”;
  • у каждого разработчика есть свой сетевой диск (который монтируется при помощи FUSE). Этот диск связан с отдельным для разработчика доменом, на котором крутится приложение;
  • артефакт с шаблонами и статикой доставляется на production машину, с которой посредством p2p сети (torrent) распространяется по frontend’ам. Исходная машина работает в режиме суперсидирования (то есть каждый блок отдается только единожды). Ребята объяснили такое решение тем, что в противном случае у них заканчивается network bandwidth на исходной машине (размер артефакта порядка 100Mb).

Progressive downloads and Rendering / Stoyan Stefanov (Yahoo) Link to heading

Yahoo, как известно “помешана” на оптимизации на клиентской стороне. Этот доклад всецело посвящен такого рода оптимизациям. Много говорилось про user perception и то как люди оценивают производительность. О том что стабильность производительности (среднеквадратичное отклонение) важнее, чем абсолютные значения latency. Про аттрибуты async и deffered, которые предоставляет HTML5. Про то что такое chunked response и как его использует Google и Amazon. Как CSS может значительно снизить производительность вашего web-приложения. Доклад довольно довольно последовательный, так что очень советую посмотреть слайды а также видео.

Я из этого доклада я вынес следующее: performance is a feature (этот тезис всплывал на конференции не раз). Если вы хотите чтобы ваше приложение быстро рендерилось на стороне клиента (что очень важно еще и в связи с ростом процента мобильных клиентов), то к этому вопросу над подходить как к фиче. Несмотря на расхожее мнение, добавить такого рода оптимизации в уже существующее приложение написанное без оглядки на вопросы client side performance, может быть довольно непросто.

Thinking Clearly About Performance / Carry Millsap Link to heading

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

Основные постулаты:

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

Я очень советую прочитать одноименную публикацию, чтобы получить более полное представление об этом материале.

Закулисы Link to heading

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

  • Sphinx очень популярен. Этим фактом, впрочем, никого не удивишь, но тем не менее полезно было получить тому подтверждение от людей реально его использующих;
  • Redis тоже довольно популярное решение, что для меня стало новостью. Я встретил по меньшей мере пятерых человек из разных компаний, которые используют это хранилище;
  • стандартная библиотека Scala изобилует довольно “детскими” багами как функциональными, так performance-related. Если вы хотите использовать Scala в крупном проекте, есть смысл подумать об использовании стандартной библиотеки Java, как бы грустно это ни звучало;
  • системы асинхронного обмена сообщениями тоже получили довольно широкий adoption. Очень много кто использует те или иные реализации очередей (в основном memcacheQ и Redis);
  • и несмотря на это, практически никто не знаком с EIP, основополагающим трудом в этой области; вопреки расхожему мнению, вопрос найма специалистов стоит остро в любой точке нашей страны (а возможно и планеты). Владивосток, будучи относительно небольшим городом, в этом отношении не особо хуже Москвы.

Ложка дёгтя Link to heading

Впрочем, не все так безоблачно. До сих пор, я намеренно игнорировал негативные моменты связанные с конференцией:

  • некоторые доклады были попросту скучные, а некоторые я считаю вредные. Абсолютизм пропагандируемый в докладе “Практическое создание крупного масштабируемого web 2.0 проекта с нуля” это на мой взгляд один из худших феноменов, который может настигнуть специалиста. Масштабируемость в этом докладе провозглашается чуть ли не самодостаточным свойством системы ради которого и “крутится Земля”. Попытки аудитории обратить внимание докладчика на то что иногда существуют определенные требования к гарантии в отношении consistency (которые влияют на принимаемые решения и выбор инструментов) не увенчались успехом;
  • некоторые участники в личном общении беззастенчиво утоляли собственные комплексы. Один участник в течении 10 минут пытался мне объяснить что настраивать GC в Java очень просто. Объяснения сводились примерно к следующему. В Java есть один стоящий GC — Parallel GC, все остальное — ошибка природы. Серьезно к такому мнению относится не получается (на самом деле, это еще один частный случай абсолютизма описанного в предыдущем пункте);
  • в рамках конференции был круглый стол об использовании SMP систем. Intel прислала на это событие не технического специалиста, а, если я не ошибаюсь, менеджера по связям с общественностью. Стоит ли говорить, что это не тот кого мы ждали;
  • вообще, в конце докладов оставалось очень мало времени на вопросы. Иногда доходило до смешного, в конце доклада организаторы говорили: “у нас есть время на два вопроса”. Два вопроса?! Вы издеваетесь?! По факту, обсуждение докладов осуществлялось за кулисами в компании 5-10 особо заинтересованных участников и самого автора.

В сухом остатке Link to heading

Участие в конференции составило 15 000 рублей. Для иногородних еще стоимость билетов и проживания в городе. Поэтому я бы дал следующий совет тем, кто собирается поехать на HighLoad++ в будущем. И пожалуй я это выделю в отдельный абзац.

Основной источник информации на такого рода event’ах — это личное общение.

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

Вот наверное и все. Если у вас есть еще какие-либо вопросы, с удовольствием отвечу на них.