Как слать 100М писем каждый день - секреты емейл-рассылок компании Badoo (Анд...Andrey Sas
Видео доклада: http://www.youtube.com/watch?v=jJJGdOiwisM
E-mail рассылки являются важным, если не самым главным, каналом связи с пользователями для большинства веб-сервисов. С их помощью уведомляют о новых событиях, предлагают продукцию и выставляют счета. Поэтому трудно переоценить значимость правильного решения проблем отправки и доставки почты в крупном проекте.
Положительный опыт решения таких задач есть у компании «Баду», которая ежедневно рассылает десятки миллионов писем своим пользователям. Чтобы доклад не был излишне абстрактным, в нём будет рассказано о конкретной реализации почтового кластера проекта, системы генерации и отсылки почты, метриках качества и мониторинге, применяемом в «Баду».
Почта в интернет-проекте: инфраструктура, статистика, мониторингAndrey Sas
- Общие рекомендации по проектированию и настройки почтовой инфраструктуры.
Как выбрать почтовый сервер, как правильно делегировать почтовый домен, на что обращают внимания ведущие почтовые сервисы при приёме писем.
- Зачем нужна почтовая статистика?
В большинстве интернет-проектов на почтовую статистику не обращают особого внимания. Отсутствие почтовой статистики не дает возможности объективно оценивать почтовый канал возврата трафика на сайт, привлечение новых пользователей и т. д.
- Как сделать систему почтовой статистики при трафике в десятки миллионов писем в день?
При большом потоке писем сбор почтовой статистики (как и отправка такого количества писем) превращается в высоконагруженный сервис, требующий определенных подходов к проектированию и агрегации данных.
- Какие параметры важны для почтовой статистики?
Стоит упомянуть о том, какие параметры являются обязательными в почтовой статистике, как правильно их измерять, как анализировать почтовый лог MTA. Нужно иметь представление и о том, какие параметры, вероятно, стоит добавить в почтовую статистику в зависимости от бизнес-логики проекта.
- Как правильно анализировать собранные данные?
Как правильно делать выводы о том, насколько хорошо работают письма в системе. Посмотрим, на что в первую очередь стоит обращать внимание при подготовке и проведении массовых почтовых рассылок.
- Как локализовать проблемы с письмами?
Как правильно применять систему фильтров в статистике в зависимости от бизнес-логики проекта? Какие панели мониторинга (dashboards) являются наиболее удачными и репрезентативными?
- Мониторинг: как делать большие почтовые рассылки и спать спокойно.
Какие показатели и их пороговые значения являются критичными при проведении рассылок? Важная дифференциация: на что необходимо обращать внимание в 3 часа ночи, а что может подождать до утра.
Брокер сообщений Kafka в условиях повышенной нагрузкиArtyom Vybornov
Kafka - распределённый брокер сообщений, нашедший широкое применение как универсальная шина для больших данных. Kafka позволяет как реализовать realtime-обработку большого числа событий, так и построить батчевый pipeline по доставке логов.
Почему мы используем Kafka? Если коротко - унификация. А если чуть подробнее - десятки поставщиков, терабайты логов каждый день, онлайн- и офлайн-pipeline'ы - без единой высокопроизводительной шины данных с этим крайне сложно совладать.
Из доклада вы узнаете о том, почему мы перешли на Kafka, и как она вписалась в наш pipeline. Поймёте, как обеспечить exactly once доставку данных. Узнаете о том, как из-за одной опечатки в несколько раз выросла нагрузка на Kafka, и что мы из этого выяснили. Выясните, какие метрики Kafka стоит мониторить и как по ним понять, что что-то идёт не так.
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного se...Sergey Xek
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного server-side API десктопного приложения. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Как слать 100М писем каждый день - секреты емейл-рассылок компании Badoo (Анд...Andrey Sas
Видео доклада: http://www.youtube.com/watch?v=jJJGdOiwisM
E-mail рассылки являются важным, если не самым главным, каналом связи с пользователями для большинства веб-сервисов. С их помощью уведомляют о новых событиях, предлагают продукцию и выставляют счета. Поэтому трудно переоценить значимость правильного решения проблем отправки и доставки почты в крупном проекте.
Положительный опыт решения таких задач есть у компании «Баду», которая ежедневно рассылает десятки миллионов писем своим пользователям. Чтобы доклад не был излишне абстрактным, в нём будет рассказано о конкретной реализации почтового кластера проекта, системы генерации и отсылки почты, метриках качества и мониторинге, применяемом в «Баду».
Почта в интернет-проекте: инфраструктура, статистика, мониторингAndrey Sas
- Общие рекомендации по проектированию и настройки почтовой инфраструктуры.
Как выбрать почтовый сервер, как правильно делегировать почтовый домен, на что обращают внимания ведущие почтовые сервисы при приёме писем.
- Зачем нужна почтовая статистика?
В большинстве интернет-проектов на почтовую статистику не обращают особого внимания. Отсутствие почтовой статистики не дает возможности объективно оценивать почтовый канал возврата трафика на сайт, привлечение новых пользователей и т. д.
- Как сделать систему почтовой статистики при трафике в десятки миллионов писем в день?
При большом потоке писем сбор почтовой статистики (как и отправка такого количества писем) превращается в высоконагруженный сервис, требующий определенных подходов к проектированию и агрегации данных.
- Какие параметры важны для почтовой статистики?
Стоит упомянуть о том, какие параметры являются обязательными в почтовой статистике, как правильно их измерять, как анализировать почтовый лог MTA. Нужно иметь представление и о том, какие параметры, вероятно, стоит добавить в почтовую статистику в зависимости от бизнес-логики проекта.
- Как правильно анализировать собранные данные?
Как правильно делать выводы о том, насколько хорошо работают письма в системе. Посмотрим, на что в первую очередь стоит обращать внимание при подготовке и проведении массовых почтовых рассылок.
- Как локализовать проблемы с письмами?
Как правильно применять систему фильтров в статистике в зависимости от бизнес-логики проекта? Какие панели мониторинга (dashboards) являются наиболее удачными и репрезентативными?
- Мониторинг: как делать большие почтовые рассылки и спать спокойно.
Какие показатели и их пороговые значения являются критичными при проведении рассылок? Важная дифференциация: на что необходимо обращать внимание в 3 часа ночи, а что может подождать до утра.
Брокер сообщений Kafka в условиях повышенной нагрузкиArtyom Vybornov
Kafka - распределённый брокер сообщений, нашедший широкое применение как универсальная шина для больших данных. Kafka позволяет как реализовать realtime-обработку большого числа событий, так и построить батчевый pipeline по доставке логов.
Почему мы используем Kafka? Если коротко - унификация. А если чуть подробнее - десятки поставщиков, терабайты логов каждый день, онлайн- и офлайн-pipeline'ы - без единой высокопроизводительной шины данных с этим крайне сложно совладать.
Из доклада вы узнаете о том, почему мы перешли на Kafka, и как она вписалась в наш pipeline. Поймёте, как обеспечить exactly once доставку данных. Узнаете о том, как из-за одной опечатки в несколько раз выросла нагрузка на Kafka, и что мы из этого выяснили. Выясните, какие метрики Kafka стоит мониторить и как по ним понять, что что-то идёт не так.
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного se...Sergey Xek
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного server-side API десктопного приложения. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Badoo Desktop: оптимизация приложения на миллион юзеров онлайнSergey Xek
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...Ontico
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
Javascript-фреймворки: должен остаться только одинSergey Xek
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Индустрия меняется прямо на глазах. Технология, еще вчера проходившая по категории "модно, но не нужно", сегодня используется даже бомжами, а завтра выбрасывается на свалку. Что учить, куда смотреть, какие книги читать? Я попробую рассказать свой взгляд на серверное программирование сейчас, в 2016 году.
SECON'2016. Тюменцев Евгений, Разработка надежных параллельных, распределенны...SECON
Набор практических приемов, которые позволяют создавать сложные многопоточные, параллельные, распределенные серверные приложения программистам без опыта сетевого и многопоточного программирования, работы с базами данных.
Брокер сообщений Kafka в условиях повышенной нагрузки / Артём Выборнов (Rambl...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 6 июня, 18:00
Тезисы:
http://backendconf.ru/2017/abstracts/2542.html
Kafka - распределённый брокер сообщений, нашедший широкое применение как универсальная шина для больших данных. Kafka позволяет как реализовать realtime-обработку большого числа событий, так и построить батчевый pipeline по доставке логов.
Почему мы используем Kafka? Если коротко - унификация. А если чуть подробнее - десятки поставщиков, терабайты логов каждый день, онлайн- и офлайн-pipeline'ы - без единой высокопроизводительной шины данных с этим крайне сложно совладать.
Из доклада вы узнаете о том, почему мы перешли на Kafka, и как она вписалась в наш pipeline. Поймёте, как обеспечить exactly once доставку данных. Узнаете о том, как из-за одной опечатки в несколько раз выросла нагрузка на Kafka, и что мы из этого выяснили. Выясните, какие метрики Kafka стоит мониторить и как по ним понять, что что-то идёт не так.
Мы в Avito не так давно начали использовать Golang, но он уже успел занять важное место в различных частях проекта. В докладе мы расскажем о том, какие задачи нам помогает решать Go, почему выбор пал именно на этот язык, с какими подводными камнями мы столкнулись, и как их обходили. В частности поговорим про:
• Сервисы. Как мы начали использовать Go для разработки микросервисов, как это сказалось на их поддержке, а также отдельно расскажем про “шаблон сервиса”, который мы используем.
• Поиск. Как мы с помощью Go мы реализовали RtIndexer для обновления Sphinx Rt индексов в кластере из множества машин (поиск по активным объявлениям), который устойчиво работает с отставанием не более 10 секунд при нагрузке до 1000 rps.
• Автоматизацию тестирования. Как мы пишем тестовые сервисы и API на Go. Подробней остановимся на использовании общих моделей тел запросов и ответов для отправки и получения, использовании горутин как воркеров для обработки очереди.
Миф об очень сложном 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, чем новое железо.
- Очень много очен�
Доклад о том, как мы добились идеально ровной балансировки нагрузки по кластеру из 200+ серверов, реализовали автоматический подбор весов и получили разброс CPU usage в 2,5% в пике трафика. Это позволило сэкономить нам около 40-50 серверов и улучшить время отклика мобильного сайта в пике нагрузки. Реализацию приведенного алгоритма мы выложим в open-sourсe. Доклад Юрия Насретдинова на Highload 2015.
Кластерный LDAP-сервера для "Больших телекомов".
Слайды доклад с 12-ой Конференции Разработчиков Свободных Программ, 17-18 Октября 2015, г.Калуга
АННОТАЦИЯ
Производственная необходимость и обстоятельства подтолкнули Петер-Сервис использовать OpenLDAP в своих решениях, а затем заставили добиться «от этого кошмара» надёжной работы в нагруженном кластере.
Увы и ах, но общеизвестный проект с открытым исходным кодом и 25-летней историей, лежащий в основе LDAP как технологии, оказался хорошим примером «так делать НЕ надо». Но отступать нам было не с руки...
В результате мы сделали клон исходного проекта и за год получили LDAP-сервер относительно пригодный для промышленной эксплуатации в сфере телекоммуникаций: десятки и сотни миллионов записей, высокие нагрузки, высокая доступность, 24x7.
Rspamd — высокопроизводительная система фильтрации спама / Стахов Всеволод (U...Ontico
Rspamd — это система фильтрации спама с открытым кодом, выполняющая оценку e-mail сообщений по множеству критериев, который возник как попытка адаптировать фильтрацию спама к современным реалиям и постоянно растущему потоку электронных писем, нуждающихся в обработке.
Тезисы - http://www.highload.ru/2015/abstracts/1892.html
«Бутылочное горлышко многопоточных программ – кто виноват, и что делать. Мастер-класс.»
BitByte: 20 апреля 2013, Санкт-Петербург
http://bitbyte.itmozg.ru/
Badoo Desktop: оптимизация приложения на миллион юзеров онлайнSergey Xek
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...Ontico
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
Javascript-фреймворки: должен остаться только одинSergey Xek
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Индустрия меняется прямо на глазах. Технология, еще вчера проходившая по категории "модно, но не нужно", сегодня используется даже бомжами, а завтра выбрасывается на свалку. Что учить, куда смотреть, какие книги читать? Я попробую рассказать свой взгляд на серверное программирование сейчас, в 2016 году.
SECON'2016. Тюменцев Евгений, Разработка надежных параллельных, распределенны...SECON
Набор практических приемов, которые позволяют создавать сложные многопоточные, параллельные, распределенные серверные приложения программистам без опыта сетевого и многопоточного программирования, работы с базами данных.
Брокер сообщений Kafka в условиях повышенной нагрузки / Артём Выборнов (Rambl...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 6 июня, 18:00
Тезисы:
http://backendconf.ru/2017/abstracts/2542.html
Kafka - распределённый брокер сообщений, нашедший широкое применение как универсальная шина для больших данных. Kafka позволяет как реализовать realtime-обработку большого числа событий, так и построить батчевый pipeline по доставке логов.
Почему мы используем Kafka? Если коротко - унификация. А если чуть подробнее - десятки поставщиков, терабайты логов каждый день, онлайн- и офлайн-pipeline'ы - без единой высокопроизводительной шины данных с этим крайне сложно совладать.
Из доклада вы узнаете о том, почему мы перешли на Kafka, и как она вписалась в наш pipeline. Поймёте, как обеспечить exactly once доставку данных. Узнаете о том, как из-за одной опечатки в несколько раз выросла нагрузка на Kafka, и что мы из этого выяснили. Выясните, какие метрики Kafka стоит мониторить и как по ним понять, что что-то идёт не так.
Мы в Avito не так давно начали использовать Golang, но он уже успел занять важное место в различных частях проекта. В докладе мы расскажем о том, какие задачи нам помогает решать Go, почему выбор пал именно на этот язык, с какими подводными камнями мы столкнулись, и как их обходили. В частности поговорим про:
• Сервисы. Как мы начали использовать Go для разработки микросервисов, как это сказалось на их поддержке, а также отдельно расскажем про “шаблон сервиса”, который мы используем.
• Поиск. Как мы с помощью Go мы реализовали RtIndexer для обновления Sphinx Rt индексов в кластере из множества машин (поиск по активным объявлениям), который устойчиво работает с отставанием не более 10 секунд при нагрузке до 1000 rps.
• Автоматизацию тестирования. Как мы пишем тестовые сервисы и API на Go. Подробней остановимся на использовании общих моделей тел запросов и ответов для отправки и получения, использовании горутин как воркеров для обработки очереди.
Миф об очень сложном 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, чем новое железо.
- Очень много очен�
Доклад о том, как мы добились идеально ровной балансировки нагрузки по кластеру из 200+ серверов, реализовали автоматический подбор весов и получили разброс CPU usage в 2,5% в пике трафика. Это позволило сэкономить нам около 40-50 серверов и улучшить время отклика мобильного сайта в пике нагрузки. Реализацию приведенного алгоритма мы выложим в open-sourсe. Доклад Юрия Насретдинова на Highload 2015.
Кластерный LDAP-сервера для "Больших телекомов".
Слайды доклад с 12-ой Конференции Разработчиков Свободных Программ, 17-18 Октября 2015, г.Калуга
АННОТАЦИЯ
Производственная необходимость и обстоятельства подтолкнули Петер-Сервис использовать OpenLDAP в своих решениях, а затем заставили добиться «от этого кошмара» надёжной работы в нагруженном кластере.
Увы и ах, но общеизвестный проект с открытым исходным кодом и 25-летней историей, лежащий в основе LDAP как технологии, оказался хорошим примером «так делать НЕ надо». Но отступать нам было не с руки...
В результате мы сделали клон исходного проекта и за год получили LDAP-сервер относительно пригодный для промышленной эксплуатации в сфере телекоммуникаций: десятки и сотни миллионов записей, высокие нагрузки, высокая доступность, 24x7.
Rspamd — высокопроизводительная система фильтрации спама / Стахов Всеволод (U...Ontico
Rspamd — это система фильтрации спама с открытым кодом, выполняющая оценку e-mail сообщений по множеству критериев, который возник как попытка адаптировать фильтрацию спама к современным реалиям и постоянно растущему потоку электронных писем, нуждающихся в обработке.
Тезисы - http://www.highload.ru/2015/abstracts/1892.html
«Бутылочное горлышко многопоточных программ – кто виноват, и что делать. Мастер-класс.»
BitByte: 20 апреля 2013, Санкт-Петербург
http://bitbyte.itmozg.ru/
«История строителя: Maven - от новичка до мастера. Сборка простых и сложных Java- проектов.»
BitByte: 20 апреля 2013, Санкт-Петербург
http://bitbyte.itmozg.ru/
The document discusses several new features in Java 8 including lambda expressions, default methods in interfaces, and type annotations. It provides examples of using the new date/time API, annotations on types, and default methods in interfaces. It also summarizes features like Java profiles, parallel collections, and improvements to the Java Virtual Machine.
«Зачем рекрутеры сидят во Вконтакте. Как формируется имидж соискателя в социальных сетях?»
BitByte: 20 апреля 2013, Санкт-Петербург
http://bitbyte.itmozg.ru/
«Собеседования: что сделать, чтобы точно его не пройти и как определиться с работой мечты»
BitByte: 20 апреля 2013, Санкт-Петербург
http://bitbyte.itmozg.ru/
Полной автоматизацией процесса сборки приложения уже никого не удивишь. Не в последнюю очередь благодаря Maven – системе управления жизненным циклом проекта. Однако проекты растут очень быстро: увеличивается количество модулей, тестов, зависимостей, используемых плагинов. И всего лишь за год легковесный проект, на сборку которого уходило 5 минут, превращается в монстра, который пожирает время разработчиков 30-минутной сборкой. Чтобы справится с этой проблемой разработчикам приходится постоянно чистить свой код и бороться со скоростью выполнения тестов. Это верное решение, но не следует забывать о том, что и сам процесс сборки можно улучшить. В этом докладе будет рассмотрено, как при помощи простых и нехитрых шагов можно оптимизировать работу с зависимостями и обогатить скрипты сборки полезными плагинами. Также будут обсуждаться тонкости конфигурации основных плагинов и особенности работы с командной строкой, которые появились в последней версии Maven.
Интернет-бизнес Как повысить доставляемость вашей email-рассылки (email-рассы...Александр Круглов
Сайт сервиса АвтоВебОфис (АвтоОфис): https://autoweboffice.ru/?r=acs&id=118&lg=ru
Из видео Вы узнаете:
- Как повысить доставляемость вашей email-рассылки?»
- Основные каналы оповещения клиентов
- Почему рассылки попадают в СПАМ?
- Общие требования почтовых сервисов
- Как рассылать письма самостоятельно?
- Зачем нужен свой IT-отдел для работы с email-рассылками?
- Что нужно делать Вам построения эффективного email-маркетинга?
Badoo Desktop: оптимизация приложения на миллион юзеров онлайнSergey Xek
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Компания «Моё дело» прошла путь от маленького стартапа до лидера рынка в своем сегменте. Вместе с ростом компании росла и ее it структура. Инфраструктура эволюционировала космическими темпами, кол-во проектов стремительно росло. Естественно, всем этим необходимо уметь грамотно оркестрировать. Как это делаем мы и во что это превращается мы и хотим вам рассказать.
SECON'2016. Парамонов Сергей, Автоматизируй это! Как не погрязнуть в рутине п...SECON
В разработке игр существует множество сопутствующих проблем, которые приходиться решать разработчику, но которые напрямую не связаны с игровым процессом. Автоматизация рутинных задач - лучшее решение, позволяющее сэкономить время для воплощения творческого замысла в условиях компактных команд и компаний.
Zabbix Moscow Meetup 2016
Доклад Ильи Аблеева, руководителя Отдела мониторинга Badoo на тему: "От LLD к Super Discovery или как переложить мониторинг на девелопера".
В докладе Илья рассказал про то как его отдел покрыл в Badoo мониторингом довольно большое количество бизнес- и аппликейшн-метрик, не заставляя девелоперов изучать Zabbix API и как расширили стандартные возможности уведомлений Zabbix.
Доклад Андрея Саса на конференции РИТ++ 2014. "Email-рассылки для профи- част...Badoo Development
Внезапно оказалось, что email-рассылка важна для вашего проекта? Обнаружили, что письма приходят в "Спам"? Иногда пользователи ждут их по часу? Хотите увеличить число отправляемых писем в N раз и не знаете, справится ли почтовый сервер? Не знаете, как правильно тестировать разные версии писем?
Этот доклад даст вам видение всего спектра задач, которые приходится решать для поддержания email-рассылок проекта "в тонусе", а также представление о возможных путях их решения.
Популярные проблемы и пути их решения:
1. Техническая реализация:
а) что нужно знать:
- устройство вашей системы отправки;
- как настроены механизмы авторизации писем;
- какова скорость рассылки, каково число серверов и т.п.;
б) популярные задачи и проблемы:
- хочу слать 3 миллиона писем в день, как много серверов мне понадобится?
- собственный сервер vs. сторонний рассыльщик?
- как понять, что сервис рассылок "плохой"?
- без какой статистики нельзя жить?
в) полезные советы и хаки:
- микрофреймворк для писем;
- config типов писем;
- асинхронная генерация писем;
- мониторинг падений email-адресов.
2. Доставляемость:
а) что нужно знать:
- распределение базы по почтовым сервисам;
- источники пополнения базы;
- типы писем и логику их рассылки;
- историю проблем с доставляемостью;
б) популярные задачи и проблемы:
- письма начали приходить в "Спам", что же делать?
- как построить мониторинг доставляемости?
в) полезные советы и хаки:
- популярные ошибки, приводящие к проблемам;
- postmaster.mail.ru;
- postoffice.yandex.ru;
- будьте осторожны с приглашениями;
- график среднего времени доставки как показатель доставляемости.
Загрузка больших объемов данных для бизнес-аналитикиBadoo Development
В Badoo мы разрабатываем собственную систему Business intelligence (сокращённо BI). И прежде, чем приступать к анализу данных, их необходимо извлечь (Extract) из источников, преобразовать (Transform) и загрузить (Load) в аналитическую базу.
Я расскажу об этом процессе - ETL (Extract, Transform, Load). Какие бывают источники данных, какие методы сбора мы используем. И самое главное - об инструменте под названием ETLMaster, созданным в нашей компании для автоматизации управления процессом трансформации и загрузки данных.
Илья Аблеев – Zabbix в Badoo: реагируем быстро и качественноBadoo Development
В условиях большой инфраструктуры и немалого количества критичных компонентов, время реакции на инцидент должно быть как можно меньше. В докладе я расскажу, какие инструменты помогают увеличить скорость реакции и уведомить о проблеме качественнее.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Грабли при ма...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. «Грабли при масштабировании веб-приложения, на которые очень легко наступить», Евгений Коковихин (системный архитектор WapStart)
Аннотация
Что происходит при росте приложения с 1М до 50М хитов в сутки. С какими проблемами можно столкнуться, когда серверов становится больше одного. О чем важно помнить при проектировании приложения, способного масштабироваться.
Подробно
Когда мы сделали первую публичную версию plus1.wapstart.ru, она помещалась на один сервер и была соответствующим образом спроектирована. Потом нагрузка начала расти, а мы начинали наступать на грабли. В докладе будет рассказано о наиболее типичных "граблях", что возможно позволит избежать их другими разработчиками при проектировании приложения.
О чем пойдет речь (кратко):
* балансировка нагрузки;
* кеширование данных и прогрев кешей;
* работа с сетью;
* сессии;
* файлы, загружаемые пользователями;
* работа с СУБД.
Мы пишем на PHP, используем фреймворк OnPHP, СУБД Postgres.
Биография
Родился в несуществующем городе несуществующей страны. Первый мобильный телефон увидел в 1997 году. С детства любил программировать, последние 4 года посвятил развитию рекламы в мобильном веб. Своими глазами видел эволюцию мобильных устройств и предпочтений рекламодателей.
Жизнь проекта на production советы по эксплуатации / Николай Сивко (okmeter.io)Ontico
Ваш сайт или другой проект приносит деньги только тогда, когда он работает.
Нельзя просто выложить код на серверы, залить схему в базу данных и делегировать домен.
Будем говорить о планировании отказоустойчивости и мониторинге проектов:
- оцениваем риски отказа различных компонентов;
- какие-то из вероятных проблем просто мониторим и планируем действия при сбоях;
- проблемы, которых можно избежать легко и дешево, закрываем сразу.
Расскажу на примерах о том, что всё всегда ломается, но с этим можно жить.
5. А кто говорит?
Я:
•руковожу развитием почтовой рассылки, могу знать не
все детали;
•не админ (извините!).
Хвастаюсь:
•год без пролёжек почтовой инфраструктуры;
6. А кто говорит?
Я:
•руковожу развитием почтовой рассылки, могу знать не
все детали;
•не админ (извините!).
Хвастаюсь:
•год без пролёжек почтовой инфраструктуры;
•97% доставки в инбокс;
7. А кто говорит?
Я:
•руковожу развитием почтовой рассылки, могу знать не
все детали;
•не админ (извините!).
Хвастаюсь:
•год без пролёжек почтовой инфраструктуры;
•97% доставки в инбокс;
•среднее время доставки почты – 15 с.
13. Бизнес-задачи
1. Предоставить прозрачный API программистам.
2. Обеспечить отправку почты в объёмах до 150М
писем в день.
3. Обеспечить доставку почты во «Входящие» в 95%+
случаев.
14. О чём НЕ буду
рассказывать?
Как сделать так, чтобы ваши письма
не попадали в Spam
15. А что в этом сложного?
Казалось бы:
•поднял MTA (mail transfer agent)
•сделал mail()
•...
•PROFIT!
16. А что в этом сложного?
Казалось бы:
•поднял MTA (mail transfer agent)
•сделал mail()
Однако:
•отправка 1 письма = обработка 1 динамического хита
17. А что в этом сложного?
Казалось бы:
•поднял MTA (mail transfer agent)
•сделал mail()
Однако:
•отправка 1 письма = обработка 1 динамического хита
•а ведь письма ещё нужно сгенерировать
18. А что в этом сложного?
Казалось бы:
•поднял MTA (mail transfer agent)
•сделал mail()
Однако:
•отправка 1 письма = обработка 1 динамического хита
•а ведь письма ещё нужно сгенерировать
•смелость пойти и узнать правду!!1111
19. Откуда взялась цифра
150М?
• 50М – каждый день
• 70М – в пике
• 100М – просто красивая цифра
• 150М – «пасаны ваще ребята. молодцы, могёте!»
23. Порядок отправки
письма
1.Появляется необходимость создать письмо.
2.Постановка в очередь на создание письма.
3.Генерация письма по задачам из очереди на
создание.
4.Постановка в очередь на отправку.
5.Отсылка письма из очереди на отправку.
24. Очередь на отправку
Наша реализация – на файлах. Преимущества:
1.Возможна работа без внешних сервисов.
2.Простота манипулирования письмами.
3.Легко получить статистику / логи.
4.Просто реализуются многократные попытки отправки.
25. SSMTP вместо sendmail
Это SMTP-клиент, эмулирующий работу sendmail.
Нам он нравится, т.к.:
•ничего лишнего, только отсылает письмо в MTA (hub)
•супер простой конфиг
•мы его слегка допилили (таймауты + параметры)
26. Балансировка между
MTA
Первая версия – на базе железки F5 LTM:
•weighted round robin
•SMTP мониторинг
Текущая реализация – скрипты на PHP + мониторинг от
F5 LTM:
•автоматическое управление всей балансировкой
•красивый веб-интерфейс
•скрипач (админ) не нужен!
27. Автоматизация при
отправке
Хорошее место, чтобы делать добрые дела:
•подставлять:
• параметры для авторизации в ссылки
• параметры для статистики в ссылки
• картинки для мониторинга открытий
• технические заголовки
•проверять целостность и корректность письма
•и даже тестировать работоспособность ссылок!
29. Как тюнить MTA?
• оптимизировать файловую систему (noatime)
• увеличить число SMTP воркеров
• увеличить число DNS воркеров
• поставить локальный кэшер DNS-запросов (unbound)
• раскладывать очередь по большому числу
директорий
• увеличить лимиты на число соединений к одному MX
серверу
• выставить лимиты на число писем в сессии
30. Наши MTA
Исторически – Communigate Pro:
•надёжный
•ОЧЕНЬ быстрый
Для «проблемных» почтовых сервисов – Postfix:
•более конфигурируемый
•есть возможность доработать напильником
31. Хм, Communigate Pro?..
Но ведь есть Postfix, Exim,
Hurricane, Message Systems, Zrinity
и даже Exchange!
34. Однако, цифры
На старой машине с 1 диском SCSI 10k:
•5 миллионов писем в сутки
•до 100 писем в секунду в пике
35. Общее ощущение
+ чрезвычайно стабилен, вплоть до LA = 200 и очереди
в 1М писем
+ высокая производительность отправки писем
+ не требователен к памяти и CPU
+ достаточно настроек для большинства проектов
* платный
– нет возможности менять настройки для разных
почтовиков
– нет возможности допилить самим
– проблемы с выводом некоторых видов статистики
36. Статистика и
мониторинг
Пока не измеряешь – не контролируешь.
Что было в начале?
•графики по числу писем в очереди на каждом
почтовике
•сколько каких писем отправили за сутки
•статистика по LA / CPU usage / Memory usage в Zabbix
37.
38. Чего не хватало больше
всего?
1. Число файлов, ожидающих отправки в MTA
2. Среднее время отправки письма в MTA
3. Среднее время доставки почты во внешние
почтовые сервисы
А также:
• число ошибок отправки писем в MTA
• самые загруженные отправкой почты скриптовые
машины
39. Как реализовали?
Число файлов, ожидающих отправки в MTA:
• просто считаем файлы!
Число ошибок отправки в MTA:
• просто считаем файлы!
Самые загруженные отправкой почты скриптовые
машины:
• лог в MySQL
40. Как реализовали?
Среднее время отправки в MTA:
• время отправки письма минус время создания
Среднее время доставки почты во внешние почтовые
сервис:
• парсим логи MTA
• хитрая агрегационная структура (highload!!1111)
48. Dashboard нас спасёт?
1. Несколько dashboard’ов.
2. Даже dashboard’ы стали слишком сложными.
3. Детектировать аномалии даже на менее значимых
графиках автоматически.
50. И что же нового?
С осени 2011 года поменялось:
•Название!
•1 -> 2,5 года без пролёжек почтовой инфраструктуры;
•97% -> 98% inbox placement rate
•Мониторинг лендинга на мобильных версиях
•Лечение от single point of failure (SPoF)
51. И что же нового?
С осени 2011 года поменялось:
•тегирование ссылок для Google Analytics (легко!)
•выгрузка данных в систему business intelligence (BI)
•API для A/B тестирования
52. Выводы
1. Быть гуру не надо, достаточно хотеть разобраться.
2. Правильная архитектура без мониторинга не спасёт.
3. Внезапно: отправка почты – тоже highload!
4. Не стойте на месте, развивайте почту, если она для
вас важна.
5. …
6. PROFIT!!!
53. Ваши вопросы *
* Кроме вопросов о том, как
мы доставляемся в Inbox