Cоциальный граф "Одноклассников" в myTargetOleg Tsarev
Задача выглядит обманчиво простой — рядом с баннером игры из Одноклассников показывать текстовый тизер «эту игру играет Кот Матроскин и ещё 5 твоих друзей» (имя и количество берутся из друзей пользователя на Одноклассниках).
Как обрабатывать граф друзей проекта Одноклассники для этой задачи?
На этот простой вопрос дают разные ответы:
- взять графовую базу данных
- использовать матрицу инцидентности
- использовать список смежных вершин.
Если уточнить, что сырые данные занимают полтора терабайта, в графе 200 миллионов вершин и 13 миллиардов связей, то ручные решения сразу отметаются.
«Графовая база данных!» Стоит озвучить нагрузку в десятки тысяч запросов секунду и требования отвечать за миллисекунды (тысячные доли секунды!) как графовые базы сразу оказываются за бортом — типичное время ответа на простые запросы — единицы секунд.
Экс-разработчик MySQL и SciDB, ныне ведущий разработчик myTarget Олег Царёв расскажет, как решалась эта непростая задача в рамках проекта.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Грабли при ма...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. «Грабли при масштабировании веб-приложения, на которые очень легко наступить», Евгений Коковихин (системный архитектор WapStart)
Аннотация
Что происходит при росте приложения с 1М до 50М хитов в сутки. С какими проблемами можно столкнуться, когда серверов становится больше одного. О чем важно помнить при проектировании приложения, способного масштабироваться.
Подробно
Когда мы сделали первую публичную версию plus1.wapstart.ru, она помещалась на один сервер и была соответствующим образом спроектирована. Потом нагрузка начала расти, а мы начинали наступать на грабли. В докладе будет рассказано о наиболее типичных "граблях", что возможно позволит избежать их другими разработчиками при проектировании приложения.
О чем пойдет речь (кратко):
* балансировка нагрузки;
* кеширование данных и прогрев кешей;
* работа с сетью;
* сессии;
* файлы, загружаемые пользователями;
* работа с СУБД.
Мы пишем на PHP, используем фреймворк OnPHP, СУБД Postgres.
Биография
Родился в несуществующем городе несуществующей страны. Первый мобильный телефон увидел в 1997 году. С детства любил программировать, последние 4 года посвятил развитию рекламы в мобильном веб. Своими глазами видел эволюцию мобильных устройств и предпочтений рекламодателей.
ChatOps на практике. Организация работы команды сопровождения / Евгений Потап...Ontico
1. Взаимодействие с командой сопровождения через чаты — преимущества и проблемы.
1.1. ChatOps — о чем это?
1.2. Преимущества взаимодействия и постановки задач через чаты.
1.3. Проблемы хаотичности взаимодействия.
2. Интеграция процессов технической поддержки в ChatOps.
2.1. Постановка задач.
2.2. Мониторинг.
2.3. Оперативное реагирование.
3. Наш опыт доработки Telegram для интеграции с системами постановки задач, мониторингом и мониторингом самого взаимодействия.
Банки.ру — проект с 10-летней историей. В разные времена мы испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас в среднем в день у нас примерно 2КК просмотра страниц, т.е. мы уже не маленькие, но ещё и не совсем большие.
Я хочу поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.
Посмотрим примеры и поищем ответы на вопросы:
1) Настолько ли ваш highload — highload?
2) Считать ли хабрэффект поводом для внедрения высоких технологий?
3) "Костыль" или "высокотехнологичное решение" — что выбрать? Плюсы и минусы.
4) Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки "по-взрослому".
5) Как можно использовать "список Бунина" для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
6) Как работать с тех. долгом, чтобы он не зарастал мхом?
В заключение я расскажу про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.
P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)
Миф об очень сложном Highload / Александр Горный (Mail.Ru Group)Ontico
Highload, высокие нагрузки — популярный и дорогой buzzword, ради него проводятся огромные конференции, разработчики указывают его в резюме, претендуя на большие деньги, а работодатели в вакансиях, обещая более интересную работу.
В докладе я показываю, что современная производительность серверов позволяет не думать о нагрузке для 95% "highload" проектов, знания из конференций не нужны в реальной жизни. Для разработки почти любого, даже очень крупного сайта достаточно PHP+MySQL, здравого смысла и совсем-совсем базовых правил, не обсуждающихся даже на Highload Junior.
План выступления.
1. Ликбез о производительности. RPS, latency — что это значит, как считается, к каким числам надо стремиться? Из чего складывается время отклика? База данных, фронтенд, верстка или мобильное приложение.
2. Замеры достижимой производительности теплого LAMP-ового сервера. Бенчмарк без индексов в базе.
Бенчмарк с индексами в базе. Сравнение с требуемыми цифрами.
3. Перечисление возможных детских ошибок, которые могут испортить эти результаты в жизни. Все эти ошибки объясняются не в академии Highload или институте Highload Junior, а в школе.
Примеры ошибок:
- выгрузка всей базы, а не нужных 20 элементов;
- паразитный вызов тяжелой страницы;
- плохой хостинг;
- чужие тормозные элементы;
- неадекватный объём html/js-кода.
4. Отсутствие детских ошибок позволяет эффективно программировать 90% крупных сайтов, 3-4 приема превратят 90% в 95%.
- nginx;
- репликация;
- кэширование и предрасчет.
Этому, кстати, тоже почти не учат на highload junior, но этому я вас уже научил.
5. Примеры продуктов, в которых на самом деле нужен highload?
- Очень-очень-очень много хитов, дешевле highload, чем новое железо.
- Очень много очен�
Cоциальный граф "Одноклассников" в myTargetOleg Tsarev
Задача выглядит обманчиво простой — рядом с баннером игры из Одноклассников показывать текстовый тизер «эту игру играет Кот Матроскин и ещё 5 твоих друзей» (имя и количество берутся из друзей пользователя на Одноклассниках).
Как обрабатывать граф друзей проекта Одноклассники для этой задачи?
На этот простой вопрос дают разные ответы:
- взять графовую базу данных
- использовать матрицу инцидентности
- использовать список смежных вершин.
Если уточнить, что сырые данные занимают полтора терабайта, в графе 200 миллионов вершин и 13 миллиардов связей, то ручные решения сразу отметаются.
«Графовая база данных!» Стоит озвучить нагрузку в десятки тысяч запросов секунду и требования отвечать за миллисекунды (тысячные доли секунды!) как графовые базы сразу оказываются за бортом — типичное время ответа на простые запросы — единицы секунд.
Экс-разработчик MySQL и SciDB, ныне ведущий разработчик myTarget Олег Царёв расскажет, как решалась эта непростая задача в рамках проекта.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Грабли при ма...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. «Грабли при масштабировании веб-приложения, на которые очень легко наступить», Евгений Коковихин (системный архитектор WapStart)
Аннотация
Что происходит при росте приложения с 1М до 50М хитов в сутки. С какими проблемами можно столкнуться, когда серверов становится больше одного. О чем важно помнить при проектировании приложения, способного масштабироваться.
Подробно
Когда мы сделали первую публичную версию plus1.wapstart.ru, она помещалась на один сервер и была соответствующим образом спроектирована. Потом нагрузка начала расти, а мы начинали наступать на грабли. В докладе будет рассказано о наиболее типичных "граблях", что возможно позволит избежать их другими разработчиками при проектировании приложения.
О чем пойдет речь (кратко):
* балансировка нагрузки;
* кеширование данных и прогрев кешей;
* работа с сетью;
* сессии;
* файлы, загружаемые пользователями;
* работа с СУБД.
Мы пишем на PHP, используем фреймворк OnPHP, СУБД Postgres.
Биография
Родился в несуществующем городе несуществующей страны. Первый мобильный телефон увидел в 1997 году. С детства любил программировать, последние 4 года посвятил развитию рекламы в мобильном веб. Своими глазами видел эволюцию мобильных устройств и предпочтений рекламодателей.
ChatOps на практике. Организация работы команды сопровождения / Евгений Потап...Ontico
1. Взаимодействие с командой сопровождения через чаты — преимущества и проблемы.
1.1. ChatOps — о чем это?
1.2. Преимущества взаимодействия и постановки задач через чаты.
1.3. Проблемы хаотичности взаимодействия.
2. Интеграция процессов технической поддержки в ChatOps.
2.1. Постановка задач.
2.2. Мониторинг.
2.3. Оперативное реагирование.
3. Наш опыт доработки Telegram для интеграции с системами постановки задач, мониторингом и мониторингом самого взаимодействия.
Банки.ру — проект с 10-летней историей. В разные времена мы испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас в среднем в день у нас примерно 2КК просмотра страниц, т.е. мы уже не маленькие, но ещё и не совсем большие.
Я хочу поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.
Посмотрим примеры и поищем ответы на вопросы:
1) Настолько ли ваш highload — highload?
2) Считать ли хабрэффект поводом для внедрения высоких технологий?
3) "Костыль" или "высокотехнологичное решение" — что выбрать? Плюсы и минусы.
4) Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки "по-взрослому".
5) Как можно использовать "список Бунина" для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
6) Как работать с тех. долгом, чтобы он не зарастал мхом?
В заключение я расскажу про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.
P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)
Миф об очень сложном Highload / Александр Горный (Mail.Ru Group)Ontico
Highload, высокие нагрузки — популярный и дорогой buzzword, ради него проводятся огромные конференции, разработчики указывают его в резюме, претендуя на большие деньги, а работодатели в вакансиях, обещая более интересную работу.
В докладе я показываю, что современная производительность серверов позволяет не думать о нагрузке для 95% "highload" проектов, знания из конференций не нужны в реальной жизни. Для разработки почти любого, даже очень крупного сайта достаточно PHP+MySQL, здравого смысла и совсем-совсем базовых правил, не обсуждающихся даже на Highload Junior.
План выступления.
1. Ликбез о производительности. RPS, latency — что это значит, как считается, к каким числам надо стремиться? Из чего складывается время отклика? База данных, фронтенд, верстка или мобильное приложение.
2. Замеры достижимой производительности теплого LAMP-ового сервера. Бенчмарк без индексов в базе.
Бенчмарк с индексами в базе. Сравнение с требуемыми цифрами.
3. Перечисление возможных детских ошибок, которые могут испортить эти результаты в жизни. Все эти ошибки объясняются не в академии Highload или институте Highload Junior, а в школе.
Примеры ошибок:
- выгрузка всей базы, а не нужных 20 элементов;
- паразитный вызов тяжелой страницы;
- плохой хостинг;
- чужие тормозные элементы;
- неадекватный объём html/js-кода.
4. Отсутствие детских ошибок позволяет эффективно программировать 90% крупных сайтов, 3-4 приема превратят 90% в 95%.
- nginx;
- репликация;
- кэширование и предрасчет.
Этому, кстати, тоже почти не учат на highload junior, но этому я вас уже научил.
5. Примеры продуктов, в которых на самом деле нужен highload?
- Очень-очень-очень много хитов, дешевле highload, чем новое железо.
- Очень много очен�
13 октября, DEV {web} - конференция о Highload веб-разработке. "Архитектура п...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Архитектура проекта на 30 млн. пользователей", Дмитрий Смирнов (ведущий разработчик Фотостраны).
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
13 октября, DEV {web} - конференция о Highload веб-разработке. "Java под нагр...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Java под нагрузкой, в поисках проблем...", Филипп Дельгядо (CTO Goodwix, ex-teamlead Яндекс.Деньги)
Аннотация
Не так давно с некоторым изумлением узнал, что Java для нагруженных систем представляется совершенной terra incognita. Хотя и совершенно не хочется бороться с мифами, по крайней мере, с удовольствием расскажу, как просто и без хлопот использовать Java в вебе. Про "суровый" highload рассказывать не буду, а вот про простые решения - с удовольствием. Ну и на закуску расскажу, за что я нежно люблю блобы.
О себе
Teamlead сколько себя помню, успел поработать и в "Яндекс.Деньгах" и в "БК Марафон". Люблю простые решения, сложные задачи и хорошую коммуникацию.
20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения ...IT-Portfolio
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков (ведущий разработчик Cezurity)
Аннотация
Когда команда разработчиков собирается написать новый сервис, у нее, как правило, отсутствует свободное время, но есть необходимый энтузиазм. Из-за нехватки времени многие архитектурные решения приходится принимать, руководствуясь общими соображениями, так как провести всесторонние тесты имеющихся на рынке средств в краткие сроки невозможно. Мы, специалисты компании Cezurity, начали свой проект не вчера, и уже накопили некоторый опыт использования технологий, появившихся сравнительно недавно - таких как Skytools, Node.JS, RabbitMQ и Redis. О том, какие возникли проблемы при внедрении этих средств, и какие их ограничения пришлось преодолевать и учитывать - мой доклад. Кроме того, я расскажу о новом направлении в нашей деятельности - внедрении HBase для хранения большого объема данных.
Биография
Докладчик - узкий специалист широкого профиля, относит себя к виду, называемому в современной англоязычной литературе термином "DevOps". Любит принимать участие в создании сложных систем и постоянно это делает. Никогда не работал в Яндексе, компенсировав это работой в Mail.Ru и некоторых других местах.
Картинки к моему рассказу о том, как мы делаем Банки.ру. Некоторые слайды очень неоднозначны без текста. Тезисы тут: http://nastachku.ru/lectures?lecture_id=630#lecture_630
Видео тут https://www.youtube.com/watch?v=m5QuiTZwMrU
Распространенные ошибки применения баз данныхSergey Xek
Распространенные ошибки применения баз данных. Сергей Аверин, Badoo.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются раз- работчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, ко- торые потом в реальной жизни никогда не понадобится.
• Или проектируется архитектура, которая якобы дает отказоустойчи- вость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологиче- ская» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки собы- тий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и неболь- ших команд, техническим руководителям.
LuaJIT как основа для сервера приложений - проблемы и решения / Игорь Эрлих (...Ontico
С того момента, как было принято решение использовать язык Lua в качестве языка описания бизнес-логики в нашей платформе, прошло уже больше восьми лет. Проекты росли, данных становилось больше, возрастала нагрузка на сервера приложений. Со временем у нас накопился солидный багаж знаний о том, как устроен LuaJIT, с какими проблемами можно столкнуться при его использовании и как эти проблемы можно решать.
Я расскажу про то...
* Почему при миграции с x86 на x64 доступной памяти в LuaJIT становится меньше, и как мы с этим боролись.
* Как загрузить в LuaJIT несколько миллионов объектов и не умереть в тормозах от сборщика мусора.
* Насколько ужасна встроенная функция хеширования строк и почему иногда надо жертвовать производительностью в пользу качества.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Архитектура п...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Архитектура проекта на 30 млн. пользователей", Дмитрий Смирнов (ведущий разработчик Фотостраны).
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
13 октября, DEV {web} - конференция о Highload веб-разработке. "Java под нагр...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Java под нагрузкой, в поисках проблем...", Филипп Дельгядо (CTO Goodwix, ex-teamlead Яндекс.Деньги)
Аннотация
Не так давно с некоторым изумлением узнал, что Java для нагруженных систем представляется совершенной terra incognita. Хотя и совершенно не хочется бороться с мифами, по крайней мере, с удовольствием расскажу, как просто и без хлопот использовать Java в вебе. Про "суровый" highload рассказывать не буду, а вот про простые решения - с удовольствием. Ну и на закуску расскажу, за что я нежно люблю блобы.
О себе
Teamlead сколько себя помню, успел поработать и в "Яндекс.Деньгах" и в "БК Марафон". Люблю простые решения, сложные задачи и хорошую коммуникацию.
20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения ...IT-Portfolio
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков (ведущий разработчик Cezurity)
Аннотация
Когда команда разработчиков собирается написать новый сервис, у нее, как правило, отсутствует свободное время, но есть необходимый энтузиазм. Из-за нехватки времени многие архитектурные решения приходится принимать, руководствуясь общими соображениями, так как провести всесторонние тесты имеющихся на рынке средств в краткие сроки невозможно. Мы, специалисты компании Cezurity, начали свой проект не вчера, и уже накопили некоторый опыт использования технологий, появившихся сравнительно недавно - таких как Skytools, Node.JS, RabbitMQ и Redis. О том, какие возникли проблемы при внедрении этих средств, и какие их ограничения пришлось преодолевать и учитывать - мой доклад. Кроме того, я расскажу о новом направлении в нашей деятельности - внедрении HBase для хранения большого объема данных.
Биография
Докладчик - узкий специалист широкого профиля, относит себя к виду, называемому в современной англоязычной литературе термином "DevOps". Любит принимать участие в создании сложных систем и постоянно это делает. Никогда не работал в Яндексе, компенсировав это работой в Mail.Ru и некоторых других местах.
Картинки к моему рассказу о том, как мы делаем Банки.ру. Некоторые слайды очень неоднозначны без текста. Тезисы тут: http://nastachku.ru/lectures?lecture_id=630#lecture_630
Видео тут https://www.youtube.com/watch?v=m5QuiTZwMrU
Распространенные ошибки применения баз данныхSergey Xek
Распространенные ошибки применения баз данных. Сергей Аверин, Badoo.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются раз- работчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, ко- торые потом в реальной жизни никогда не понадобится.
• Или проектируется архитектура, которая якобы дает отказоустойчи- вость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологиче- ская» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки собы- тий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и неболь- ших команд, техническим руководителям.
LuaJIT как основа для сервера приложений - проблемы и решения / Игорь Эрлих (...Ontico
С того момента, как было принято решение использовать язык Lua в качестве языка описания бизнес-логики в нашей платформе, прошло уже больше восьми лет. Проекты росли, данных становилось больше, возрастала нагрузка на сервера приложений. Со временем у нас накопился солидный багаж знаний о том, как устроен LuaJIT, с какими проблемами можно столкнуться при его использовании и как эти проблемы можно решать.
Я расскажу про то...
* Почему при миграции с x86 на x64 доступной памяти в LuaJIT становится меньше, и как мы с этим боролись.
* Как загрузить в LuaJIT несколько миллионов объектов и не умереть в тормозах от сборщика мусора.
* Насколько ужасна встроенная функция хеширования строк и почему иногда надо жертвовать производительностью в пользу качества.
Александр Курдюков. Внедрение continuous delivery для гетерогенных поставок.ScrumTrek
Современный бизнес хочет как можно более быстрых поставок. Но в сложной системе полный цикл проверки и установки может занимать значительное время и требовать ручного труда. Проблем становится больше, если система гетерогенна, т.е. используется как привычный Linux, так и Windows. Мы прошли некоторый путь от полностью ручных выкаток и проверок сред к автоматизации, которая минимизирует время поставки пользователям. При этом удалось сохранить единство подхода как для Linux, так и для Windows выкаток. Доклад о том, что мы пробовали, что получилось, а что не очень. И куда можно развить полученный успех.
Павел Прищепа. Бббыстрый бэкенд на базе ДрупалDrupalSib
Выступления на DrupalCafe#7@Omsk от сибирского сообщества друпаллеров НП "ДрупалСиб".
В случае использования традиционных подходов, скорость работы друпала в качестве бэкенда для single-page application или в качестве мобильного бэкенда - не выдерживает никакой критики.
Конечно, всегда можно написать быстрый бэкенд на Node.js, Pytnon, использовать NoSQL базы данных. И все это будет работать достаточно шустро.
Но это решает только часть проблем и порождает массу других:
*найм новых специалистов, изучение новых языков программирования и фреймворков;
*разнесение/дублирование бизнес-логики;
*необходимость с нуля реализовывать многие вещи, которые давно есть в друпале;
*...
Для бизнеса это существенно повышает риски и стоимость проекта. Проект становится неуправляемым.
Я расскажу:
-как решить задачу создания быстрого бэкенда привычными средствами;
-какие архитектурные решения надо использовать, чтобы иметь возможность масштабировать проект по мере его роста;
-про паттерны построения высоконагруженных систем применимые к друпалу.
-----
Сайт сибирского сообщества друпаллеров ДрупалСиб drupalsib.ru
Группа сибирского сообщества друпаллеров Вконтакте vk.com/drupalsib
Партнер Группа компаний И20 i20.biz
1. Впадая в крайности
Решаем проблемы с Ruby on Rails
http://www.slideshare.net/sergeymoiseev/going-to-extreme
Monday, February 25, 13
2. О докладчике
• http://www.linkedin.com/in/moiseevsergey
• https://github.com/bopm
• http://www.slideshare.net/sergeymoiseev
• @SergeyMoiseev
Monday, February 25, 13
3. В прошлых сериях
• https://vimeo.com/51198953
• http://www.slideshare.net/sergeymoiseev/
migrate-4843818
Monday, February 25, 13
4. Тема доклада
• Боль, давление, рельсы.
• Временной интервал 2011 год.
• Один из трех крупнейших купонных
сервисов в РФ.
Monday, February 25, 13
5. Начинаем
• У нас тут есть Drupal, что бы ты мог нам
предложить.
• Его пилят свои люди, но мы не можем
себе позволить больше ждать.
• Пилят уже почти год.
• Админа у нас нет, но тут вроде был ДДоС.
Monday, February 25, 13
7. План действий
• Пишем новую версию на RoR.
• Мигрируем и начинаем развивать
функционал.
• Изначальная команда для разработки
нового проекта - три человека.
• Одного привел, второго забрал из под
увольнения.
Monday, February 25, 13
8. Пишем ТЗ
• Пишем ТЗ на базе текущей системы.
• Всё на месте? Вроде да.
• Окей, будем строить на базе гипотезы, что
заказчик читал ТЗ внимательно.
• Вместе с воспроизведением
функциональности будем делать редизайн.
Monday, February 25, 13
9. Первая итерация:
прототип
• Сделки, пользователи, покупки, регистрация.
• Дизайн.
• В процессе его разработки увольняется
делавший его дизайнер.
• Придумываем сами.
• Раз нет дизайна, то нет и формально
поставленной задачи.
Monday, February 25, 13
10. Postgresql
• Нет извечного конфликта какой storage
engine выбрать.
• Лучше тюнится.
• Я умею его готовить.
Monday, February 25, 13
11. Devise
• Гибкое решение по аунтефикации для
Rails.
• Очень эффективно для быстрого начала
разработки.
• Крайне гибкое и расширяемое.
• Из минусов: написано хакерами. Излучает
магию.
devise_for :users, :controllers => {:omniauth_callbacks =>
'users/omniauth_callbacks'}
Monday, February 25, 13
12. OmniAuth
• Поддержка множества провайдеров
аунтефикации.
• Поддерживает из коробки twitter,
facebook, гугл и множество других OAuth
провайдеров.
• Полный список: https://github.com/intridea/
omniauth/wiki/List-of-Strategies
Monday, February 25, 13
13. Globalize3
• Поддержка i18n на уровне базы.
• Перевод атрибутов моделей во вспомогательных
таблицах.
• Большой минус тесное связывание миграции и моделей.
Создаем: Используем:
class CreatePosts < ActiveRecord::Migration class Post < ActiveRecord::Base
def up translates :title, :text
create_table :posts do |t| end
t.timestamps
end
Post.create_translation_table! :title
=> :string, :text => :text
end Получаем:
def down I18n.locale = :en
drop_table :posts post.title # => Globalize3 rocks!
Post.drop_translation_table!
end I18n.locale = :he
end post.title # => !גלובאלייז2 שולט
Monday, February 25, 13
14. Seed-fu
• Заполнение справочников в БД.
• Позволяет вам писать сиды, которые
могут быть отредактированы, дополнены
и перезапущены путем ручного выбора
присваеваемых в базе ID.
Locale.delete_all
Locale.seed(:id,
{:id => 1, :code => 'ru' },
{:id => 2, :code => 'en' },
{:id => 3, :code => 'lv' },
{:id => 4, :code => 'lt' },
{:id => 5, :code => 'ee' },
)
Monday, February 25, 13
15. Смена курса
• Заказчик меняет ген. дира.
• Бывшего представителем заказчика на
проекте.
• На месте одного заказчика - четверо.
Monday, February 25, 13
16. Старая версия
• Нет VCS.
• Правят прямо на сервере.
• Наощупь.
• Свои люди доступны в офисе не в полном
объеме, живут в одной из среднеазиатских
республик.
• И да, они подчины только заказчику.
Monday, February 25, 13
17. Технологии старой
версии
• Один виртуальный сервер.
• Который админят индусы.
• MySQL из коробки.
• MyISAM.
Monday, February 25, 13
18. Самое интересное
• Заказчики не ведут формальную постановку задач
при работе со старой командой.
• Как потом окажется игнорируют постановку
задач вообще.
• Старая команда в свою очередь игнорирует
часть задач в принципе.
• Каждый день в референсной системе появляется
что-то новое.
• О чем нам забыли сказать.
Monday, February 25, 13
19. Ищем выход
• С тонущей подводной лодки.
• Плюсы: у нас рельсы и написаный
прототип.
• Минусы: нам нужно переломить кучу
бизнес-процессов притом быстро.
• Выбираем жертву: региональное зеркало.
• Спасительное но: данные независимы.
Monday, February 25, 13
20. Одновременно с этим
• Спасаем вселенную в лице старого проекта каждый
день (смотри доклад DevOps).
• Трафик на проекте постоянно растет.
• Боремся с ростом штата конторы с 20 до 150 человек.
• Внедряем VoIP.
• Перевозим офис на новое место за одну ночь (среды).
• Покупаем хостинг у RackSpace.
• Пишем новый массовый рассыльщик.
Monday, February 25, 13
22. Миграция данных
• Главный источник проблем.
• Особенно когда база меняется без учета
изменений.
• К примеру с помощью миграций в рельсах.
• В старой базе много данных относящихся к
коду которого уже нет в системе.
• А то никогда и не было.
Monday, February 25, 13
23. Мигрируем
региональное зеркало
• Начинаем в 20:00, заканчиваем к 02:30.
• Главная беда - долгая миграция данных.
• Даем себе обещание переносить максимум
данных заранее.
• На следующее утро узнаем, что заказчик не
предупредил региональных менеджеров.
• Все оставшееся время до конца года ругаемся
с ними в почте про “верните все обратно”.
Monday, February 25, 13
24. Проводим очередную
демонстрацию заказчику
• В таком дизайне это внедрять нельзя.
• Не важно, что мы это видели и согласилсь
запускать в регионы.
• Будем делать новый дизайн.
• С кнопками как у Apple.
Monday, February 25, 13
25. Нам нужны люди
побольше
• Заказчик настаивает на наращивании штата.
• Организует собеседования через HR.
• Плюс четыре человека в штат
программистов.
• Все требуют время на себя.
• Если вы не успеваете что-то, нужен PM в
штат.
Monday, February 25, 13
26. Миграция данных 2
• Выделяем постоянного специалиста.
• Теперь уже на основном объеме данных.
• Все прошлые проблемы плюс:
• больший объем данных;
• больше спрятанного под ковер.
Monday, February 25, 13
27. Resque
• Решение по созданию фоновых очередей.
• Поддерживает множественные очереди
на базе Redis.
Worker: Запуск:
class Archive class Repository
@queue = :file_serve def async_create_archive(branch)
Resque.enqueue(Archive, self.id, branch)
def self.perform(repo_id, branch = 'master') end
repo = Repository.find(repo_id) end
repo.create_archive(branch)
end
end
Monday, February 25, 13
28. Миграция данных 3
• Пишем логику переноса в worker’ах.
• При логике одна задача - один
пользователь выполнение слабо
параллелится.
Monday, February 25, 13
29. Nginx
• Один из лучших веб-серверов. Четко
ложится в наши планы по развертыванию.
• Кеширует статику на фронтовых серверах.
• Балансирует запросы на бековые
unicorn’ы.
• Миграция между площадками: апдейтим
dns, указав в nginx proxy_pass на новое
место.
Monday, February 25, 13
31. Unicorn
• Hot restart.
• Долгие споры с DevOps на тему unix
socket (~5-10% прироста
производительности) и числа процессов
на ядро.
Monday, February 25, 13
32. Кнопки как у apple
• Дизайн будет делать наш человек.
• Ему и нам не интересно, что программисты
думают о том, что дизайн не совместим с
функционалом.
• В переписке начинает вестись практика ответа
всем кроме меня.
• Приходится по каждому случаю показывать,
что это не работает потому как функционал
блокируется дизайном.
Monday, February 25, 13
34. Кнопки как у Apple 2
• Свой человек уходит.
• Как и в прошлый раз продолжаем делать
своими силами.
• Но это сильно что-то напоминает.
Monday, February 25, 13
35. Коммунистический
субботник
• Выгоднее всего работать по ночам.
• По вечерам есть время чтобы успевать делать
все накопившееся и еще чуть-чуть.
• Несмотря на это придумываются “блокеры”
которые нужно сделать до запуска.
• Команда работает без выходных на
регулярной основе.
• Но не вся. Новички не понимают чем обязаны.
Monday, February 25, 13
36. Decision Point
• На дворе конец ноября.
• Если не запустить проект сейчас, то не
понятно когда его вообще запускать.
Monday, February 25, 13
37. Запуск
• Ночь с пятницы на понедельник.
• Нагрузка на запущенных ранее зеркалах и основном
сайте не сравнима.
• Виртуальная машина дает просадку производительности.
• Вынимаем из нее бекэнд.
• Это не помогает. Бекэнды не успевают отвечать и
наружу падают 504.
• Посещения падают к 4-5 утра и все кто выжил идут
спать.
Monday, February 25, 13
38. Запуск 2
• DevOps с бекграундом во всем вообще
очень полезный человек на проекте.
• Когда он не пишет вам в общекомандный
чат, что рубисты уроды и им мало руки
оторвать.
• В итоге помогает профилировать
приложение и говорит о просадке по GC.
Monday, February 25, 13
39. Запуск 3
• Ведущий разработчик высказывает версию
о том, что GC в ветке 1.9.x не должен так
втыкать.
• Быстро собираем 1.9.2 и стабилизируем
поток 504тых.
• К концу суток с момента начала работ по
запуску можно выдохнуть.
Monday, February 25, 13
40. Новая прекрасная
жизнь
• Все недовольны.
• Верните как было.
• Я не знаю как этим пользоваться.
• У нас не сходятся цифры.
• С начала жизни проекта.
Monday, February 25, 13
41. Миграция данных 4
• Все чистые данные на месте, но есть куча
проблемных.
• Остатки на счетах съедают нам мозги.
• Правим-перезапускаем-правим.
• Поздняя домиграция. Ставим
миграционный таск в очередь при
попытке логина.
Monday, February 25, 13
42. Деплой
• Больше всего времени съедает
перекомпиляция ресурсов.
• Сейчас для того же использую Turbo-
sprockets-rails3.
• Тогда в качестве process monitoring был
god, сейчас bluepill.
Monday, February 25, 13
43. Производительность
• Слишком интерактивная главная страница.
• Переписываем на статическую компоновку главной страницы
с выполнением операций показа скрытия акций по cron.
• Фрагментарное кеширование. Его никогда не бывает много.
• В итоге последние цифры которые я видел 150rps на
бекэнде. В рельсах.
• В начале года было 20rps на единственном сервере.
• Лендинги. Самое проблемное место в проекте. Нужно писать
тонны лидовых данных. Для пользователей которые еще не
пользователи. И могут ими не стать.
Monday, February 25, 13
44. Sinatra
• Младший брат RoR, фреймворк для создания
однофайловых веб-приложений.
• Создание лендинговых страниц без полного
инстанцирования модельного слоя.
• В целом гипотеза была ошибочной,
стабилизировать лендинги на синатре мы так и
не смогли.
• Говорят async_sinatra помогает, но пробовать
пока негде.
Monday, February 25, 13
45. О высоких нагрузках
• Вы стоите под очень толстой струей воды.
• Пока написанный вами код пропускает ее через
себя без задержки, вы ее не замечаете.
• Как только он начинает лагать, последовательно
наедается все.
• Кошмар заказчика - 504тые по всем фронтам.
• До тех пор пока в команде кто-то не понимает,
что он пишет, любой деплой - катастрофа.
Monday, February 25, 13
46. Климат
• http://issendai.livejournal.com/572510.html
• Хочешь привязать к себе людей, держи их
слишком занятыми чтобы думать.
• Все задачи идут мимо jira.
• Большинство противоречат друг-другу по
приоритетам.
• Релиз в начале декабря, к 20тым числам
проект стабилизирован.
Monday, February 25, 13
47. Климат 2
• Ведущий разработчик требует время на
стабилизацию проекта.
• Заказчик требует все переделать.
• Каждый день.
• Я беру отпуск по уходу за рассудком.
Monday, February 25, 13
48. Климат 3
• В отпуск мне сообщают, что я все
испортил.
• Что ничего не работает (команда говорит
обратное).
• Знакомые говорят, что их собеседуют на
моё место.
• Мне отменяют премию за запуск.
Monday, February 25, 13
49. Внутренние цели
• На протяжении всего года я говорил
себе, что взявшись за проект я не могу
позволить его бросить на середине.
• Начинает возникать понимание.
• Что проект закончен.
• Лучше чем сейчас мне его не сделать.
• А что терять - есть.
Monday, February 25, 13
50. Итог
• В первый рабочий день 2012 года я подаю
заявление об увольнении.
• В течении нескольких месяцев все
региональные зеркала переведены на
новый RoR движок.
• Команда постепенно увольняется.
• Заменяясь аутсорсерами.
Monday, February 25, 13
51. Выученные уроки
• Дизайн нельзя менять вместе с
платформой.
• Дизайн нельзя менять не понимая, что
продает.
• Рельсы позволяют соревноваться по
скорости с самым пытливым умом.
• Но не когда их четыре.
Monday, February 25, 13
53. Благодарности
• Андрею, Антону, Лёше, Антону, Степану,
Петру, Толе, Сергею, Леониду, Диме и
Саше за то, что мы сделали вместе.
• Джасуру, Шавкату, Комилу и Беку за
бесценный опыт и то, что теперь я могу
всё.
Monday, February 25, 13
54. Другой взгляд на
события
• http://www.slideshare.net/alexclear/
ruby-13262249
• Наш DevOps.
Monday, February 25, 13