Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2914.html
Казалось бы, что нужно для организации тестового окружения? Тестовая железка и копия боевого окружения - и тестовый сервер готов. Но как быть, когда проект сложный? А когда большой? А если нужно тестировать одновременно много версий? А если все это вместе?
Организация тестирования большого развивающегося проекта, где одновременно в разработке и тестировании около полусотни фич - достаточно непростая задача. Ситуация обычно осложняется тем, что иногда есть желание потрогать еще не полностью готовый функционал. В таких ситуациях часто возникает вопрос: "А куда это можно накатить и где покликать?"
...
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2957.html
Расскажем о нашем опыте разработки модуля межсетевого экрана для MySQL с использованием генератора парсеров ANTLR и языка Kotlin.
Подробно рассмотрим следующие вопросы:
— когда и почему целесообразно использовать ANTLR;
— особенности разработки ANTLR-грамматики для MySQL;
— сравнение производительности рантаймов для ANTLR в рамках задачи синтаксического анализа MySQL (C#, Java, Kotlin, Go, Python, PyPy, C++);
— вспомогательные DSL;
— микросервисная архитектура модуля экранирования SQL;
— полученные результаты.
Банки.ру — проект с 10-летней историей. В разные времена мы испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас в среднем в день у нас примерно 2КК просмотра страниц, т.е. мы уже не маленькие, но ещё и не совсем большие.
Я хочу поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.
Посмотрим примеры и поищем ответы на вопросы:
1) Настолько ли ваш highload — highload?
2) Считать ли хабрэффект поводом для внедрения высоких технологий?
3) "Костыль" или "высокотехнологичное решение" — что выбрать? Плюсы и минусы.
4) Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки "по-взрослому".
5) Как можно использовать "список Бунина" для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
6) Как работать с тех. долгом, чтобы он не зарастал мхом?
В заключение я расскажу про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.
P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)
NoSQL — это слово громко "жужжит".
К сожалению, оно при этом ничего не означает. Это не продукт, не технология, и даже не концепция. Это даже не подход к проектированию. Это, скорее, декларация отказа от некоторых паттернов проектирования, господствовавших в разработке клиент-серверных систем долгие годы.
На этом доклад можно было бы и закончить. Если бы мы не знали достоверно, что на свете есть люди, которые умудряются извлекать прибыль, используя NoSQL в своих проектах. Ну или сокращать убытки, по крайней мере.
Попробуем еще раз.
NoSQL — это именно декларация отказа от некоторых паттернов.
- От чего именно придется отказаться? Упомянутые паттерны так живучи совсем не случайно.
- Как это ударит по проекту? Не сомневайтесь, оно ударит, в этом мире нет ни серебряных пуль, ни бесплатного сыра.
- Какими свойствами должен обладать проект, чтобы внедрение NoSQL СУБД принесло ему пользу? Избегать NoSQL — это не трусость, это осторожность.
- Каковы сильные стороны NoSQL СУБД, и в чем профит? Выбор NoSQL — это всегда выбор в пользу меньшего зла.
- Как выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES [currently >225], и даже просто прочесть его — тяжелая работа.
- Почему реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra? Да, это провокационный вопрос, но на него есть not-so-provocative ответ.
- С какими проблемами сталкиваются разработчики и администраторы при эксплуатации "тяжелой" NoSQL базы? К сожалению, большая часть этих проблем создается именно присутствием NoSQL.
- Что можно делать с NoSQL СУБД и чего нельзя? На какие параметры производительности и отказоустойчивости можно рассчитывать? В чем особенности выбора "железа" для NoSQL?
- И в чем, все-таки, profit?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
DevOps-трансформация Альфа-Банка / Антон Исанин (Альфа-Банк)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2907.html
Конкуренция в банковском сегменте усиливается с каждым годом, повышаются ставки и цели по прибыли компаний. При прочих равных выигрывает тот, кто может быстрее разрабатывать продукты и мгновенно реагировать на потребности рынка. Банки рассматривают DevOps-трансформацию как средство, которое позволит им кардинально повысить финансовую эффективность, качество финансовых продуктов и поможет услышать и быстро реагировать на клиента.
...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2914.html
Казалось бы, что нужно для организации тестового окружения? Тестовая железка и копия боевого окружения - и тестовый сервер готов. Но как быть, когда проект сложный? А когда большой? А если нужно тестировать одновременно много версий? А если все это вместе?
Организация тестирования большого развивающегося проекта, где одновременно в разработке и тестировании около полусотни фич - достаточно непростая задача. Ситуация обычно осложняется тем, что иногда есть желание потрогать еще не полностью готовый функционал. В таких ситуациях часто возникает вопрос: "А куда это можно накатить и где покликать?"
...
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2957.html
Расскажем о нашем опыте разработки модуля межсетевого экрана для MySQL с использованием генератора парсеров ANTLR и языка Kotlin.
Подробно рассмотрим следующие вопросы:
— когда и почему целесообразно использовать ANTLR;
— особенности разработки ANTLR-грамматики для MySQL;
— сравнение производительности рантаймов для ANTLR в рамках задачи синтаксического анализа MySQL (C#, Java, Kotlin, Go, Python, PyPy, C++);
— вспомогательные DSL;
— микросервисная архитектура модуля экранирования SQL;
— полученные результаты.
Банки.ру — проект с 10-летней историей. В разные времена мы испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас в среднем в день у нас примерно 2КК просмотра страниц, т.е. мы уже не маленькие, но ещё и не совсем большие.
Я хочу поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.
Посмотрим примеры и поищем ответы на вопросы:
1) Настолько ли ваш highload — highload?
2) Считать ли хабрэффект поводом для внедрения высоких технологий?
3) "Костыль" или "высокотехнологичное решение" — что выбрать? Плюсы и минусы.
4) Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки "по-взрослому".
5) Как можно использовать "список Бунина" для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
6) Как работать с тех. долгом, чтобы он не зарастал мхом?
В заключение я расскажу про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.
P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)
NoSQL — это слово громко "жужжит".
К сожалению, оно при этом ничего не означает. Это не продукт, не технология, и даже не концепция. Это даже не подход к проектированию. Это, скорее, декларация отказа от некоторых паттернов проектирования, господствовавших в разработке клиент-серверных систем долгие годы.
На этом доклад можно было бы и закончить. Если бы мы не знали достоверно, что на свете есть люди, которые умудряются извлекать прибыль, используя NoSQL в своих проектах. Ну или сокращать убытки, по крайней мере.
Попробуем еще раз.
NoSQL — это именно декларация отказа от некоторых паттернов.
- От чего именно придется отказаться? Упомянутые паттерны так живучи совсем не случайно.
- Как это ударит по проекту? Не сомневайтесь, оно ударит, в этом мире нет ни серебряных пуль, ни бесплатного сыра.
- Какими свойствами должен обладать проект, чтобы внедрение NoSQL СУБД принесло ему пользу? Избегать NoSQL — это не трусость, это осторожность.
- Каковы сильные стороны NoSQL СУБД, и в чем профит? Выбор NoSQL — это всегда выбор в пользу меньшего зла.
- Как выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES [currently >225], и даже просто прочесть его — тяжелая работа.
- Почему реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra? Да, это провокационный вопрос, но на него есть not-so-provocative ответ.
- С какими проблемами сталкиваются разработчики и администраторы при эксплуатации "тяжелой" NoSQL базы? К сожалению, большая часть этих проблем создается именно присутствием NoSQL.
- Что можно делать с NoSQL СУБД и чего нельзя? На какие параметры производительности и отказоустойчивости можно рассчитывать? В чем особенности выбора "железа" для NoSQL?
- И в чем, все-таки, profit?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
DevOps-трансформация Альфа-Банка / Антон Исанин (Альфа-Банк)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2907.html
Конкуренция в банковском сегменте усиливается с каждым годом, повышаются ставки и цели по прибыли компаний. При прочих равных выигрывает тот, кто может быстрее разрабатывать продукты и мгновенно реагировать на потребности рынка. Банки рассматривают DevOps-трансформацию как средство, которое позволит им кардинально повысить финансовую эффективность, качество финансовых продуктов и поможет услышать и быстро реагировать на клиента.
...
Эволюция процесса деплоя в проекте — Денис Яковлев, 2ГИС2ГИС Технологии
Если наш проект это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готово кода в боевое окружение. В самом начале, когда наш проект маленький и простой на эту задачу никто может и не обращать внимание, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов - git pull, yii migrate, etc...которые легко запомнить и в которых сложно ошибиться.
С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилититы, библиотеки и т.д.), новые сущности (балансеры, кешы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем чем решений, люди ошибаются чаще и т.д.
В докладе:
— Рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты.
— Обсудим какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, в чем их задача и какое решение выбрать;
— Поговорим про административные вопросы, которые с этим связаны.
Организация надежного резервного копирования веб-проекта. Практика и подводны...Anton Baranov
1. Общая информация
- Что именно нужно бэкапить?
- Типы бэкапов. Плюсы и минусы.
- Периодичность создания.
- Выбор хранилища.
2. Бэкапы БД и файлов
- Обзор инструментов.
- Источники данных для бэкапов.
- Неочевидные особенности создания/восстановления.
3. Проблемы организации резервного копирования
- Актуальность данных.
- Скорость восстановления.
- Надежность создания резервных копий.
4. Верификация бэкапов
- Тестовый стенд.
- Мониторинг процесса.
- Ручные проверки.
Миф об очень сложном 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, чем новое железо.
- Очень много очен�
Javascript-фреймворки: должен остаться только одинSergey Xek
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
LuaJIT как основа для сервера приложений - проблемы и решения / Игорь Эрлих (...Ontico
С того момента, как было принято решение использовать язык Lua в качестве языка описания бизнес-логики в нашей платформе, прошло уже больше восьми лет. Проекты росли, данных становилось больше, возрастала нагрузка на сервера приложений. Со временем у нас накопился солидный багаж знаний о том, как устроен LuaJIT, с какими проблемами можно столкнуться при его использовании и как эти проблемы можно решать.
Я расскажу про то...
* Почему при миграции с x86 на x64 доступной памяти в LuaJIT становится меньше, и как мы с этим боролись.
* Как загрузить в LuaJIT несколько миллионов объектов и не умереть в тормозах от сборщика мусора.
* Насколько ужасна встроенная функция хеширования строк и почему иногда надо жертвовать производительностью в пользу качества.
Доклад с PUG#4 https://www.facebook.com/events/350783888446030/
Рассмотрим:
- Что такое Highload, термины, инструменты.
- Где тормозит PHP, родовые травмы языка, как с ними жить.
- Скорость работы vs скорость разработки.
- Архитектура, что стоит делать и когда.
C++ CoreHard Autumn 2018. Ускорение сборки C++ проектов, способы и последстви...corehard_by
В докладе обсуждаются способы улучшения времени сборки C++ проектов, опыт полученный в ходе ускорения сборки клиента и тулов World Of Tanks. Также описывается эффект, который они оказывают на организацию кодобазы (как позитивный, так и негативный) и затраты, которые необходимы для поддержки этих решений, т.к. не все они бесплатны. Методики, описываемые в докладе: ускорение линковки (Incremental Linking, Fastlink), ускорение компиляции(Include what you use, использование precompiled headers).
Доклад с PUG#2 https://www.facebook.com/events/292457000957088/
Доклад о работе в Shell, исполнении PHP в Shell, использовании REPL в PHP, а также эпический батл между Boris и PsySH.
PHP User Group Ukraine в социальных сетях:
https://www.facebook.com/pug.ukraine
https://vk.com/pug.ukraine
https://www.linkedin.com/groups/PHP-User-Group-Ukraine-6703717
Лучшие практики CI/CD с Kubernetes и GitLab / Дмитрий Столяров (Флант)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3073.html
Весь этот год мы в компании «Флант» активно переводили на Kubernetes проекты заказчиков, сильно различающихся как по масштабам, так и по технологиям. На данный момент (сентябрь 2017) у нас в Kubernetes (в production) функционируют 13 проектов, в состав которых входят более 130 различных приложений, написанных на 8 языках программирования: .NET, Erlang, Go, Java, Node.js, PHP, Python и Ruby. В этих проектах задействовано множество инфраструктурных компонентов, таких как Cassandra, Ceph, Firebird, Memcached, MongoDB, MySQL, NATS.io, NGINX, PostgreSQL, RabbitMQ, Redis, RethinkDB, Sphinx, SQLite и других. Мы поделимся обширным опытом, полученным в результате выстраивания CI/CD для таких приложений.
...
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...Ontico
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
4 года разрабатывает видеостриминговый сервер эрливидео и в этом докладе расскажет о некоторых отличительных возможностях Erlang, которые позволяют быстро развиваться и поддерживать высочайшее качество ПО минимальными усилиями.
Badoo Desktop: оптимизация приложения на миллион юзеров онлайнSergey Xek
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Мы в Avito не так давно начали использовать Golang, но он уже успел занять важное место в различных частях проекта. В докладе мы расскажем о том, какие задачи нам помогает решать Go, почему выбор пал именно на этот язык, с какими подводными камнями мы столкнулись, и как их обходили. В частности поговорим про:
• Сервисы. Как мы начали использовать Go для разработки микросервисов, как это сказалось на их поддержке, а также отдельно расскажем про “шаблон сервиса”, который мы используем.
• Поиск. Как мы с помощью Go мы реализовали RtIndexer для обновления Sphinx Rt индексов в кластере из множества машин (поиск по активным объявлениям), который устойчиво работает с отставанием не более 10 секунд при нагрузке до 1000 rps.
• Автоматизацию тестирования. Как мы пишем тестовые сервисы и API на Go. Подробней остановимся на использовании общих моделей тел запросов и ответов для отправки и получения, использовании горутин как воркеров для обработки очереди.
SECON'2016. Тюменцев Евгений, Разработка надежных параллельных, распределенны...SECON
Набор практических приемов, которые позволяют создавать сложные многопоточные, параллельные, распределенные серверные приложения программистам без опыта сетевого и многопоточного программирования, работы с базами данных.
Вадим Мадисон "Опыт разработки через микросервисы"Tanya Denisyuk
Мы начали разработку через микросервисы когда это еще не было трендом, было не ясно - это реально работающий подход или просто очередная модная штука. Не было понимания как это делать правильно, где подводные камни и что за одним словом “микросервисы” по факту стоит куча всего, что придется узнать, изучить и понять.
Сейчас у нас большой парк микросервисов, но оперировать ими становится все проще - сказывается опыт.
В ходе доклада я поделюсь основными моментами в разработке микросервисов, расскажу как это делаем мы и что для этого используем.
Эволюция процесса деплоя в проекте — Денис Яковлев, 2ГИС2ГИС Технологии
Если наш проект это не коробочный продукт, а, например, веб-сервис, на который постоянно ходят пользователи, их много и они сразу видят изменения, то в жизненном цикле разработки у нас возникает еще одна задача — задача деплоя готово кода в боевое окружение. В самом начале, когда наш проект маленький и простой на эту задачу никто может и не обращать внимание, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов - git pull, yii migrate, etc...которые легко запомнить и в которых сложно ошибиться.
С развитием проекта его сложность возрастает — он уже крутится на нескольких серверах, появляются новые компоненты (утилититы, библиотеки и т.д.), новые сущности (балансеры, кешы, и т.д.). Держать всю инфраструктуру в голове становится невозможным, ведение документации привносит больше проблем чем решений, люди ошибаются чаще и т.д.
В докладе:
— Рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты.
— Обсудим какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, в чем их задача и какое решение выбрать;
— Поговорим про административные вопросы, которые с этим связаны.
Организация надежного резервного копирования веб-проекта. Практика и подводны...Anton Baranov
1. Общая информация
- Что именно нужно бэкапить?
- Типы бэкапов. Плюсы и минусы.
- Периодичность создания.
- Выбор хранилища.
2. Бэкапы БД и файлов
- Обзор инструментов.
- Источники данных для бэкапов.
- Неочевидные особенности создания/восстановления.
3. Проблемы организации резервного копирования
- Актуальность данных.
- Скорость восстановления.
- Надежность создания резервных копий.
4. Верификация бэкапов
- Тестовый стенд.
- Мониторинг процесса.
- Ручные проверки.
Миф об очень сложном 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, чем новое железо.
- Очень много очен�
Javascript-фреймворки: должен остаться только одинSergey Xek
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
LuaJIT как основа для сервера приложений - проблемы и решения / Игорь Эрлих (...Ontico
С того момента, как было принято решение использовать язык Lua в качестве языка описания бизнес-логики в нашей платформе, прошло уже больше восьми лет. Проекты росли, данных становилось больше, возрастала нагрузка на сервера приложений. Со временем у нас накопился солидный багаж знаний о том, как устроен LuaJIT, с какими проблемами можно столкнуться при его использовании и как эти проблемы можно решать.
Я расскажу про то...
* Почему при миграции с x86 на x64 доступной памяти в LuaJIT становится меньше, и как мы с этим боролись.
* Как загрузить в LuaJIT несколько миллионов объектов и не умереть в тормозах от сборщика мусора.
* Насколько ужасна встроенная функция хеширования строк и почему иногда надо жертвовать производительностью в пользу качества.
Доклад с PUG#4 https://www.facebook.com/events/350783888446030/
Рассмотрим:
- Что такое Highload, термины, инструменты.
- Где тормозит PHP, родовые травмы языка, как с ними жить.
- Скорость работы vs скорость разработки.
- Архитектура, что стоит делать и когда.
C++ CoreHard Autumn 2018. Ускорение сборки C++ проектов, способы и последстви...corehard_by
В докладе обсуждаются способы улучшения времени сборки C++ проектов, опыт полученный в ходе ускорения сборки клиента и тулов World Of Tanks. Также описывается эффект, который они оказывают на организацию кодобазы (как позитивный, так и негативный) и затраты, которые необходимы для поддержки этих решений, т.к. не все они бесплатны. Методики, описываемые в докладе: ускорение линковки (Incremental Linking, Fastlink), ускорение компиляции(Include what you use, использование precompiled headers).
Доклад с PUG#2 https://www.facebook.com/events/292457000957088/
Доклад о работе в Shell, исполнении PHP в Shell, использовании REPL в PHP, а также эпический батл между Boris и PsySH.
PHP User Group Ukraine в социальных сетях:
https://www.facebook.com/pug.ukraine
https://vk.com/pug.ukraine
https://www.linkedin.com/groups/PHP-User-Group-Ukraine-6703717
Лучшие практики CI/CD с Kubernetes и GitLab / Дмитрий Столяров (Флант)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3073.html
Весь этот год мы в компании «Флант» активно переводили на Kubernetes проекты заказчиков, сильно различающихся как по масштабам, так и по технологиям. На данный момент (сентябрь 2017) у нас в Kubernetes (в production) функционируют 13 проектов, в состав которых входят более 130 различных приложений, написанных на 8 языках программирования: .NET, Erlang, Go, Java, Node.js, PHP, Python и Ruby. В этих проектах задействовано множество инфраструктурных компонентов, таких как Cassandra, Ceph, Firebird, Memcached, MongoDB, MySQL, NATS.io, NGINX, PostgreSQL, RabbitMQ, Redis, RethinkDB, Sphinx, SQLite и других. Мы поделимся обширным опытом, полученным в результате выстраивания CI/CD для таких приложений.
...
Преждевременная оптимизация архитектуры / Евгений Потапов, Антон Баранов (ITS...Ontico
Работа в высоконагруженных проектах всегда была такой сферой деятельности, где можно в рамках решения прикладных задач находить и применять сложные и интересные решения.
К сожалению, очень часто во главу угла ставится не надежное решение поставленной задачи, а именно применение сложного и интересного решения, которое даст специалисту новый опыт и удовольствие от сложных архитектур.
В своем докладе я хочу пройтись по тем стандартным "набитым шишкам", которые мы встречаем в своей работе, когда сложное, новое и интересное решение не означает стабильность системы.
1. Когда "интересно" не значит "правильно"?
1.1. Специфика развития высоконагруженного проекта.
1.2. Требования бизнеса и современные технологии.
1.3. Типичные "сомнительные" решения.
2. Проблемы в архитектуре отказоустойчивых систем.
2.1. Ошибки в планировании резервирования.
2.2. Ошибки в планировании системы выкладок.
2.3. Ошибки в архитектурах систем хранения данных.
3. Проблемы в архитектуре систем, рассчитанных на высокую нагрузку.
3.1. Ошибки в планировании мощностей системы.
3.2. Ошибки в планировании возможностей масштабирования системы.
3.3. Ошибки в архитектурах систем хранения данных.
4 года разрабатывает видеостриминговый сервер эрливидео и в этом докладе расскажет о некоторых отличительных возможностях Erlang, которые позволяют быстро развиваться и поддерживать высочайшее качество ПО минимальными усилиями.
Badoo Desktop: оптимизация приложения на миллион юзеров онлайнSergey Xek
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Мы в Avito не так давно начали использовать Golang, но он уже успел занять важное место в различных частях проекта. В докладе мы расскажем о том, какие задачи нам помогает решать Go, почему выбор пал именно на этот язык, с какими подводными камнями мы столкнулись, и как их обходили. В частности поговорим про:
• Сервисы. Как мы начали использовать Go для разработки микросервисов, как это сказалось на их поддержке, а также отдельно расскажем про “шаблон сервиса”, который мы используем.
• Поиск. Как мы с помощью Go мы реализовали RtIndexer для обновления Sphinx Rt индексов в кластере из множества машин (поиск по активным объявлениям), который устойчиво работает с отставанием не более 10 секунд при нагрузке до 1000 rps.
• Автоматизацию тестирования. Как мы пишем тестовые сервисы и API на Go. Подробней остановимся на использовании общих моделей тел запросов и ответов для отправки и получения, использовании горутин как воркеров для обработки очереди.
SECON'2016. Тюменцев Евгений, Разработка надежных параллельных, распределенны...SECON
Набор практических приемов, которые позволяют создавать сложные многопоточные, параллельные, распределенные серверные приложения программистам без опыта сетевого и многопоточного программирования, работы с базами данных.
Вадим Мадисон "Опыт разработки через микросервисы"Tanya Denisyuk
Мы начали разработку через микросервисы когда это еще не было трендом, было не ясно - это реально работающий подход или просто очередная модная штука. Не было понимания как это делать правильно, где подводные камни и что за одним словом “микросервисы” по факту стоит куча всего, что придется узнать, изучить и понять.
Сейчас у нас большой парк микросервисов, но оперировать ими становится все проще - сказывается опыт.
В ходе доклада я поделюсь основными моментами в разработке микросервисов, расскажу как это делаем мы и что для этого используем.
Видео: http://www.youtube.com/watch?v=vz0U3jQpHSM
Это обзор опыта применения лучших практик разработки программного обеспечения на разных проектах от госзаказов до видеоконференций в командах от 5 до 50 человек. В докладе будут описаны не только практики, но и то, как они применяются на реальных проектах и какие выгоды они действительно приносят.
Типовая сборка и деплой продуктов в Positive TechnologiesPositive Hack Days
1. Проблемы в построении CI процессов в компании
2. Структура типовой сборки
3. Пример реализации типовой сборки
4. Плюсы и минусы от использования типовой сборки
Переход с Objective-C на Swift — все ли так просто? / Олег Алексеенко (SuperJob)Ontico
РИТ++ 2017, App's Conf
Зал Найроби, 6 июня, 10:00
Тезисы:
http://appsconf.ru/2017/abstracts/2818.html
Ни для кого не секрет, что Swift — это mainstream: его активно продвигает Apple, на нем пишутся все новые фреймворки, многие разработчики начинают именно с него. Но так ли просто мигрировать c Objective-С, если твоему приложению 5 лет и оно имеет большую аудиторию? В докладе мы расскажем о том, как сделать это без ущерба для бизнеса.
Вы узнаете об этапах такого перехода:
1. Какую бизнес-проблему решали? - Ускоряем разработку, уменьшаем количество багов, проще и быстрее находим новых сотрудников, ограждаем от будущих рисков (старых не поддерживаемых фреймворков, устаревших АПИ).
...
SECON'2016. Парамонов Сергей, Автоматизируй это! Как не погрязнуть в рутине п...SECON
В разработке игр существует множество сопутствующих проблем, которые приходиться решать разработчику, но которые напрямую не связаны с игровым процессом. Автоматизация рутинных задач - лучшее решение, позволяющее сэкономить время для воплощения творческого замысла в условиях компактных команд и компаний.
Вместе с Алексеем Ашурком мы расскажем о том, как проект «Фламп» релизится по 2n раз в неделю и комфортно себя при этом чувствует:
— Ветки - это хорошо или о переходе с SVN на Git.
— Чем плоха «классическая» модель релизов.
— Что такое модель пофичных релизов, в чём её плюсы и минусы.
— Почему она подходит для веб-сервисов.
— Как идти в ногу со временем или частые деплои.
— Как ловить ошибки и минимизировать их число.
Видео доклада: http://devday.2gis.ru/report/15
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...Ontico
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
См. тезисы - http://rootconf.ru/2015/abstracts/1746
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...Anton Baranov
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
Прежде всего, мы постараемся сделать доклад не сравнением feature-листов, а рассмотреть особенности практического применения разных систем для конкретной задачи - для сайта, который не должен падать (а точнее - для возможности оперативно отреагировать на аварию, понять что к ней привело, и как можно ее исправить).
Организация надежного резервного копирования веб-проекта. Практика и подводны...Ontico
1. Общая информация
- Что именно нужно бэкапить?
- Типы бэкапов. Плюсы и минусы.
- Периодичность создания.
- Выбор хранилища.
2. Бэкапы БД и файлов
- Обзор инструментов.
- Источники данных для бэкапов.
- Неочевидные особенности создания/восстановления.
3. Проблемы организации резервного копирования
- Актуальность данных.
- Скорость восстановления.
- Надежность создания резервных копий.
4. Верификация бэкапов
- Тестовый стенд.
- Мониторинг процесса.
- Ручные проверки.
"How to build powerful CI / CD based on GitLab and Docker", Aleksandr Matkovs...Provectus
Aleksandr Matkovskiy – Head of IT Department lives and works with the motto "Scaling and load balancing is our all!". Therefore, he has 3 sons and dreams to find DEV for his OPS.
You will be able to see how the CI / CD was created and saved our lives. From concept to the final product.
Vladislav Anikin – Team Leader & Software Architect, specializing in SAAS flexible and scalable solutions for business. Driving DDD/TDD oriented squad of awesome SOLID developers.
You will be able to see how the CI / CD was created and saved our lives. From concept to the final product.
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2964.html
Одноклассники состоят из более чем восьми тысяч железных серверов, расположенных в нескольких дата-центрах. Каждая из этих машин была специализированной под конкретную задачу - как для обеспечения изоляции отказов, так и для обеспечения автоматизированного управления инфраструктурой.
...
Масштабируя DNS / Артем Гавриченков (Qrator Labs)Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/3032.html
Протокол DNS на семь лет старше, чем Всемирная паутина. Стандарты RFC 882 и 883, определяющие основную функциональность системы доменных имён, появились в конце 1983 года, а первая реализация последовала уже годом позже. Естественно, что у технологии столь старой и при этом по сей день активнейшим образом используемой просто не могли не накопиться особенности, неочевидные обыкновенным пользователям.
...
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/3010.html
В этом докладе я расскажу, как BigData-платформа помогает трансформировать Почту России, как мы управляем построением и развитием платформы. Расскажу про найденные удачные решения, например, как разбиение на продукты с понятными SLA и интерфейсами между ними помогло нам сохранять управляемость с ростом масштабов проекта.
...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2854.html
Из этого доклада вы узнаете о возможностях репликации и автофейловера PostgreSQL, в том числе о возможностях, ставших доступных в PostgreSQL 10.
Среди прочих, будет затронуты следующие темы:
* Виды репликации и решаемые с ее помощью проблемы.
* Настройка потоковой репликации.
* Настройка логической репликации.
* Настройка автофейловера / HA средствами Stolon и Consul.
После прослушивания доклада вы сможете самостоятельно настраивать репликацию и автофейловер PostgreSQL.
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/3096.html
PostgreSQL is the world’s most advanced open source database. Indeed! With around 270 configuration parameters in postgresql.conf, plus all the knobs in pg_hba.conf, it is definitely ADVANCED!
How many parameters do you tune? 1? 8? 32? Anyone ever tuned more than 64?
No tuning means below par performance. But how to start? Which parameters to tune? What are the appropriate values? Is there a tool --not just an editor like vim or emacs-- to help users manage the 700-line postgresql.conf file?
Join this talk to understand the performance advantages of appropriately tuning your postgresql.conf file, showcase a new free tool to make PostgreSQL configuration possible for HUMANS, and learn the best practices for tuning several relevant postgresql.conf parameters.
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/3115.html
During this session we will cover the last development in ProxySQL to support regular expressions (RE2 and PCRE) and how we can use this strong technique in correlation with ProxySQL's query rules to anonymize live data quickly and transparently. We will explain the mechanism and how to generate these rules quickly. We show live demo with all challenges we got from the Community and we finish the session by an interactive brainstorm testing queries from the audience.
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3114.html
ProxySQL aims to be the most powerful proxy in the MySQL ecosystem. It is protocol-aware and able to provide high availability (HA) and high performance with no changes in the application, using several built-in features and integration with clustering software. During this session we will quickly introduce its main features, so to better understand how it works. We will then describe multiple use case scenarios in which ProxySQL empowers large MySQL installations to provide HA with zero downtime, read/write split, query rewrite, sharding, query caching, and multiplexing using SSL across data centers.
MySQL Replication — Advanced Features / Петр Зайцев (Percona)Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2954.html
MySQL Replication is powerful and has added a lot of advanced features through the years. In this presentation we will look into replication technology in MySQL 5.7 and variants focusing on advanced features, what do they mean, when to use them and when not, Including.
When should you use STATEMENT, ROW or MIXED binary log format?
What is GTID in MySQL and MariaDB and why do you want to use them?
What is semi-sync replication and how is it different from lossless semi-sync?
...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3120.html
Количество разработчиков мобильных приложений Сбербанк Онлайн с начала 2016 года выросло на порядок. Для того чтобы продолжать выпускать качественный продукт, мы кардинально перестраиваем процесс разработки.
Количество внутренних заказчиков тех или иных доработок в какой-то момент выросло настолько, что разработчики стали узким местом. Мы внедрили культуру разработки, которую можно условно назвать "внутренним open-source", сохранив за собой контроль над архитектурой и качеством проекта, но позволив разрабатывать новые фичи всем желающим.
...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2836.html
При использовании Eventually Consistent распределенных баз данных нет гарантий, что чтение возвращает результаты последних изменений данных, если чтение и запись производятся на разных узлах. Это ограничивает пропускную способность системы. Поддержка свойства Causal Consistency снимает это ограничение, что позволяет улучшить масштабируемость, не требуя изменений в коде приложения.
...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/2858.html
Аудитория Одноклассников превышает 73 миллиона человек в России, СНГ и странах дальнего зарубежья. При этом ОК.ru - первая социальная сеть по просмотрам видео в рунете и крупнейшая сервисная платформа.
Качественный и количественный рост DDoS-атак за последние годы превращает их в одну из первоочередных проблем для крупнейших интернет-ресурсов. В зависимости от вектора атаки “узким” местом становится та или иная часть инфраструктуры. В частности, при SYN-flood первый удар приходится на систему балансировки трафика. От ее производительности зависит успех в противостоянии атаке.
...
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/3008.html
Никогда не было и вот снова случилось! Компания Google в результате перенаправления трафика сделала недостпуными в Японии несколько тысяч различных сервисов, большинство из которых никак не связано с самой компанией Google. Однако, подобные инциденты происходят с завидной регулярностью, вот только не всегда попадают в большие СМИ. У таких инцидентов могут быть разные причины, начиная от ошибок сетевых инженеров и заканчивая государственным регулированием.
...
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2925.html
Облака и виртуализация – современные тренды развития IT-технологий. Операторы связи строят свои TelcoClouds на стандартах NFV (Network Functions Virtualization) и SDN (Software-Defined Networking). В докладе начнем с основ виртуализации, далее разберемся, для чего используются NFV и SDN, потом полетим к облакам и вернемся на землю для решения практических задач!
...
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)Ontico
HighLoad++ 2017
Зал «Мумбай», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/3045.html
Как мы заставили Druid работать в Одноклассниках.
«Druid is a high-performance, column-oriented, distributed data store» http://druid.io.
Мы расскажем о том, как, внедрив Druid, мы справились с ситуацией, когда MSSQL-based система статистики на 50 терабайт стала:
- медленной: средняя скорость ответа была в разы меньше требуемой (и увеличилась в 20 раз);
- нестабильной: в час пик статистика отставала до получаса (теперь ничего не отстает);
- дорогой: изменилась политика лицензирования Microsoft, расходы на лицензии могли составить миллионы долларов.
...
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2905.html
Прошло более года с того момента, как Microsoft выпустила первую версию своего нового фреймворка для разработки web-приложений ASP.NET Core, и с каждым днем он находит все больше поклонников. ASP.NET Core базируется на платформе .NET Core, кроссплатформенной версии платформы .NET c открытым исходным кодом. Теперь у С#-разработчиков появилась возможность использовать Mac в качестве среды разработки, и запускать приложения на Linux или внутри Docker-контейнеров.
...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2913.html
Изначально будут раскрыты базовые причины, которые заставили появиться такой части механизма СУБД, как кэш результатов, и почему в ряде СУБД он есть или отсутствует.
Будут рассмотрены различные варианты кэширования результатов как sql-запросов, так и результатов хранимой в БД бизнес-логики. Произведено сравнение способов кэширования (программируемые вручную кэши, стандартный функционал) и даны рекомендации, когда и в каких случаях данные способы оптимальны, а порой опасны.
...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2947.html
Apache Ignite — Open Source платформа для высокопроизводительной распределенной работы с большими данными с применением SQL или Java/.NET/C++ API. Ignite используют в самых разных отраслях. Сбербанк, ING, RingCentral, Microsoft, e-Therapeutics — все эти компании применяют решения на основе Ignite. Размеры кластеров разнятся от всего одного узла до нескольких сотен, узлы могут быть расположены в одном ЦОД-е или в нескольких геораспределенных.
...
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3005.html
Когда мы говорим о нагруженных системах и базах данных с большим числом параллельных коннектов, особый интерес представляет практика эксплуатации и сопровождения таких проектов. В том числе инструменты и механизмы СУБД, которые могут быть использованы DBA и DevOps-инженерами для решения задач мониторинга жизнедеятельности базы данных и ранней диагностики возможных проблем.
...
Как мы учились чинить самолеты в воздухе / Евгений Коломеец (Virtuozzo)Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 10:00
Тезисы:
http://www.highload.ru/2017/abstracts/2975.html
Все мы слышали про изменение кода ядра Linux на лету (kernel live patching). Но кто-нибудь проводит подобные фокусы в user space? Оказалось, что да. Мы тоже попробовали.
И получилось.
Длинная дорога технологии Userspace Live Patching в жизнь:
Что такое Live Patching
1) Изменение части логики процесса.
2) Сохранение состояния процесса.
3) Делать 1+2 БЕЗОПАСНО.
...
Java и Linux — особенности эксплуатации / Алексей Рагозин (Дойче Банк)Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 11:00
Тезисы:
http://www.highload.ru/2017/abstracts/2884.html
Java на Linux встречается повсеместно в информационных системах от больших данных до новомодных serverless архитектур. Как Linux, так и Java имеют свои эксплуатационные нюансы. Понимание этих нюансов важно, чтобы заставить стек Java + Linux работать стабильно и эффективно.
Но на практике "джависты" очень любят мыслить кроссплатформенно и не хотят разбираться с особенностями операционной системы, a "линускоиды" считают JVM чуждым миру Linux процессом, пожирающим всю доступную на сервере память.
А потом появляется Docker, и нюансов становится ещё больше...
Цель доклада - рассказать "джавистам" про Linux и Docker, а "линуксоидам" про JVM.
Java и Linux — особенности эксплуатации / Алексей Рагозин (Дойче Банк)
Цикл разработки и внедрения функционала в Мамбе (Михаил Буйлов)
1. Цикл
разработки
и
внедрения
функционала
в
Мамбе
Михаил
Буйлов
«Мамба»
2. О
чем
доклад?
• Основа
разработки
–
система
контроля
версий
• Автоматизированная
система
деплоя
с
веб
интерфейсом
• Проблемы
непосредственно
деплоя
кода
• Как
мы
понимаем,
что
все
хорошо
9. Проблемы
деплоя
при
разработки
в
транке
• Его
нельзя
раскладывать
целиком.
Только
отдельные
файлы.
10. Проблемы
деплоя
при
разработки
в
транке
• Его
нельзя
раскладывать
целиком.
Только
отдельные
файлы.
• Деплой
нужно
производить
так
часто
как
это
возможно
11. Проблемы
деплоя
при
разработки
в
транке
• Его
нельзя
раскладывать
целиком.
Только
отдельные
файлы.
• Деплой
нужно
производить
так
часто
как
это
возможно
• Нет
возможности
сегментировать
билд
17. Решение
всех
проблем:
переход
на
гит
• Сильно
проще
работать
с
ветками.
• Стабильный
мастер
позволит
делать
теги
для
аварийного
отката
18. Решение
всех
проблем:
переход
на
гит
• Сильно
проще
работать
с
ветками.
• Стабильный
мастер
позволит
делать
теги
для
аварийного
отката
• Заявка
на
деплой
–
ветка
в
репозитории
28. Система
перевода
• Меташаблоны
– Blitz
– Вызовы
из
пхп
кода
из
шаблонов
– Вызовы
как
маркеры
фраз
29. Система
перевода
• Меташаблоны
– Blitz
– Вызовы
из
пхп
кода
из
шаблонов
– Вызовы
как
маркеры
фраз
• Копия
шаблонов
для
каждого
языка
30. Система
перевода
• Меташаблоны
– Blitz
– Вызовы
из
пхп
кода
из
шаблонов
– Вызовы
как
маркеры
фраз
• Копия
шаблонов
для
каждого
языка
• Визуальный
перевод
45. После
деплоя.
Демон
агрегации
статистики
• BTP:
Демон
сбора
статистики
46. После
деплоя.
Демон
агрегации
статистики
• BTP:
Демон
сбора
статистики
• Большое
количество
счетчиков
и
таймеров
разного
уровня.
47. После
деплоя.
Демон
агрегации
статистики
• BTP:
Демон
сбора
статистики
• Большое
количество
счетчиков
и
таймеров
разного
уровня.
• Циклическая
база
для
хранения
значений
до
года
48. После
деплоя.
Демон
агрегации
статистики
• BTP:
Демон
сбора
статистики
• Большое
количество
счетчиков
и
таймеров
разного
уровня.
• Циклическая
база
для
хранения
значений
до
года
• Обновляется
в
реальном
времени
52. О
чем
же
был
доклад?
• Git
быстрее
svn
из-‐за
локальных
операций
• Визуальным
деплоем
пользуются
даже
менеджеры
• Деплой:
переключение
document
root
• Для
мониторинга
мы
написали
сервер
статистики
и
он
open
source
53. BTP
можно
найти
на
github
• h€ps://github.com/mambaru/btp-‐daemon
Демон
• h€ps://github.com/mambaru/btp-‐webui
Web
интерфейс
• h€ps://github.com/mambaru/btp-‐api
Api
для
PHP
54. Вопросы?
Михаил
Буйлов,
«Мамба»
buylov@mamba.ru
github.com/mambaru
