4 года разрабатывает видеостриминговый сервер эрливидео и в этом докладе расскажет о некоторых отличительных возможностях Erlang, которые позволяют быстро развиваться и поддерживать высочайшее качество ПО минимальными усилиями.
Рельсы прекрасный инструмент, но в некоторых ситуациях они не справляются.
В этом докладе рассказывается о таких ситуациях и одном из вариантов решения
ELK: менеджмент логов, быстрая локализация проблем / Сергей Шумов (News360)Ontico
Сначала несколько слов про предпосылки задачи.
1. Что нам завещали деды: zcat | cut | sort | uniq -c | sort -nr . На самом деле, нормально работает, когда на проекте есть только лог nginx и не больше пары ГБ в день. В случае аварий tail -f | grep позволяет найти проблему за пару минут.
При первой же попытке параллелизации инстансов работать становится неудобно, нужна
2. Сборка логов: syslog-ng, rsyslog etc. Логи с локальных syslogd по UDP агрегируются в одно общее файловое хранилище.
Помогает собирать файлы логов с разных инстансов или сервисов. Минусы:
* Мы по-прежнему ограничены общим объемом логов. Текущие аварии на одном сервисе локализуются сравнительно быстро, но ретроспективная статистика строится часами.
* Появляются неприятные артефакты: задержки при доставке логов в хранилище, неупорядоченность событий в логах из-за разной задержки на разных инстансах. Последнее - вообще, беда, так как по-хорошему требует полной пересортировки лога.
* Поскольку события хранятся как строки в файлах логов, нет жесткой необходимости соблюдать формат. Значит, он соблюдаться и не будет. Нет, все будут стараться, но косяки все равно постоянно будут возникать.
* Отвратительно (муторно, медленно, вручную) работает трекинг проблемных реквестов, особенно в сложных системах с десятками взаимосвязанных сервисов.
3. Ок, давайте сделаем все правильно:
* для всех логов будет описан формат полей;
* события вместо файлов будут храниться в горизонтально масштабируемой БД;
* большинство агрегатов будет рассчитано заранее.
Дальше пара слайдов про компоненты ELK и переходим к главному: как Kibana помогает в локализации проблем.
Полезные фичи Elastic & Kibana:
* мгновенное масштабирование от месяцев до долей секунд;
* статистика распределения для каждого поля по любому диапазону и фильтру;
* field templates;
* significant terms filtering;
* geohashing;
Несколько кейсов, где Кибана выступает отлично:
* Получение списка объектов/пользователей, на которых возникают проблемы;
* Трекинг связанных проблем на разных сервисах;
* Просмотр сессии конкретного пользователя;
* Выявление аномальных пользователей (ботов);
* Отслеживание последующих действий пользователей, попавших во всплеск активности. Средства вроде graphite визуализируют только суммарные значения, а сильная сторона Kibana именно в трекинге отдельных пользователей.
Метрики и дашборды: тут они с graphite примерно одинаково гибки, но упомянуть об этом надо.
* Как отслеживать связанные события в разных логах? Связка через общий request_id vs полное добавление контекста в событие.
* LogStash vs fluentd для доставки? Мы выбрали fluentd - меньше затраты ресурсов.
Кратенько об альтернативах, плюсы-минусы:
* realtime log readers: LogWatch
* LaaS: Splunk
Планирование требуемых ресурсов, (не-)линейность масштабирования.
Доклад с PUG#4 https://www.facebook.com/events/350783888446030/
Рассмотрим:
- Что такое Highload, термины, инструменты.
- Где тормозит PHP, родовые травмы языка, как с ними жить.
- Скорость работы vs скорость разработки.
- Архитектура, что стоит делать и когда.
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, так и на других.
Доклад с 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
Видео и материалы со встречи:
http://getdev.net/Event/dynamic-language-runtime
В докладе рассмотрим скриптовые языки на платформе DLR, способы автоматизации рутинной работы с их помощью, а также интегрирование в конечное приложение.
“Чем хорош Erlang вообще и для веб-разработки в частности?” Olga Lavrentieva
Юрий Жлоба (TvZavr.ru, Москва)
Доклад: “Чем хорош Erlang вообще и для веб-разработки в частности?”
О чем: Для какого именно веба хорош Erlang? Он не имеет ничего, сопоставимого с Ruby on Rails, тогда зачем его использовать в вебе? Вносим ясность. Примеры успешных веб-проектов на Erlang.
Alexandr Serbul "The Rust language for a high-load network service - a quick ...Fwdays
In this talk, we will talk about the evolution of the development of a high-load network cluster for sending push notifications using technologies from Unix / bash and PHP to asynchronous non-blocking multithreaded connections based on Rust / Tokio. Let's talk about the intricacies of Rust development, language features, pitfalls, and ways to quickly learn and use it for web developers with LAMP skills. Let's also talk about Go, Java, and the reasons for our technological decisions.
The talk will be useful for developers wishing to master the latest and popular Rust programming language, functional programming, Haskell ideas with PHP / Python / JavaScript web development experience.
4 года разрабатывает видеостриминговый сервер эрливидео и в этом докладе расскажет о некоторых отличительных возможностях Erlang, которые позволяют быстро развиваться и поддерживать высочайшее качество ПО минимальными усилиями.
Рельсы прекрасный инструмент, но в некоторых ситуациях они не справляются.
В этом докладе рассказывается о таких ситуациях и одном из вариантов решения
ELK: менеджмент логов, быстрая локализация проблем / Сергей Шумов (News360)Ontico
Сначала несколько слов про предпосылки задачи.
1. Что нам завещали деды: zcat | cut | sort | uniq -c | sort -nr . На самом деле, нормально работает, когда на проекте есть только лог nginx и не больше пары ГБ в день. В случае аварий tail -f | grep позволяет найти проблему за пару минут.
При первой же попытке параллелизации инстансов работать становится неудобно, нужна
2. Сборка логов: syslog-ng, rsyslog etc. Логи с локальных syslogd по UDP агрегируются в одно общее файловое хранилище.
Помогает собирать файлы логов с разных инстансов или сервисов. Минусы:
* Мы по-прежнему ограничены общим объемом логов. Текущие аварии на одном сервисе локализуются сравнительно быстро, но ретроспективная статистика строится часами.
* Появляются неприятные артефакты: задержки при доставке логов в хранилище, неупорядоченность событий в логах из-за разной задержки на разных инстансах. Последнее - вообще, беда, так как по-хорошему требует полной пересортировки лога.
* Поскольку события хранятся как строки в файлах логов, нет жесткой необходимости соблюдать формат. Значит, он соблюдаться и не будет. Нет, все будут стараться, но косяки все равно постоянно будут возникать.
* Отвратительно (муторно, медленно, вручную) работает трекинг проблемных реквестов, особенно в сложных системах с десятками взаимосвязанных сервисов.
3. Ок, давайте сделаем все правильно:
* для всех логов будет описан формат полей;
* события вместо файлов будут храниться в горизонтально масштабируемой БД;
* большинство агрегатов будет рассчитано заранее.
Дальше пара слайдов про компоненты ELK и переходим к главному: как Kibana помогает в локализации проблем.
Полезные фичи Elastic & Kibana:
* мгновенное масштабирование от месяцев до долей секунд;
* статистика распределения для каждого поля по любому диапазону и фильтру;
* field templates;
* significant terms filtering;
* geohashing;
Несколько кейсов, где Кибана выступает отлично:
* Получение списка объектов/пользователей, на которых возникают проблемы;
* Трекинг связанных проблем на разных сервисах;
* Просмотр сессии конкретного пользователя;
* Выявление аномальных пользователей (ботов);
* Отслеживание последующих действий пользователей, попавших во всплеск активности. Средства вроде graphite визуализируют только суммарные значения, а сильная сторона Kibana именно в трекинге отдельных пользователей.
Метрики и дашборды: тут они с graphite примерно одинаково гибки, но упомянуть об этом надо.
* Как отслеживать связанные события в разных логах? Связка через общий request_id vs полное добавление контекста в событие.
* LogStash vs fluentd для доставки? Мы выбрали fluentd - меньше затраты ресурсов.
Кратенько об альтернативах, плюсы-минусы:
* realtime log readers: LogWatch
* LaaS: Splunk
Планирование требуемых ресурсов, (не-)линейность масштабирования.
Доклад с PUG#4 https://www.facebook.com/events/350783888446030/
Рассмотрим:
- Что такое Highload, термины, инструменты.
- Где тормозит PHP, родовые травмы языка, как с ними жить.
- Скорость работы vs скорость разработки.
- Архитектура, что стоит делать и когда.
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, так и на других.
Доклад с 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
Видео и материалы со встречи:
http://getdev.net/Event/dynamic-language-runtime
В докладе рассмотрим скриптовые языки на платформе DLR, способы автоматизации рутинной работы с их помощью, а также интегрирование в конечное приложение.
“Чем хорош Erlang вообще и для веб-разработки в частности?” Olga Lavrentieva
Юрий Жлоба (TvZavr.ru, Москва)
Доклад: “Чем хорош Erlang вообще и для веб-разработки в частности?”
О чем: Для какого именно веба хорош Erlang? Он не имеет ничего, сопоставимого с Ruby on Rails, тогда зачем его использовать в вебе? Вносим ясность. Примеры успешных веб-проектов на Erlang.
Alexandr Serbul "The Rust language for a high-load network service - a quick ...Fwdays
In this talk, we will talk about the evolution of the development of a high-load network cluster for sending push notifications using technologies from Unix / bash and PHP to asynchronous non-blocking multithreaded connections based on Rust / Tokio. Let's talk about the intricacies of Rust development, language features, pitfalls, and ways to quickly learn and use it for web developers with LAMP skills. Let's also talk about Go, Java, and the reasons for our technological decisions.
The talk will be useful for developers wishing to master the latest and popular Rust programming language, functional programming, Haskell ideas with PHP / Python / JavaScript web development experience.
F# - функциональный язык «новой» волныKiev ALT.NET
* Функциональные языки - как ответ на новые тенденции в развитии аппаратного обеспечения.
* F#. История. Идеология, концепции, возможности.
* ФП – холодный старт. Миграция с императивных конструкций на функциональные.
* Основные механизмы для построения высоконадежных, масштабируемых, распределенных систем.
* Примеры использования Async, Mailbox message processing.
HappyDev-lite-2016-весна 04 Анна Тарасенко. На каких языках говорят программистыHappyDev-lite
Языков программирования огромное разнообразие. И несмотря на то, что вроде бы уже есть языки на все случаи жизни, все равно появляются новинки. В докладе хочу рассказать, чем языки программирования отличаются друг от друга, почему до сих пор нет самого лучшего и чем руководствоваться при выборе языка для изучения, если вы только начинаете карьеру.
1. Организационные и формальные вопросы.
2. Пользователь всегда прав!
3. Что такое язык программирования?
4. Краткая история развития языков программирования: машинные коды, ассемблер, языки высокого уровня.
5. Способы трансляции: компиляция и интерпретация.
6. Виртуальные машины.
7. Ученье — свет, неученье — тьма (для программиста: потеря работы).
Переводим без интернета: как мы делали Яндекс.Перевод для iOS, Иван МоскалёвYandex
Рассказ о том, как удалось портировать сервис машинного перевода на мобильное устройство, какие сопутствующие задачи пришлось решить и какие грабли поджидали на пути. Обсудим также, насколько современные мобильные приложения зависимы от наличия сети и как проектировать архитектуру так, чтобы в будущем не набить шишек при добавлении офлайн-режима.
Vladimir ’mend0za’ Shakhov — Linux firmware for iRMC controller on Fujitsu P...Minsk Linux User Group
Доклад Владимира Шахова про прошивку BMC (iRMC) серверов Fujitsu Primergy на основе Linux.
Прозвучал на сентябрьской линуксовке Minsk LUG 26 сентября 2015.
2. О себе
7 лет в IT
C/C++/Ruby
Специализация:
облачные хранилища
(Dropbox), виртуализация
Linux/Mac OS X
3.
4.
5.
6. Идея создания языка
Как создавать программы, почти такие же надежные,
как железо
Как программировать, почти так же просто,
как собирать железо
!
Позитивное программирование
7. Краткая история
1986 - первая версия
(by Ericsson in Computer Science lab)
1998 - открыт исходный код
!
История в трех словах:
завелось и поехало
9. Возможности Erlang
“Each year your sequential programs will go slower.
Each year your concurrent programs will go faster.”
!
Joe Armstrong (Erlang inventor)
10. Возможности Erlang
- Модель многопоточности, основанная на легких процессах,
обменивающихся сообщениями;
- Распределенность, сетевая прозрачность;
- Устойчивость к ошибкам;
- Горячее обновление кода.
14. Устойчивость к ошибкам Erlang
Три уровня защиты:
Изолированность потоков,
супервайзеры,
распределенность
!
На практике все это все равно не спасает
от проблем
18. Достоинства языка Erlang
- неизменяемые переменные
- нет общего состояния между процессами (передача
сообщений)
- быстрое обучение (несколько недель)
- зрелость языка
- меньше кода - меньше багов
- горячее обновление кода
- удобное создание и парсинг бинарных протоколов
- есть вакансии. хорошие. сравнительно много для
мира ФП
19. Недостатки языка Erlang
- это не язык общего назначения
- динамическая типизация - для меня недостаток
- плохая документация для библиотек
- бардак с библиотеками, нестабильны, куча версий,
форков и непонятно какую использовать
- синтаксис языка часто удручает. Это Prolog (80’s).
- тяжелый рефакторинг, много синтаксических ошибок
- хочется статической типизации
- erlang медленный. В важных местах прибегать к С.
- мало разработчиков
20. Erlang хорошо подходит для
- системы мониторинга
- распределенные БД
- СПЕЦИАЛИЗИРОВАННЫЕ высокопроизводительные
веб-серверы
- приложения, нуждающиеся в кластеризации и
распределении вычислений
- для soft real-time приложений (streaming видео это soft
real time, баллистические ракеты это hard real-time).
- различные load-balancer без привязки к протоколу.
21. Erlang плохо подходит для
- веб-приложений которые работают с CRUD (create/retrieve/
update/delete), веб-формы, веб-UI, сайты).
- тяжелые вычислительные задачи
- обработка строк: парсеры, преобразования, и.т.д..
- Desktop GUI
22. Почему не стоит писать на Erlang
- политика (erlang это не С и не Java, политика
компании)
- один производитель - представьте, что Ericcson
перестанет поддерживать erlang
- не мейнстрим. мало программистов.