Электронная коммерция: от Hadoop к Spark ScalaRoman Zykov
Как обрабатывать большой объем данных быстро с наименьшими затратами? Мы смогли этого добиться в компании
RetailRocket. Обработка данных – это наш бизнес! У нас много данных: более 100 Тбайт, в сутки нам поступает более 100 млн
событий для обработки. До недавнего времени у нас все работало на кластере на базе Hadoop относительно устаревшего
дистрибутива Cloudera CDH 4.5, программный код был написан на Pig, Hive, Python и Java. Это порождало ряд проблем с
архитектурой, производительностью. Тестирование превращалось в настоящую головную боль. В конце лета RetailRocket
перешел на Yarn на базе CDH 5.1.2. Это открыло путь к более совершенным технологиям семейства Spark. Сейчас мы
находимся в фазе полного перехода на Spark на функциональном языке Scala. Это позволило нам избавиться от зоопарка
технологий, упростив архитектуру решений и автоматизировав тестирование. Первые результаты не заставили себя ждать –
получен прирост производительности на том же железе в три-пять раз. А это значит, что мы будем меньше инвестировать в
расширение парка серверов кластера. В докладе будет рассказано о проблемах, с которыми мы столкнулись, и о том как мы
их решили. Будут примеры исходного кода для оптимизации производительности и повышения удобства работы, который мы
закоммитили в наш публичный GitHub
WebCamp2016:Front-End_Юрий Артюх_Современные подходы в версткеWebCamp
WebCamp2016, 29 июля, Одесса
Юрий Артюх Chief Technology Officer, Coderiver
Современные подходы в верстке
В 2016 верстка трансформируется, о том как ее автоматизировать, и выжить верстальщику среди реактов, ангуларов и прочего и будет рассказ.
Website: http://webcamp.in.ua/devops.html#theme
Facebook: https://www.facebook.com/WebCamp/
VK: https://vk.com/webcamp
Twitter: https://twitter.com/WebCampOdessa
Youtube: http://bit.ly/2bsQ0LO
Электронная коммерция: от Hadoop к Spark ScalaRoman Zykov
Как обрабатывать большой объем данных быстро с наименьшими затратами? Мы смогли этого добиться в компании
RetailRocket. Обработка данных – это наш бизнес! У нас много данных: более 100 Тбайт, в сутки нам поступает более 100 млн
событий для обработки. До недавнего времени у нас все работало на кластере на базе Hadoop относительно устаревшего
дистрибутива Cloudera CDH 4.5, программный код был написан на Pig, Hive, Python и Java. Это порождало ряд проблем с
архитектурой, производительностью. Тестирование превращалось в настоящую головную боль. В конце лета RetailRocket
перешел на Yarn на базе CDH 5.1.2. Это открыло путь к более совершенным технологиям семейства Spark. Сейчас мы
находимся в фазе полного перехода на Spark на функциональном языке Scala. Это позволило нам избавиться от зоопарка
технологий, упростив архитектуру решений и автоматизировав тестирование. Первые результаты не заставили себя ждать –
получен прирост производительности на том же железе в три-пять раз. А это значит, что мы будем меньше инвестировать в
расширение парка серверов кластера. В докладе будет рассказано о проблемах, с которыми мы столкнулись, и о том как мы
их решили. Будут примеры исходного кода для оптимизации производительности и повышения удобства работы, который мы
закоммитили в наш публичный GitHub
WebCamp2016:Front-End_Юрий Артюх_Современные подходы в версткеWebCamp
WebCamp2016, 29 июля, Одесса
Юрий Артюх Chief Technology Officer, Coderiver
Современные подходы в верстке
В 2016 верстка трансформируется, о том как ее автоматизировать, и выжить верстальщику среди реактов, ангуларов и прочего и будет рассказ.
Website: http://webcamp.in.ua/devops.html#theme
Facebook: https://www.facebook.com/WebCamp/
VK: https://vk.com/webcamp
Twitter: https://twitter.com/WebCampOdessa
Youtube: http://bit.ly/2bsQ0LO
Доклад Сергея Аверина на DevConf 2013. "Распространенные ошибки применения ба...Badoo Development
Доклад не про БД в чистом виде а про архитектуру веб-приложений, использующих БД.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
Подробно:
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, которые потом в реальной жизни никогда не понадобятся.
• Или проектируется архитектура, которая якобы дает отказоустойчивость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологическая» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки событий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и небольших команд, техническим руководителям.
Badoo — это большая социальная сеть с более чем 180 млн. пользователей. Большинство новых фич в нашей компании мы предварительно оцениваем посредством A/B тестирования. Вот уже примерно год мы используем собственный высоконагруженный фреймворк тестирования, при этом по моему мнению он очень прост, понятен, и не требует огромных ресурсов на разработку и поддержку. В докладе я расскажу вам о том, почему мы пришли к собственному решению, его архитектуру и принципы работы. Я уверен, каждый из вас может сделать что-то подобное для своего проекта и начать принимать более обоснованные решения.
Тезисы:
* Как мы раньше тестировали
* Почему мы сделали свой инструмент
* Архитектура: API, граф. интерфейсы, транспорт, скрипты, БД
* Структура теста
* Основные правила А/Б тестирования
* Оценка результатов, примеры отчетов
* И заключительная часть про то, что от человека с головой полностью не избавиться
Для кого доклад:
Для разработчиков и техн. менеджеров соц. сетей, сайтов объявлений, блогов с рассылками, проектов, продающих что-то через e-mail расслыки, разных коммьюнити-сайтов, банков и вообще проектов, где взаимодействие с каждым клиентом долгосрочное.
Сложность:
Несмотря на то, что конференция называется Highload++, я уверяю, что представленную здесь архитектуру может потянуть проект с посещаемостью в 1000 чел в день и тремя программистами в штате. Закодить все, что здесь рассказано на PHP займет меньше недели одного человека. А результат, между прочим, пожно вполне изменрять в живой прибыли.
Последовательная и параллельная загрузка, преимущества и недостатки. Разбираемся с основами сетей. Померим размер js файлов. Посмотрим на паттерны использования. Обратимся к основам программирования и базовым структурам данных. Разберёмся с механизмом пошаговой загрузки изображений. Напишем queue/sliding-buffer, посмотрим на девственно-чистый js/es2015.
Как слать 100М писем каждый день - секреты емейл-рассылок компании Badoo (Анд...Andrey Sas
Видео доклада: http://www.youtube.com/watch?v=jJJGdOiwisM
E-mail рассылки являются важным, если не самым главным, каналом связи с пользователями для большинства веб-сервисов. С их помощью уведомляют о новых событиях, предлагают продукцию и выставляют счета. Поэтому трудно переоценить значимость правильного решения проблем отправки и доставки почты в крупном проекте.
Положительный опыт решения таких задач есть у компании «Баду», которая ежедневно рассылает десятки миллионов писем своим пользователям. Чтобы доклад не был излишне абстрактным, в нём будет рассказано о конкретной реализации почтового кластера проекта, системы генерации и отсылки почты, метриках качества и мониторинге, применяемом в «Баду».
HappyDev'15 Keynote: Когда все данные станут большими...Alexey Zinoviev
Этот момент обязательно наступит, если ваш проект, ваш бизнес сделаны не для того, чтобы вспыхнуть Фениксом в пламени бюджетов. Его важно не пропустить и начать обряд масштабирования как можно раньше.
Однако, не для каждой ситуации может подойти простое натравливание Hadoop на ваши логи, перелив данных из PostgreSQL в Cassandra или беспощадный тюнинг nginx и JVM.
Всегда стоит идти от задач, от представления о системе аналитики или от определенного заранее уровня отзывчивости системы. В этом докладе я хотел бы сосредоточиться не на инструментарии, столь важном для разработчика, а, напротив, поговорить о различных типах вопросов и болей с которыми приходят к нам заказчики в реальном мире, где никому нет дела до ваших результатов на Kaggle (онлайн-олимпиада по анализу данных) и синтетических тестов производительности, а также о процессе поиска ответов на эти вопросы. В реальном мире конечная идея приложения может измениться до неузнаваемости в один момент.
Приходите, разберем как хорошие случаи, так и типичные ошибки в построении приложений.
Для кого хорошо подойдет данный доклад: для тех, кто не слишком знаком с концепцией BigData, либо хорошо знаком с инструментарием разработчика, но нет определенной ясности в том, а для чего все это нужно. Ну и если вы идете на мастер-класс, то заходите, лишним не будет.
Веб-приложения бывают разные: от сайтов-визиток небольших компаний или персональных блогов, до известных социальных сетей и популярных интернет-магазинов, обслуживающих миллионы пользователей по всему миру. Как устроены сложные веб-приложения «под капотом», за счет чего они выдерживают высокие нагрузки и как строится взаимодействие пользователя с такими нетривиальными веб-приложениеми, мы рассмотрим в докладе.
Компания "Ленвендо" занимается созданием, развитием и поддержкой крупномасштабных онлайн-проектов.
Сегодня «Ленвендо» отвечает за работу ресурсов «Эльдорадо», «Связной», HomeMe, Газпромбанк, Эхо Москвы в Петербурге.
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Несколько...IT-Portfolio
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Несколько кейсов из жизни "больших" проектов", Виталий Гаврилов (технический директор "Ленвендо")
Аннотация
Команда разработчиков «Ленвендо» реализовала сотни проектов, среди которых были сайты и интернет-магазины для компаний: Эльдорадо, Газпромбанк, Связной, SUP media, Эхо Москвы в Петербурге, Банк БФА и другие. Специалисты компании в совершенстве владеют языками программирования от низкоуровневого C++ до высокоуровневых PHP, Perl, Bash и умею разрабатывать проекты с многомиллионной посещаемостью.
В рамках презентации будет рассмотрено несколько интересных кейсов из практики «Ленвендо». Мы поговорим об особенностях построения высоконагруженных проектов с использованием БД PostgreSQL, о резервном копировании и особенностях его организации в высоконагруженных проектах с большими объемами данных. Также остановимся на специфике проектов, размещенных в 2-х и более датацентрах, и тех инструментах, которые мы используем для построения таких проектов (csync2, MySQL Multi-Master Replication и т.д.).
Особое внимание будет уделено теме управляемого статического кеширования, позволяющего существенно (от 30% до нескольких раз) снизить нагрузку на backend-сервера с сохранением актуальности отображаемой на сайте информации (с помощью RabbitMQ, RedisDB, Nginx embedded Perl).
И напоследок - короткое «лирическое» отступление о том, когда и для чего имеет смысл использовать СУБД Oracle.
О компании
Компания «Ленвендо» - профессионал в области разработки, внедрения и технической поддержки высоконагруженных Интернет-решений. Компания была признана одной из лидеров по разработке Highload-систем (рейтинг Best in Digital 2013).
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 и некоторых других местах.
Доклад Сергея Аверина на DevConf 2013. "Распространенные ошибки применения ба...Badoo Development
Доклад не про БД в чистом виде а про архитектуру веб-приложений, использующих БД.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
Подробно:
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, которые потом в реальной жизни никогда не понадобятся.
• Или проектируется архитектура, которая якобы дает отказоустойчивость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологическая» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки событий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и небольших команд, техническим руководителям.
Badoo — это большая социальная сеть с более чем 180 млн. пользователей. Большинство новых фич в нашей компании мы предварительно оцениваем посредством A/B тестирования. Вот уже примерно год мы используем собственный высоконагруженный фреймворк тестирования, при этом по моему мнению он очень прост, понятен, и не требует огромных ресурсов на разработку и поддержку. В докладе я расскажу вам о том, почему мы пришли к собственному решению, его архитектуру и принципы работы. Я уверен, каждый из вас может сделать что-то подобное для своего проекта и начать принимать более обоснованные решения.
Тезисы:
* Как мы раньше тестировали
* Почему мы сделали свой инструмент
* Архитектура: API, граф. интерфейсы, транспорт, скрипты, БД
* Структура теста
* Основные правила А/Б тестирования
* Оценка результатов, примеры отчетов
* И заключительная часть про то, что от человека с головой полностью не избавиться
Для кого доклад:
Для разработчиков и техн. менеджеров соц. сетей, сайтов объявлений, блогов с рассылками, проектов, продающих что-то через e-mail расслыки, разных коммьюнити-сайтов, банков и вообще проектов, где взаимодействие с каждым клиентом долгосрочное.
Сложность:
Несмотря на то, что конференция называется Highload++, я уверяю, что представленную здесь архитектуру может потянуть проект с посещаемостью в 1000 чел в день и тремя программистами в штате. Закодить все, что здесь рассказано на PHP займет меньше недели одного человека. А результат, между прочим, пожно вполне изменрять в живой прибыли.
Последовательная и параллельная загрузка, преимущества и недостатки. Разбираемся с основами сетей. Померим размер js файлов. Посмотрим на паттерны использования. Обратимся к основам программирования и базовым структурам данных. Разберёмся с механизмом пошаговой загрузки изображений. Напишем queue/sliding-buffer, посмотрим на девственно-чистый js/es2015.
Как слать 100М писем каждый день - секреты емейл-рассылок компании Badoo (Анд...Andrey Sas
Видео доклада: http://www.youtube.com/watch?v=jJJGdOiwisM
E-mail рассылки являются важным, если не самым главным, каналом связи с пользователями для большинства веб-сервисов. С их помощью уведомляют о новых событиях, предлагают продукцию и выставляют счета. Поэтому трудно переоценить значимость правильного решения проблем отправки и доставки почты в крупном проекте.
Положительный опыт решения таких задач есть у компании «Баду», которая ежедневно рассылает десятки миллионов писем своим пользователям. Чтобы доклад не был излишне абстрактным, в нём будет рассказано о конкретной реализации почтового кластера проекта, системы генерации и отсылки почты, метриках качества и мониторинге, применяемом в «Баду».
HappyDev'15 Keynote: Когда все данные станут большими...Alexey Zinoviev
Этот момент обязательно наступит, если ваш проект, ваш бизнес сделаны не для того, чтобы вспыхнуть Фениксом в пламени бюджетов. Его важно не пропустить и начать обряд масштабирования как можно раньше.
Однако, не для каждой ситуации может подойти простое натравливание Hadoop на ваши логи, перелив данных из PostgreSQL в Cassandra или беспощадный тюнинг nginx и JVM.
Всегда стоит идти от задач, от представления о системе аналитики или от определенного заранее уровня отзывчивости системы. В этом докладе я хотел бы сосредоточиться не на инструментарии, столь важном для разработчика, а, напротив, поговорить о различных типах вопросов и болей с которыми приходят к нам заказчики в реальном мире, где никому нет дела до ваших результатов на Kaggle (онлайн-олимпиада по анализу данных) и синтетических тестов производительности, а также о процессе поиска ответов на эти вопросы. В реальном мире конечная идея приложения может измениться до неузнаваемости в один момент.
Приходите, разберем как хорошие случаи, так и типичные ошибки в построении приложений.
Для кого хорошо подойдет данный доклад: для тех, кто не слишком знаком с концепцией BigData, либо хорошо знаком с инструментарием разработчика, но нет определенной ясности в том, а для чего все это нужно. Ну и если вы идете на мастер-класс, то заходите, лишним не будет.
Веб-приложения бывают разные: от сайтов-визиток небольших компаний или персональных блогов, до известных социальных сетей и популярных интернет-магазинов, обслуживающих миллионы пользователей по всему миру. Как устроены сложные веб-приложения «под капотом», за счет чего они выдерживают высокие нагрузки и как строится взаимодействие пользователя с такими нетривиальными веб-приложениеми, мы рассмотрим в докладе.
Компания "Ленвендо" занимается созданием, развитием и поддержкой крупномасштабных онлайн-проектов.
Сегодня «Ленвендо» отвечает за работу ресурсов «Эльдорадо», «Связной», HomeMe, Газпромбанк, Эхо Москвы в Петербурге.
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Несколько...IT-Portfolio
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Несколько кейсов из жизни "больших" проектов", Виталий Гаврилов (технический директор "Ленвендо")
Аннотация
Команда разработчиков «Ленвендо» реализовала сотни проектов, среди которых были сайты и интернет-магазины для компаний: Эльдорадо, Газпромбанк, Связной, SUP media, Эхо Москвы в Петербурге, Банк БФА и другие. Специалисты компании в совершенстве владеют языками программирования от низкоуровневого C++ до высокоуровневых PHP, Perl, Bash и умею разрабатывать проекты с многомиллионной посещаемостью.
В рамках презентации будет рассмотрено несколько интересных кейсов из практики «Ленвендо». Мы поговорим об особенностях построения высоконагруженных проектов с использованием БД PostgreSQL, о резервном копировании и особенностях его организации в высоконагруженных проектах с большими объемами данных. Также остановимся на специфике проектов, размещенных в 2-х и более датацентрах, и тех инструментах, которые мы используем для построения таких проектов (csync2, MySQL Multi-Master Replication и т.д.).
Особое внимание будет уделено теме управляемого статического кеширования, позволяющего существенно (от 30% до нескольких раз) снизить нагрузку на backend-сервера с сохранением актуальности отображаемой на сайте информации (с помощью RabbitMQ, RedisDB, Nginx embedded Perl).
И напоследок - короткое «лирическое» отступление о том, когда и для чего имеет смысл использовать СУБД Oracle.
О компании
Компания «Ленвендо» - профессионал в области разработки, внедрения и технической поддержки высоконагруженных Интернет-решений. Компания была признана одной из лидеров по разработке Highload-систем (рейтинг Best in Digital 2013).
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 и некоторых других местах.
PyCon Siberia 2016. Не доверяйте тестам!Ivan Tsyganov
Слайды с конференции PyCon Siberia 2016.
Каждый программист рано или поздно начинает писать тесты на свой код. В какой-то момент он начинает задумываться о том, насколько его тесты хороши. В своем докладе я расскажу о том, какие инструменты для проверки качества тестов существуют, как они работают и почему они обманывают нас.
Построение распределенной системы сбора данных с помощью RabbitMQ, Alvaro Vid...Ontico
This document discusses building a distributed data ingestion system using RabbitMQ. It introduces RabbitMQ as a multi-protocol, polyglot messaging broker. The document then outlines some issues with a naïve ad-hoc solution to distributing data and proposes using RabbitMQ federation to address these issues. It provides an overview of how RabbitMQ federation works and how to configure it. Finally, it discusses additional RabbitMQ features like sharded queues and federated queues that can help scale the system.
101 способ приготовления RabbitMQ и немного о pipeline архитектуре / Филонов ...Ontico
Архитектурный шаблон проектирования конвейер (pipeline) хорошо зарекомендовал себя при проектировании высоконагруженных (highload) систем. Использование шины сообщений (message bus) при реализации каналов взаимодействия позволяет достигать хороших показателей масштабируемости (scalability), но при этом появляются дополнительные накладные расходы, которые сказываются на показателях производительности (performance).
В докладе обсуждаются варианты использования системы обмена сообщениями RabbitMQ в качестве связующего программного обеспечения (middleware) для построения конвейерной архитектуры. Рассматриваются вопросы производительности и масштабирования как stateless так и statefull фильтров.
В качестве примера рассматривается реализация системы обработки сложных событий (complex event processing) применительно к управлению журналированием (log management).
Мы в Avito не так давно начали использовать Golang, но он уже успел занять важное место в различных частях проекта. В докладе мы расскажем о том, какие задачи нам помогает решать Go, почему выбор пал именно на этот язык, с какими подводными камнями мы столкнулись, и как их обходили. В частности поговорим про:
• Сервисы. Как мы начали использовать Go для разработки микросервисов, как это сказалось на их поддержке, а также отдельно расскажем про “шаблон сервиса”, который мы используем.
• Поиск. Как мы с помощью Go мы реализовали RtIndexer для обновления Sphinx Rt индексов в кластере из множества машин (поиск по активным объявлениям), который устойчиво работает с отставанием не более 10 секунд при нагрузке до 1000 rps.
• Автоматизацию тестирования. Как мы пишем тестовые сервисы и API на Go. Подробней остановимся на использовании общих моделей тел запросов и ответов для отправки и получения, использовании горутин как воркеров для обработки очереди.
«Как 200 строк на Go помогли нам освободить 15 серверов» – Паша Мурзаков (Badoo)AvitoTech
В Badoo я работаю в команде, которая разрабатывает на PHP. Одна из фич, которой мы занимаемся, со временем начала отъедать всё больше и больше железячных ресурсов. В итоге мы едва успевали добавлять серверы под растущую нагрузку. При этом вечера, проведённые с Go дома, подсказывали, что можно сделать на порядки производительнее, не затратив на разработку много времени.
Я расскажу о том, почему наша фича так плохо ложится на PHP и хорошо – на Go, как уговорить всех всё переписать и не показаться сумасшедшим, ну и, конечно же, как из 19 серверов оставить только 4.
«Миллион открытых каналов с данными по сети» – Илья Биин (Zenhotels)AvitoTech
Поговорим о том, почему это далеко не самая простая задача, и как следует разбираться с возникающими трудностями. Рассмотрим и покритикуем существующие решения. Научимся создавать свой собственный велосипед.
Миф об очень сложном 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, чем новое железо.
- Очень много очен�
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного se...Sergey Xek
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного server-side API десктопного приложения. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)Ontico
NodeJS — достаточно молодой фреймворк, и пока не каждый решается использовать его в продакшене, а тем более в highload.
В течение последнего года мы разрабатывали проект DMP (Data Management Platform), используя NodeJS для прототипирования. На данный момент проект в большей степени все еще остался на JS и без труда справляется с текущими нагрузками в 10 000 запросов в секунду.
В докладе я расскажу, почему остановились именно на NodeJS и совсем не жалеем об этом.
К сожалению, никакое дело не обходится без граблей и костылей. Я расскажу обо всех встретившихся проблемах и уделю особое внимание проблемам со спагетти-кодом, утечками и нехваткой памяти. Как мы убили немало времени, тщетно ища источник проблем, и какие правила мы составили для себя на будущее, чтобы не повторить своих ошибок.
Расскажу немного о применении микросервисов для решения проблемы спагетти-кода.
И, как итог, опишу ряд рекомендаций, которые помогут избежать большой траты времени при использовании NodeJS.
Badoo Desktop: оптимизация приложения на миллион юзеров онлайнSergey Xek
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Архитектура п...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Архитектура проекта на 30 млн. пользователей", Дмитрий Смирнов (ведущий разработчик Фотостраны).
Badoo Desktop: оптимизация приложения на миллион юзеров онлайнSergey Xek
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Прогрессивный рендеринг и Catberry.js / Михаил Реенко (2GIS / Flamp)Ontico
РИТ++ 2017, Frontend Сonf
Зал Мумбаи, 6 июня, 14:00
Тезисы:
http://frontendconf.ru/2017/abstracts/2471.html
Знаете ли вы, что такое прогрессивный рендеринг?
Почему вам стоит его использовать?
Какие есть варианты сегодня?
Презентация с технической секции #BitByte - фестиваля профессионального развития, который прошел 19 мая в Санкт-Петербурге.
Дмитрий Смирнов, Ведущий разработчик компании «Фотострана»: «30 млн. пользователей - как правильно строить архитектуру?»
Рельсы прекрасный инструмент, но в некоторых ситуациях они не справляются.
В этом докладе рассказывается о таких ситуациях и одном из вариантов решения
Similar to Оптимизация одного из топовых приложений для социальной сети ВКонтакте: 1000 запросов в секунду на Rails, Максим Лапшин (20)
Facebook has over 500 million active users, with half logging in every day. It processes over 4 trillion feed actions per day and caches over 2 trillion objects. Facebook has scaled to over 1 million active users per engineer, significantly more efficient than other large tech companies. To achieve this scale, Facebook relies on techniques like frequent small releases, dark launching of major changes, and shedding load during outages to maintain reliability as the site grows enormously.
Shared Personalization Service - How To Scale to 15K RPS, Patrice PellandFuenteovejuna
The document summarizes the Shared Personalization Service (SPS) developed by Microsoft to enable explicit and implicit personalization at scale. SPS uses AppFabric caching and SQL partitioning to support 150 million home page visits per month with peaks of 15,000 requests per second. It provides a stateless architecture with no single point of failure and aims for read latencies less than 25ms and update latencies less than 50ms. SPS deploys across multiple regions using caching, databases, and file servers for availability and scalability.
Social Monitoring Tool codename Looking Glass, Patrice PellandFuenteovejuna
The document discusses the progression of a social monitoring incubation project from a Windows Server backend to Windows Azure.
It began as a Silverlight application with code reuse across Windows Phone and iOS. The initial backend used Windows Server and SQL Server but struggled to scale.
It then moved to using Windows Azure web and worker roles with SQL Azure and Azure storage to improve scalability. This allowed for distributed data acquisition and indexing to handle larger datasets.
The final phase utilized multiple Azure services including data aggregators, indexers, blob storage and visualization to create a more scalable, reliable and complex social monitoring solution. Moving to Azure addressed the project's scalability issues in a cost effective way.
Real time indexes in Sphinx, Yaroslav VorozhkoFuenteovejuna
This presentation introduces Sphinx Search 1.10's new real-time indexes feature. It discusses the problems with plain indexes and how real-time indexes allow indexing and updating data on the fly directly from MySQL. Performance tests show real-time indexes using less disk space and performing better for single and multi-queries compared to plain indexes, especially under load. The presentation demonstrates easy creation and CRUD of real-time indexes and migration tools and strategies.