Golang в действии: Как нам удается писать highload приложение на (не?)подходя...Daniel Podolsky
Последние 2 года язык Go является моим - нашим - основным средством заработка на хлеб. Хватает, в общем-то, и на хлеб, и на масло, а иногда и на красную икру.
Не покривив душой, я могу сказать, что мы относимся к языку Go и его создателям с симпатией и уважением.
Однако, при всем нашем уважении, заявить, что Go предназначен для "тяжелых" проектов, я, не покривив душой, не могу.
Во-первых, Go молодой язык, для которого еще не известны паттерны и - что важнее - антипаттерны. Тем, кто пишет на Go тяжелое приложение сегодня, приходится тратить существенное время на тесты и оптимизации
Во-вторых, выразительные средства Go довольно скудны, что приводит к появлению в коде ужасающего количества boilerplate, за которым эффективно прячется бизнес-логика. Программу на Go бывает трудно охватить взглядом и поместить ее модель себе в голову просто из-за количества строк, которые надо для этого прочесть.
В-третьих, у Go есть проблемы с эффективностью кода. У Go плохой оптимизатор. У Go плохо с "заточкой" под железо - вспомним хотя бы историю с патчем CloudFlare для TLS. Патч ведь так и не попал в основную ветку...
Возникает вопрос - почему же, не по наслышке зная о вышеперечисленных проблемах, мы пишем наш реально тяжелый проект именно на Go?
Ответ прост: Go не идеален, но под наши задачи он подходит лучше всего.
Раньше мы строили разные тяжелые бекенды на perl, python, java, groovy и даже lua+nginx. Нам есть, с чем сравнивать.
Во-первых, Go достаточно быстр. Во всяком случае, он быстрее perl и python на нашем профиле нагрузки.
Во-вторых, и это важнее, Go предоставляет вполне достаточные средства контроля за потреблением как RAM, так и CPU. Например, регулярные выражения Go не такие гибкие, как pcre, и, по моим наблюдениям, медленнее, чем pcre. Но! регулярные выражения в Go всегда отрабатывают за предсказуемое время!
В-третьих, создатели языка не врут нам - они, действительно, постарались сделать язык, на котором человекочитаемую программу написать проще, чем нечитаемую. И у них - с некоторомы оговорками - получилось! Даже пресловутый boilerplate не способен этому помешать.
Наконец, Go просто сумел нам понравиться, чего уже давно не случалось с языками программирования.
Итак, на основании опыта, полученного при создании пилотной версии проекта inCaller.org я расскажу о том, как мы писали на Go тяжелое приложение.
Миллионы одновременных персистентных websocket соединений, десятки тысяч коннектов по ssl в секунду, сотни тысяч в секунду обновлений записей в БД.
Я расскажу об антипаттернах, нами обнаруженных, о методике тестирования производительности, анализа проблем и способах с проблемами справиться.
Доклад рассчитан на backend-программистов, как на языке Go, так и на других.
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
RTB DSP на языке Go укрощение buzzwords / Даниил Подольский (Qmobi.Com)Ontico
RTB и его проблематика должны быть знакомы участникам конференции — мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие — нет, будет рассказано в докладе.
Банки.ру — проект с 10-летней историей. В разные времена мы испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас в среднем в день у нас примерно 2КК просмотра страниц, т.е. мы уже не маленькие, но ещё и не совсем большие.
Я хочу поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.
Посмотрим примеры и поищем ответы на вопросы:
1) Настолько ли ваш highload — highload?
2) Считать ли хабрэффект поводом для внедрения высоких технологий?
3) "Костыль" или "высокотехнологичное решение" — что выбрать? Плюсы и минусы.
4) Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки "по-взрослому".
5) Как можно использовать "список Бунина" для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
6) Как работать с тех. долгом, чтобы он не зарастал мхом?
В заключение я расскажу про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.
P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)
Golang в действии: Как нам удается писать highload приложение на (не?)подходя...Daniel Podolsky
Последние 2 года язык Go является моим - нашим - основным средством заработка на хлеб. Хватает, в общем-то, и на хлеб, и на масло, а иногда и на красную икру.
Не покривив душой, я могу сказать, что мы относимся к языку Go и его создателям с симпатией и уважением.
Однако, при всем нашем уважении, заявить, что Go предназначен для "тяжелых" проектов, я, не покривив душой, не могу.
Во-первых, Go молодой язык, для которого еще не известны паттерны и - что важнее - антипаттерны. Тем, кто пишет на Go тяжелое приложение сегодня, приходится тратить существенное время на тесты и оптимизации
Во-вторых, выразительные средства Go довольно скудны, что приводит к появлению в коде ужасающего количества boilerplate, за которым эффективно прячется бизнес-логика. Программу на Go бывает трудно охватить взглядом и поместить ее модель себе в голову просто из-за количества строк, которые надо для этого прочесть.
В-третьих, у Go есть проблемы с эффективностью кода. У Go плохой оптимизатор. У Go плохо с "заточкой" под железо - вспомним хотя бы историю с патчем CloudFlare для TLS. Патч ведь так и не попал в основную ветку...
Возникает вопрос - почему же, не по наслышке зная о вышеперечисленных проблемах, мы пишем наш реально тяжелый проект именно на Go?
Ответ прост: Go не идеален, но под наши задачи он подходит лучше всего.
Раньше мы строили разные тяжелые бекенды на perl, python, java, groovy и даже lua+nginx. Нам есть, с чем сравнивать.
Во-первых, Go достаточно быстр. Во всяком случае, он быстрее perl и python на нашем профиле нагрузки.
Во-вторых, и это важнее, Go предоставляет вполне достаточные средства контроля за потреблением как RAM, так и CPU. Например, регулярные выражения Go не такие гибкие, как pcre, и, по моим наблюдениям, медленнее, чем pcre. Но! регулярные выражения в Go всегда отрабатывают за предсказуемое время!
В-третьих, создатели языка не врут нам - они, действительно, постарались сделать язык, на котором человекочитаемую программу написать проще, чем нечитаемую. И у них - с некоторомы оговорками - получилось! Даже пресловутый boilerplate не способен этому помешать.
Наконец, Go просто сумел нам понравиться, чего уже давно не случалось с языками программирования.
Итак, на основании опыта, полученного при создании пилотной версии проекта inCaller.org я расскажу о том, как мы писали на Go тяжелое приложение.
Миллионы одновременных персистентных websocket соединений, десятки тысяч коннектов по ssl в секунду, сотни тысяч в секунду обновлений записей в БД.
Я расскажу об антипаттернах, нами обнаруженных, о методике тестирования производительности, анализа проблем и способах с проблемами справиться.
Доклад рассчитан на backend-программистов, как на языке Go, так и на других.
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
RTB DSP на языке Go укрощение buzzwords / Даниил Подольский (Qmobi.Com)Ontico
RTB и его проблематика должны быть знакомы участникам конференции — мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие — нет, будет рассказано в докладе.
Банки.ру — проект с 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?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
Миф об очень сложном 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, чем новое железо.
- Очень много очен�
Учебный план для highload гуру / Андрей Аксёнов (Sphinx Technologies Inc.)Ontico
Программирование — штука одновременно очень узкая и очень широкая. С одной стороны, фундаментальных структур данных и алгоритмов крайне мало, а с другой, решаемых задач и специальных (для разных индустрий) техник много. И это мы молчим про регулярно появляющиеся новые клёвые библиотеки, фреймворки, СУБД, языки, трояны и кукизы. Через это системы вырастают всё более сложные и на стыке всего подряд, проблемы и задачи в них тоже. А значит, чтобы уметь ловко забарывать совсем любые задачи — особенно с хитростями и подвывертами из-за высокой нагрузки, распределенной архитектуры или тупо ограничений по железу — надо понимать много всякого про все уровни этих задач.
Как такому пониманию научиться, что именно надо изучать? Чего именно в идеале должен (и может!) знать каждый, а на практике почему-то не боятся знать единицы? Почему N-томника Кнута слишком много, но недостаточно? Какой очередной pet project затеять заради глобальной личной пользы вместо заныра в дебри очередного сиюминутного фреймворка? Чего читать после (или даже вместо) Гарри Поттера? Читать ли книжки вообще? Исчерпывающий ответ на эти вопросы возможно, пожалуй, уложить в недлинный 3-летний интенсивный учебный курс, но примерно правильный ответ я все равно попытаюсь дать в рамках доклада.
Пайплайн машинного обучения на Apache Spark / Павел Клеменков (Rambler&Co)Ontico
В докладе рассмотрим нашу старую архитектуру пайплайна машинного обучения, обратим внимание на ее недостатки как с точки зрения инфраструктуры и автоматизации, так и с точки зрения настройки моделей машинного обучения и проведения экспериментов. Разберемся с архитектурой Apache Spark, и почему мы решили его использовать. Подробно ознакомимся с новой архитектурой нашего пайплайна и тем, как она позволила оптимизировать обнаружение и устранение проблем, ускорила и упростила работу data scientist'ов по проведению экспериментов и доведения их до продакшена. Также затронем вопросы написания тестов и процесса разработки ПО на больших данных.
Serghei Iakovlev "Chaos engineering in action"Fwdays
Let's talk about what chaos engineering is and how this discipline can be applied in projects where PHP is used as the main language.
Among other things, we will cover the following topics:
What problems does chaos engineering solve?
What are the solutions exist?
How to develop your own solution?
What is a controlled failover?
A little about ZendEngine and what tools are out of the box?
A bit about chaos design.
A bit about the code leading to chaos.
Выбираем СУБД для хранения временных рядов / Павел Филонов (Лаборатория Каспе...Ontico
Проблема мониторинга целостности технологических процессов на индустриальных объектах связана с обработкой большого объема показаний различных датчиков (температура, давление, управляющие сигналы и т.д.). Каждый из таких сенсоров порождает временной ряд, который может быть использован как для потоковой обработки, так и для проведения исторического анализа и расследования инцидентов. Здесь возникает задача хранения показаний за некоторый период времени. При этом потоки данных могут достигать десятков тысяч показаний в секунду, а период хранения достигать нескольких месяцев или даже лет. При таких условиях необходимо предельно аккуратно выбирать СУБД для хранения временных рядов, которая правильно впишется в нефункциональные требования.
В качестве конкурсантов выступят: OpenTSDB, InfluxDB, MongoDB, PostgreSQL и еще несколько "чёрных лошадок".
В докладе будет рассмотрен многокритериальный подход к выбору с учетом таких показателей как:
* зависимость пропускной способности на запись от различных параметров;
* время исполнения запроса на чтение;
* степень сжатия данных;
* пропускная способность при нагрузочном тестировании.
В докладе предлагается не только привести получившиеся числа, но и обсудить почему они получились именно такими.
Поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.
Рассмотрим следующие темы и поищем ответы на вопросы:
1) Что такое фреймворк, и зачем их пишут.
2) Почему для некоторых языков их десятки, а для некоторых — единицы.
3) В чём плюсы и минусы применения.
4) Наиболее распространённые мифы.
5) Использовать или нет — примеры из жизни.
6) Как выбрать из множества доступных вариантов, на что стоит обратить внимание.
WebGL многими воспринимается как API для "быстрого" рисования. Но на практике нередко случается, что решение на WebGL выходит медленным, иногда даже медленнее решений на других API.
В этом докладе мы попробуем взглянуть на проблемы производительности, встречающиеся в работе с WebGL, и их решения на примере движка Панорам Яндекс.Карт.
Why do we need ORM? The difference between ActiveRecord and DataMapper patterns. The practical appliance of Iterative deepening depth-first search algo for topological sort of ORM relations.
Review of Cycle ORM and it features.
Организация надежного резервного копирования веб-проекта. Практика и подводны...Anton Baranov
1. Общая информация
- Что именно нужно бэкапить?
- Типы бэкапов. Плюсы и минусы.
- Периодичность создания.
- Выбор хранилища.
2. Бэкапы БД и файлов
- Обзор инструментов.
- Источники данных для бэкапов.
- Неочевидные особенности создания/восстановления.
3. Проблемы организации резервного копирования
- Актуальность данных.
- Скорость восстановления.
- Надежность создания резервных копий.
4. Верификация бэкапов
- Тестовый стенд.
- Мониторинг процесса.
- Ручные проверки.
Performance management lessons learnt / Андрей Дмитриев (JUGRU)Ontico
В идеальном мире нагрузочное тестирование проводится своевременно, с должной поддержкой со стороны разработчиков, на подходящем железе и с нужным объемом данных.
В реальности выполнение многих задач может запаздывать, способ решения может меняться и заказчик может менять свои планы.
Как минимальными усилиями можно провести тестирование производительности, при этом не упустив важных кейсов?
Наша команда проводит нагрузочное тестирование на десятке различных аккаунтов по всему миру и за последнее время накопила большой опыт, проводя тестирование полного цикла: от сбора требований до выдачи отчета заказчику.
В этом докладе я постараюсь охватить не только подход к нагрузочному тестированию, который мы практикуем, но и подход к управлению скоростными характеристиками проекта.
Как 100 000 раз в секунду выбирать правильный рекламный материал? Programmati...Ontico
Число запросов на показ рекламы и число рекламных кампаний постоянно растет. Начиная с 2013 года, мы наблюдаем рост этих показателей в десятки раз.
Так как нагрузка на нашу систему пропорциональна произведению этих чисел, такой рост создает для нас множество сложных и интересных задач.
Некоторые из этих задач, про которые расскажем:
- Как из тысяч рекламных материалов выбрать наиболее релевантный для пользователя и делать это 100 000 раз в секунду?
- Как реализовать таргетирование рекламных кампаний так, чтобы общая производительность почти не зависела от общего количества этих кампаний?
- Как эффективно запрашивать данные из внешних сервисов, когда таких запросов надо делать миллионы раз в секунду?
- Как оставаться в рамках 50 мс на ответ даже в моменты пиковой нагрузки, в разы превышающей нормальную?
- Как измерять и мониторить нагруженность в разрезе по потокам и автоматически реагировать на перегрузки?
- Как сразу видеть эффект от оптимизации или негативное влияние новой функциональности на нагрузку?
Функциональное тестирование высоконагруженных проектов / Илья Пастушков (2ГИС)Ontico
В докладе я расскажу о следующем:
+ почему тема доклада не оговорка, а абсолютно реальная вещь;
+ что можно извлечь из результатов теста помимо «да/нет»;
+ в каких случаях «количество» = «качество»;
+ когда «один в поле не воин»;
+ немного о том, зачем тестировщику нужна матстатистика;
+ как избежать случайностей в результатах;
+ «буря в стакане» или масштабируем highload в docker/openvz;
+ почему фиксация запросов в тестах приводит к фиксации сервиса на продакшене;
+ а также всё вышеперечисленное на примерах наших проектов.
Ошибки проектирования высоконагруженных проектов / Максим Ехлаков (OneTwoRent)Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 5 июня, 15:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2632.html
Наиболее типичные ошибки, которые совершаются при создании высоконагруженных продуктов: выбор используемых языков, фреймворков, СУБД и других инструментов. Каковы причины совершения этих ошибок, и как их избежать.
Во время проектирования и разработки высоконагруженных программных продуктов существует большой соблазн применить классические подходы. Однако не все они будут полезны, а какие-то даже вредны. При этом цена каждой такой ошибки всегда будет очень большой.
На примере нескольких реальных проектов мы поговорим об ошибках проектирования, разработки и управления, о том, почему они возникли, и о решениях, которые позволили (или не позволили) преодолеть их.
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?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
Миф об очень сложном 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, чем новое железо.
- Очень много очен�
Учебный план для highload гуру / Андрей Аксёнов (Sphinx Technologies Inc.)Ontico
Программирование — штука одновременно очень узкая и очень широкая. С одной стороны, фундаментальных структур данных и алгоритмов крайне мало, а с другой, решаемых задач и специальных (для разных индустрий) техник много. И это мы молчим про регулярно появляющиеся новые клёвые библиотеки, фреймворки, СУБД, языки, трояны и кукизы. Через это системы вырастают всё более сложные и на стыке всего подряд, проблемы и задачи в них тоже. А значит, чтобы уметь ловко забарывать совсем любые задачи — особенно с хитростями и подвывертами из-за высокой нагрузки, распределенной архитектуры или тупо ограничений по железу — надо понимать много всякого про все уровни этих задач.
Как такому пониманию научиться, что именно надо изучать? Чего именно в идеале должен (и может!) знать каждый, а на практике почему-то не боятся знать единицы? Почему N-томника Кнута слишком много, но недостаточно? Какой очередной pet project затеять заради глобальной личной пользы вместо заныра в дебри очередного сиюминутного фреймворка? Чего читать после (или даже вместо) Гарри Поттера? Читать ли книжки вообще? Исчерпывающий ответ на эти вопросы возможно, пожалуй, уложить в недлинный 3-летний интенсивный учебный курс, но примерно правильный ответ я все равно попытаюсь дать в рамках доклада.
Пайплайн машинного обучения на Apache Spark / Павел Клеменков (Rambler&Co)Ontico
В докладе рассмотрим нашу старую архитектуру пайплайна машинного обучения, обратим внимание на ее недостатки как с точки зрения инфраструктуры и автоматизации, так и с точки зрения настройки моделей машинного обучения и проведения экспериментов. Разберемся с архитектурой Apache Spark, и почему мы решили его использовать. Подробно ознакомимся с новой архитектурой нашего пайплайна и тем, как она позволила оптимизировать обнаружение и устранение проблем, ускорила и упростила работу data scientist'ов по проведению экспериментов и доведения их до продакшена. Также затронем вопросы написания тестов и процесса разработки ПО на больших данных.
Serghei Iakovlev "Chaos engineering in action"Fwdays
Let's talk about what chaos engineering is and how this discipline can be applied in projects where PHP is used as the main language.
Among other things, we will cover the following topics:
What problems does chaos engineering solve?
What are the solutions exist?
How to develop your own solution?
What is a controlled failover?
A little about ZendEngine and what tools are out of the box?
A bit about chaos design.
A bit about the code leading to chaos.
Выбираем СУБД для хранения временных рядов / Павел Филонов (Лаборатория Каспе...Ontico
Проблема мониторинга целостности технологических процессов на индустриальных объектах связана с обработкой большого объема показаний различных датчиков (температура, давление, управляющие сигналы и т.д.). Каждый из таких сенсоров порождает временной ряд, который может быть использован как для потоковой обработки, так и для проведения исторического анализа и расследования инцидентов. Здесь возникает задача хранения показаний за некоторый период времени. При этом потоки данных могут достигать десятков тысяч показаний в секунду, а период хранения достигать нескольких месяцев или даже лет. При таких условиях необходимо предельно аккуратно выбирать СУБД для хранения временных рядов, которая правильно впишется в нефункциональные требования.
В качестве конкурсантов выступят: OpenTSDB, InfluxDB, MongoDB, PostgreSQL и еще несколько "чёрных лошадок".
В докладе будет рассмотрен многокритериальный подход к выбору с учетом таких показателей как:
* зависимость пропускной способности на запись от различных параметров;
* время исполнения запроса на чтение;
* степень сжатия данных;
* пропускная способность при нагрузочном тестировании.
В докладе предлагается не только привести получившиеся числа, но и обсудить почему они получились именно такими.
Поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.
Рассмотрим следующие темы и поищем ответы на вопросы:
1) Что такое фреймворк, и зачем их пишут.
2) Почему для некоторых языков их десятки, а для некоторых — единицы.
3) В чём плюсы и минусы применения.
4) Наиболее распространённые мифы.
5) Использовать или нет — примеры из жизни.
6) Как выбрать из множества доступных вариантов, на что стоит обратить внимание.
WebGL многими воспринимается как API для "быстрого" рисования. Но на практике нередко случается, что решение на WebGL выходит медленным, иногда даже медленнее решений на других API.
В этом докладе мы попробуем взглянуть на проблемы производительности, встречающиеся в работе с WebGL, и их решения на примере движка Панорам Яндекс.Карт.
Why do we need ORM? The difference between ActiveRecord and DataMapper patterns. The practical appliance of Iterative deepening depth-first search algo for topological sort of ORM relations.
Review of Cycle ORM and it features.
Организация надежного резервного копирования веб-проекта. Практика и подводны...Anton Baranov
1. Общая информация
- Что именно нужно бэкапить?
- Типы бэкапов. Плюсы и минусы.
- Периодичность создания.
- Выбор хранилища.
2. Бэкапы БД и файлов
- Обзор инструментов.
- Источники данных для бэкапов.
- Неочевидные особенности создания/восстановления.
3. Проблемы организации резервного копирования
- Актуальность данных.
- Скорость восстановления.
- Надежность создания резервных копий.
4. Верификация бэкапов
- Тестовый стенд.
- Мониторинг процесса.
- Ручные проверки.
Performance management lessons learnt / Андрей Дмитриев (JUGRU)Ontico
В идеальном мире нагрузочное тестирование проводится своевременно, с должной поддержкой со стороны разработчиков, на подходящем железе и с нужным объемом данных.
В реальности выполнение многих задач может запаздывать, способ решения может меняться и заказчик может менять свои планы.
Как минимальными усилиями можно провести тестирование производительности, при этом не упустив важных кейсов?
Наша команда проводит нагрузочное тестирование на десятке различных аккаунтов по всему миру и за последнее время накопила большой опыт, проводя тестирование полного цикла: от сбора требований до выдачи отчета заказчику.
В этом докладе я постараюсь охватить не только подход к нагрузочному тестированию, который мы практикуем, но и подход к управлению скоростными характеристиками проекта.
Как 100 000 раз в секунду выбирать правильный рекламный материал? Programmati...Ontico
Число запросов на показ рекламы и число рекламных кампаний постоянно растет. Начиная с 2013 года, мы наблюдаем рост этих показателей в десятки раз.
Так как нагрузка на нашу систему пропорциональна произведению этих чисел, такой рост создает для нас множество сложных и интересных задач.
Некоторые из этих задач, про которые расскажем:
- Как из тысяч рекламных материалов выбрать наиболее релевантный для пользователя и делать это 100 000 раз в секунду?
- Как реализовать таргетирование рекламных кампаний так, чтобы общая производительность почти не зависела от общего количества этих кампаний?
- Как эффективно запрашивать данные из внешних сервисов, когда таких запросов надо делать миллионы раз в секунду?
- Как оставаться в рамках 50 мс на ответ даже в моменты пиковой нагрузки, в разы превышающей нормальную?
- Как измерять и мониторить нагруженность в разрезе по потокам и автоматически реагировать на перегрузки?
- Как сразу видеть эффект от оптимизации или негативное влияние новой функциональности на нагрузку?
Функциональное тестирование высоконагруженных проектов / Илья Пастушков (2ГИС)Ontico
В докладе я расскажу о следующем:
+ почему тема доклада не оговорка, а абсолютно реальная вещь;
+ что можно извлечь из результатов теста помимо «да/нет»;
+ в каких случаях «количество» = «качество»;
+ когда «один в поле не воин»;
+ немного о том, зачем тестировщику нужна матстатистика;
+ как избежать случайностей в результатах;
+ «буря в стакане» или масштабируем highload в docker/openvz;
+ почему фиксация запросов в тестах приводит к фиксации сервиса на продакшене;
+ а также всё вышеперечисленное на примерах наших проектов.
Ошибки проектирования высоконагруженных проектов / Максим Ехлаков (OneTwoRent)Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 5 июня, 15:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2632.html
Наиболее типичные ошибки, которые совершаются при создании высоконагруженных продуктов: выбор используемых языков, фреймворков, СУБД и других инструментов. Каковы причины совершения этих ошибок, и как их избежать.
Во время проектирования и разработки высоконагруженных программных продуктов существует большой соблазн применить классические подходы. Однако не все они будут полезны, а какие-то даже вредны. При этом цена каждой такой ошибки всегда будет очень большой.
На примере нескольких реальных проектов мы поговорим об ошибках проектирования, разработки и управления, о том, почему они возникли, и о решениях, которые позволили (или не позволили) преодолеть их.
сравнение производительности СУБД MySQL и PostgreSQL для "типичной задачи стартапа".
Презентация сопровождала тестовую online-сессию и потому не содержит результатов тестирования.
Бинарные (файловые) хранилища- страшная сказка с мрачным концомDaniel Podolsky
1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочетаний требований решение есть!
4.3. А для остальных - решения нет.
5. Так что же все-таки делать? (заключение)
5.1. искать бюджет
5.2. все-таки сложить все файлы в базу - личное мнение докладчика
5.3. написать свое
5.3.1. не так это и сложно!
5.3.2. но все же довольно сложно
ночью через лес Stress-test пяти almost-the-same-functionality shared-nothin...Daniel Podolsky
1. "Mia! MIA! What the hell happened?", или что случается с производительностью вашей РСУБД, когда ее индексы перестают помещаться в память
2. "Why the fuck didn't you tell us about that guy in the bathroom?", или почему мы гадим под себя, когда речь заходит о шардинге РСУБД
3. "Now the night of the fight, you may fell a slight sting, that's pride fuckin' wit ya. Fuck pride! ", или почему shared nothing
4. "And that's what we're gonna be, we're gonna be cool.", или с какими проблемами сталкиваются люди, которые собрались эксплуатировать shared-nothing cluster
5. "Mind if I try one of yours?", или наша методика тестирования
6. “The truth. Three well-dressed, slightly toasted, Mexicans.”, или отбор кандидатов на тестирование
7. "So you're gonna go out there, drink your drink, say "Goodnight, I've had a very lovely evening," go home, and jack off.", или краткий отчет о безумной неделе
8. "This sensual thing's goin' on that nobody's talkin about, but you know it and she knows it, fuckin' Marsellus knew it, and Antwan shoulda known fuckin' better.", или выводы
Delivered as plenary at USENIX LISA 2013. video here: https://www.youtube.com/watch?v=nZfNehCzGdw and https://www.usenix.org/conference/lisa13/technical-sessions/plenary/gregg . "How did we ever analyze performance before Flame Graphs?" This new visualization invented by Brendan can help you quickly understand application and kernel performance, especially CPU usage, where stacks (call graphs) can be sampled and then visualized as an interactive flame graph. Flame Graphs are now used for a growing variety of targets: for applications and kernels on Linux, SmartOS, Mac OS X, and Windows; for languages including C, C++, node.js, ruby, and Lua; and in WebKit Web Inspector. This talk will explain them and provide use cases and new visualizations for other event types, including I/O, memory usage, and latency.
Прогрессивный рендеринг и Catberry.js / Михаил Реенко (2GIS / Flamp)Ontico
РИТ++ 2017, Frontend Сonf
Зал Мумбаи, 6 июня, 14:00
Тезисы:
http://frontendconf.ru/2017/abstracts/2471.html
Знаете ли вы, что такое прогрессивный рендеринг?
Почему вам стоит его использовать?
Какие есть варианты сегодня?
PG Day'14 Russia, PostgreSQL в avito.ru, Михаил Тюринpgdayrussia
Доклад был представлен на официальной российской конференции PG Day'14 Russia, посвященной вопросам разработки и эксплуатации PostgreSQL.
С момента старта проекта на PostgreSQL были возложены серьёзные задачи. Это во многом предопределило успешное развитие всего продукта. Вокруг СУБД выстроены основные компоненты архитектуры, при этом сами базы берут на себя львиную долю обработки пользовательских запросов. Набор фич и расширений, легендарная надёжность PostgreSQL, наличие встроенной репликации, средств резервирования и архивирования — весь потенциал нашел своё воплощение, а наличие открытого профессионального комьюнити не оставляет шансов к неэффективной реализации.
В докладе будет дан обзор развития подсистем, сосредоточенных вокруг PostgreSQL, представлены параметры и режимы функционирования. Будут описаны успешные решения в рамках отдельного PostgreSQL-кластера и при распределенной обработке данных, приведены текущие вызовы, связанные с продолжающимся активным ростом проекта.
TК°Conf. Организация разработки Frontend. Виталий Слободин.TKConf
Расскажу об организации процесса разработки Frontend в единый конвейер, чтобы увеличить скорость и минимизировать затраты с рисками.
Как организовать верстку макета по фантастичному макету дизайнера при этом не вогнав в когнитивный диссонанс результатом на Bootstrap.
Каким образом объединить воинствующие стороны: Frontend, Backend и дизайнеров.
Контрибьютить в известные проекты можно и нужно. Участие в ОpenSource-проектах помогает лучше изучить их внутренности, позволяет не останавливаться в развитии, даже если нет интересных и сложных задач в коммерческих проектах.
Надеюсь своим выступлением мотивировать белорусских разработчиков принимать активное участие в OpenSource-проектах во благо мирового Ruby Community.
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 и некоторых других местах.
3. Немного о себе
• Системный администратор со стажем 20 лет
• начинал на ассемблере х86
• последняя прочитанная книжка о процессорах
инструкциях и регистрах - i386
4. Немного о себе
• Системный администратор со стажем 20 лет
• начинал на ассемблере х86
• последняя прочитанная книжка о процессорах
инструкциях и регистрах - i386
• Пишу/читаю на C, C++, Perl5, Java, Groovy,
Lua,Go
5. Немного о себе
• Системный администратор со стажем 20 лет
• начинал на ассемблере х86
• последняя прочитанная книжка о процессорах
инструкциях и регистрах - i386
• Пишу/читаю на C, C++, Perl5, Java, Groovy,
Lua,Go
• Сейчас руковожу разработкой проекта на Go
7. Немного о себе
• Люблю Perl5
• Правда-правда!
• Даже имею несколько опубликованных на
CPAN модулей
8. Немного о себе
• Люблю Perl5
• Правда-правда!
• Даже имею несколько опубликованных на
CPAN модулей
• Не читал Modern Perl
9. Немного о себе
• Люблю Perl5
• Правда-правда!
• Даже имею несколько опубликованных на
CPAN модулей
• Не читал Modern Perl
• Фактически - не пишу на современном перле
10. О чем и зачем этот доклад
• О том, как я расстался с Perl
11. О чем и зачем этот доклад
• О том, как я расстался с Perl
• Я хочу поделиться опытом проигранных
сражений
12. О чем и зачем этот доклад
• О том, как я расстался с Perl
• Я хочу поделиться опытом проигранных
сражений
• И предостеречь “молодежь”
13. О чем и зачем этот доклад
• О том, как я расстался с Perl
• Я хочу поделиться опытом проигранных
сражений
• И предостеречь “молодежь”
• Хоть и осознаю, что в этом нет смысла
30. Стадии развития проекта:
отрицание
• AnyEvent, Mojo, XML, JSON
• масса всего всякого XS
• чтение кода ночами
• “мы - программисты, мы любим писать
сложный код”
31. Стадии развития проекта:
отрицание
• AnyEvent, Mojo, XML, JSON
• масса всего всякого XS
• чтение кода ночами
• “мы - программисты, мы любим писать
сложный код”
• “все языки одинаковы”
39. Стадии развития проекта:
гнев
• Монолитное приложение
• так делают java-программисты
• так делать не надо
• Копирование массивов при передаче параметров
40. Стадии развития проекта:
гнев
• Монолитное приложение
• так делают java-программисты
• так делать не надо
• Копирование массивов при передаче параметров
• замена хешей на перебор
41. Стадии развития проекта:
гнев
• Монолитное приложение
• так делают java-программисты
• так делать не надо
• Копирование массивов при передаче параметров
• замена хешей на перебор
• замена регекспов на токенизаторы
48. Стадии развития проекта:
отчаяние
• отсутствие оптимизатора
• отсутствие семплирующего профайлера
• да вообще какого-либо пригодного для
использования профайлера
49. Стадии развития проекта:
отчаяние
• отсутствие оптимизатора
• отсутствие семплирующего профайлера
• да вообще какого-либо пригодного для
использования профайлера
• threads are weird
50. Стадии развития проекта:
отчаяние
• отсутствие оптимизатора
• отсутствие семплирующего профайлера
• да вообще какого-либо пригодного для
использования профайлера
• threads are weird
• IPC is weird
53. Стадии развития проекта:
отчаяние
• очень дорогой вызов функции
• очень высокие накладные расходы на
обслуживание очереди событий
• reordering?!
54. Стадии развития проекта:
отчаяние
• очень дорогой вызов функции
• очень высокие накладные расходы на
обслуживание очереди событий
• reordering?!
• Приложение захлебывается при высокой
утилизации CPU
55. Стадии развития проекта:
отчаяние
• Основное время выполняется код, которого мы
не писали
• низкоэффективные структуры данных
• современный perl - очень сложный язык
• наверное, все же не все языки одинаковы
• и уж точно разные VM и runtime
58. Стадии развития проекта:
отчаяние
• Основное время выполняется код, которого мы
не писали
• низкоэффективные структуры данных
• современный perl - очень сложный язык
59. Стадии развития проекта:
отчаяние
• Основное время выполняется код, которого мы
не писали
• низкоэффективные структуры данных
• современный perl - очень сложный язык
• наверное, все же не все языки одинаковы
60. Стадии развития проекта:
отчаяние
• Основное время выполняется код, которого мы
не писали
• низкоэффективные структуры данных
• современный perl - очень сложный язык
• наверное, все же не все языки одинаковы
• и уж точно разные VM и runtime
65. Стадии развития проекта:
смирение
• Groovy
• увеличение производительности в 8 раз
• приложение перестало захлебываться
• nginx+lua
• получилось не хуже
66. Стадии развития проекта:
смирение
• Groovy
• увеличение производительности в 8 раз
• приложение перестало захлебываться
• nginx+lua
• получилось не хуже
• то есть - дело не в собственно асинхронности
70. Что же делать?!
или выводы
• Никогда больше
• по результатам я выучил Go
• Никакой асинхронности
• запускать в голове стейт-машину - развлечение
для дебилов
71. Что же делать?!
или выводы
• Никогда больше
• по результатам я выучил Go
• Никакой асинхронности
72. Что же делать?!
или выводы
• Никогда больше
• по результатам я выучил Go
• Никакой асинхронности
• запускать в голове стейт-машину - развлечение
для дебилов
73. Что же делать?!
или выводы
• Возможно, выход - в использовании
функциональных языков
74. Что же делать?!
или выводы
• Возможно, выход - в использовании
функциональных языков
• и акторов
75. Что же делать?!
или выводы
• Возможно, выход - в использовании
функциональных языков
• и акторов
• микросервисы - акторы для бедных