В предыдущем посте я рассказал общие впечатления о конференции, а здесь оставил то, что осталось в голове от прослушанных докладов. Кстати, по объему и качеству описания можно определять насколько мне был понятен и интересен доклад :)
NAS, Predictions, Preloading, Presudo-Isomorphism - Охрименко Алексей
В этом докладе Алексей рассказал о том, как улучшить производительность веб сайта с точки зрения пользователя. Сперва это может показаться парадоксальным, но чтобы этого добиться, надо уменьшить реальную производительность. Например, если с 90% вероятностью мы знаем, что пользователь сделает какое-то действие, для которого надо подгрузить картинку, то нужно взять и загрузить ее заранее. Или если пользователь ввел логин и вводит сейчас пароль, то на сервере уже сейчас можно подгружать всю информацию о пользователе. В итоге, для пользователя все будет быстрее, но нагрузка на сервер вырастет. Эти два примера представляют паттерны Predictions и Preloading соответственно. Также хорошим тоном является неблокирующее состояние приложения, иными словами, все операции для пользователя должны быть асинхронными. Например, как это сделано вконтакте: ведя переписку, можно начать загружать файл и продолжать переписываться, как только файл будет загружен, появится возможность отправить его собеседнику. В конце доклада Алексей рассказал про преимущества техники Presudo-Isomorphism, так называемые SPA (Single Page Application) сайты, в которых главная страница грузится только в первый раз, а затем почти все управление передается javascript.
Учебный план для highload гуру - Андрей Аксёнов
В этом докладе Андрей перечислил ключевые слова, которые стоило бы погуглить начинающему highload специалисту. Это, действительно, как признался сам докладчик, не самый интересный доклад по содержанию, но он полезен. Возможно, хватило бы какого-нибудь интернет поста на эту тему, но Андрей смог интересно преподнести все это, разбавляя общими рассуждениями о том, какой должен быть специалист. Универсал или узкий специалист? Какая должна быть идеальная система? Лично я стараюсь развиваться в своей узкой сфере, но ставлю себе цель постоянно мониторить что происходит вокруг, чтобы хотя бы иметь представление о тех технологиях, с которыми я не работаю. Хотя, надо понимать, что это практически бесконечная область знаний. Мне кажется, в этом мое виденье с докладчиком совпадает.
Распределенный blockchain процессинг - Алексей Трошичев
Алексей рассказывал про архитектуру процессинга, которую они у себя организовали. Типичный процессинг это две таблицы, в одной таблице балансы, а в другом транзакции. По его словам, мало кто даст зуб на то, что сумма транзакций даст актуальный баланс из таблицы. Ситуация усложняется, когда база распределяется по кластеру. Алексей описал свою отказоустойчивую архитектуру, в которой с помощью хранения в транзакции хеша предыдущей тразнакции можно гарантировать целостность цепочки тразнакций. А затем было рассказано про кластерную систему, в которой эти транзакции равномерно распределялись по нодам.
Android Cloud... точнее Cloud из Android - Охрименко Алексей
В этом докладе Охрименко Алексей рассказал о том, как он построил кластерную сеть из дешевых китайских android планшетов. Аудитория все это слушала с большой долей скептицизма и усмешки, но докладчик настаивал на своем и убеждал, что будущее за этим. В качестве примера была приведена сеть из 7 планшетов за 3000 рублей, на которых был установлен linux. Утверждалось, что за 25000 рублей была достигнута цифра 500 RPS, что вроде как дешево. На таком "мобильном" кластере удалось развернуть Docker, Vargant, Postgress, Hadoop, Jenkins, Gitlab. Параллельно узнали о китайских планшетах много нового, например, бывают случаи, когда только после установки linux вскрывается, что процессор у устройства был двухъядерный, а не четырёхъядерный, как было видно из android. Также производительность планшета сильно падает после 50%-ой разрядки аккумулятора.
Ускорение показа превью изображений в Яндекс.Диске - Сергей Нечаев
Одни пользователи постоянно загружают новые фотки на Яндекс.Диск, другие в это время их просматривают, а яндекс обеспечивает всему этому быструю бесперебойную работу. Кому-то нужно только небольшое превью картинок, чтобы увидеть набор изображений на маленьком дисплее телефона, кому-то чуть побольше, для превью на ноутбуке, а кто-то будет смотреть фото в оригинальном размере. Это накладывает сложности в том, чтобы обеспечить быстрый показ одного и того же изображения в разных размерах. Команда из Яндекса пришла к выводу, что выгоднее всего при загрузке сгенерировать уменьшенную копию изображения 1380 пикселей по максимальному размеру, а затем по требованию генерировать более мелкие изображения для просмотра. Собственно доклад был посвящен тому, почему были выбраны такие решения, как удалось это все реализовать на высоконагруженном проекте и с какими трудностями пришлось столкнуться.
Одни пользователи постоянно загружают новые фотки на Яндекс.Диск, другие в это время их просматривают, а яндекс обеспечивает всему этому быструю бесперебойную работу. Кому-то нужно только небольшое превью картинок, чтобы увидеть набор изображений на маленьком дисплее телефона, кому-то чуть побольше, для превью на ноутбуке, а кто-то будет смотреть фото в оригинальном размере. Это накладывает сложности в том, чтобы обеспечить быстрый показ одного и того же изображения в разных размерах. Команда из Яндекса пришла к выводу, что выгоднее всего при загрузке сгенерировать уменьшенную копию изображения 1380 пикселей по максимальному размеру, а затем по требованию генерировать более мелкие изображения для просмотра. Собственно доклад был посвящен тому, почему были выбраны такие решения, как удалось это все реализовать на высоконагруженном проекте и с какими трудностями пришлось столкнуться.
Tarantool: как сэкономить миллион долларов на базе данных на высоконагруженном проекте - Аникин Денис
Tarantool как платформа для микросервисов - Антон Резников и Владимир Перепелица
Эти два доклада были посвящены open source разработке mail.ru - Tarantool. Сначала Денис рассказывал о том, что может происходить по мере роста проекта. Сначала есть база данных, но постепенно количество запросов к ней становиться все больше и больше. Если это запросы на чтение, то можно поднять базу на еще одном сервере и настроить репликацию. Если же запросы на запись, то поможет шардинг. Причем во многих проектах часто запрашивается одни и те же данные, так называемые "горячие" данные, в то время как остальные данные запрашиваются редко. Ну а что если все равно медленно, несмотря на кластеризацию? Врубаем кэш - получаем проблему консистентности, а если "умный" кэш, который решает эту проблему? Тогда встает вопрос его прогрева, но это тоже решаемая задача. Собственно, так, ход за ходом, был презентован проект tarantool, который является тем самым кэшем, который решает все проблемы. Его можно использовать как кэш или как отдельную БД в памяти. Затем Антон и Владимир рассказали о примерах использования tarantool в жизни.
Tarantool как платформа для микросервисов - Антон Резников и Владимир Перепелица
Эти два доклада были посвящены open source разработке mail.ru - Tarantool. Сначала Денис рассказывал о том, что может происходить по мере роста проекта. Сначала есть база данных, но постепенно количество запросов к ней становиться все больше и больше. Если это запросы на чтение, то можно поднять базу на еще одном сервере и настроить репликацию. Если же запросы на запись, то поможет шардинг. Причем во многих проектах часто запрашивается одни и те же данные, так называемые "горячие" данные, в то время как остальные данные запрашиваются редко. Ну а что если все равно медленно, несмотря на кластеризацию? Врубаем кэш - получаем проблему консистентности, а если "умный" кэш, который решает эту проблему? Тогда встает вопрос его прогрева, но это тоже решаемая задача. Собственно, так, ход за ходом, был презентован проект tarantool, который является тем самым кэшем, который решает все проблемы. Его можно использовать как кэш или как отдельную БД в памяти. Затем Антон и Владимир рассказали о примерах использования tarantool в жизни.
Ускоряем исследования с помощью конкурсов: как их готовить и выигрывать - Иван Гуз и Михаил Трофимов
В этом докладе я узнал о таких проектах, как https://www.kaggle.com/, на которых сотни команд соревнуются между собой в исследовательских конкурсах. Если у вас есть сложная исследовательская задача, например, научиться распознавать номера телефонов на watermark фотографий, как это нужно было avito, то вероятно будет проще занять этим несколько сотен команд и заплатить победителю, чем тратить годы исследований своим специалистам. Первая часть доклада была посвящена тому, как составлять конкурсы, чтобы получить результат. Для этого нужно придерживаться следующих принципов:
В этом докладе я узнал о таких проектах, как https://www.kaggle.com/, на которых сотни команд соревнуются между собой в исследовательских конкурсах. Если у вас есть сложная исследовательская задача, например, научиться распознавать номера телефонов на watermark фотографий, как это нужно было avito, то вероятно будет проще занять этим несколько сотен команд и заплатить победителю, чем тратить годы исследований своим специалистам. Первая часть доклада была посвящена тому, как составлять конкурсы, чтобы получить результат. Для этого нужно придерживаться следующих принципов:
- Задача должна быть рассчитана на срок не более двух месяцев, чтобы избежать слишком сложных моделей, которые с большой вероятностью не будут правильно работать
- Необходимо максимально делиться исходными данными, для полного понимания задачи участниками конкурса
- Выборку нужно делить минимум на три части: для обучения, для тестирования решений и одну для финального экзамена. Финальная выборка нужна чтобы отсечь тех, которые приспособили свое решение именно к тестируемой выборке.
- По той же причине можно ограничить количество коммитов за определенный промежуток времени.
- Надо правильно составлять выборку и не оставлять утечек информации. Как можно ошибиться? Например, положительные результаты можно создавать в один день, а отрицательные в другой. Конкурсантам останется лишь предоставить вам 100% работающий на вашей выборке, но никому не нужный алгоритм.
- Не нужно ждать готовых решений, нужно ждать идей. Реализовывать все равно придется все самому.
Frontera: распределенный робот для обхода веба в больших объемах - Александр Сибиряков
Здесь яразмечтался надеялся услышать о неком инструменте, который практически из коробки позволит мне обойти большой объем веба, но на деле оказалось все не так просто. Александр подробно рассказал о внутренностях проекта, о том, с какими сложностями пришлось столкнуться и как они были решены. К сожалению, хоть проект и open source, но нельзя просто так взять и запустить обход, это не коробочный проект.
Здесь я
Как подготовиться к гигабитной DDoS-атаке при помощи машинного обучения - Константин Игнатов
Константин довольно увлекательно рассказывал о том, как обучить машину защищаться от DDos атак вместо человека. Дело в том, что злоумышленники атакуют с помощью роботов, а защищаться приходится человеку, стоимость работы которого дороже, поэтому часто случаются поражения. Чтобы обучить робота, необходимо выполнить подготовительные действия, которые далеко не тривиальны, например, получить лог во время Ddos атаки. Причем не стоит забывать о различных пиковых нагрузках, которые могут быть восприняты как атаки. Простой пример: магазины перед новым годом. Все проблемы в совокупности делают задачу очень сложной, тем не менее, Константин рассказал о своих успехах в этой области.
Константин довольно увлекательно рассказывал о том, как обучить машину защищаться от DDos атак вместо человека. Дело в том, что злоумышленники атакуют с помощью роботов, а защищаться приходится человеку, стоимость работы которого дороже, поэтому часто случаются поражения. Чтобы обучить робота, необходимо выполнить подготовительные действия, которые далеко не тривиальны, например, получить лог во время Ddos атаки. Причем не стоит забывать о различных пиковых нагрузках, которые могут быть восприняты как атаки. Простой пример: магазины перед новым годом. Все проблемы в совокупности делают задачу очень сложной, тем не менее, Константин рассказал о своих успехах в этой области.
Как строить архитектуру для отказоустойчивой службы такси - Минкин Андрей
Это доклад о том, как удалось перевести службу такси на новую архитектуру, чтобы уменьшить количество операторов и время доставки машины. Слушатели были удивлены целым зоопарком технологий для такого проекта, но Андрей подробно рассказывал как они приходили к каждому решению. Благодаря этому, теперь, такси в Бишкеке работает гораздо лучше. (убера там пока нет).
Это доклад о том, как удалось перевести службу такси на новую архитектуру, чтобы уменьшить количество операторов и время доставки машины. Слушатели были удивлены целым зоопарком технологий для такого проекта, но Андрей подробно рассказывал как они приходили к каждому решению. Благодаря этому, теперь, такси в Бишкеке работает гораздо лучше. (убера там пока нет).
Docker в работе: взгляд на его использование в Badoo через год - Антон Турецкий
Во время выступления этого докладчика в зале не было свободных мест, а некоторым приходилось слушать его стоя. Уровень доклада был довольно высоким, видно, что рассчитан на людей, которые с докером интенсивно работали. Антон рассказывал про различные особенности, грабли, на которые пришлось наступить и то, как их можно исправлять. Я же с докером совсем не работал, и наверное, зря пошел на этот доклад.
Во время выступления этого докладчика в зале не было свободных мест, а некоторым приходилось слушать его стоя. Уровень доклада был довольно высоким, видно, что рассчитан на людей, которые с докером интенсивно работали. Антон рассказывал про различные особенности, грабли, на которые пришлось наступить и то, как их можно исправлять. Я же с докером совсем не работал, и наверное, зря пошел на этот доклад.
Скорость с доставкой до пользователя - Анатолий Орлов и Денис Нагорнов
Как видно из названия, в этом докладе был сделан акцент на то, что даже если на сервере все работает быстро, это не значит, что на клиенте страница будет так же быстро отображаться. Чтобы это оптимизировать, нужно уметь измерять время на клиенте. Часть доклада была посвящена инструментам, как это делать. Один из советов по оптимизации был обратить внимание на протокол. Например, https несмотря на время на рукопожатия работает быстрее http, потому что не сканируется антивирусом.
Как видно из названия, в этом докладе был сделан акцент на то, что даже если на сервере все работает быстро, это не значит, что на клиенте страница будет так же быстро отображаться. Чтобы это оптимизировать, нужно уметь измерять время на клиенте. Часть доклада была посвящена инструментам, как это делать. Один из советов по оптимизации был обратить внимание на протокол. Например, https несмотря на время на рукопожатия работает быстрее http, потому что не сканируется антивирусом.
Высоконагруженная отправка push-уведомлений - Алексей Акулович
Этот доклад был вне расписания в обеденное время, тем не менее он собрал больше, чем полный зал слушателей. Алексей из Вконтакте рассказал об архитектуре отправки push сообщений, которую они у себя используют. Собственно, практически каждый это может наблюдать, как это все хорошо и стабильно работает, если только он не владелец windows phone. Это связано с косяками API для push сообщений у microsoft.
Chronicle Map — key-value хранилище для трейдинга на Java - Левентов Роман
Роман рассказывал о разработке финансовых приложений, где прибыль критично зависит от скорости доступа к данным. Помимо презентации своей разработки Chronicle Map и сравнения с аналогами, было рассказано, почему может быть выгодно разделить jvm на несколько штук. Дело в том, что сборка мусора блокирует все процессы, поэтому удобно выделить в отдельную jvm критический функционал, который не генерирует мусора и соответственно, не будет останавливаться. Также было произведено сравнение производительности Unsafe с JNI, в котором первый порвал второго.
Роман рассказывал о разработке финансовых приложений, где прибыль критично зависит от скорости доступа к данным. Помимо презентации своей разработки Chronicle Map и сравнения с аналогами, было рассказано, почему может быть выгодно разделить jvm на несколько штук. Дело в том, что сборка мусора блокирует все процессы, поэтому удобно выделить в отдельную jvm критический функционал, который не генерирует мусора и соответственно, не будет останавливаться. Также было произведено сравнение производительности Unsafe с JNI, в котором первый порвал второго.
Производительность WebGL-приложений - Дмитрий Кирилл
WebGL приложения, это клиентские приложения, которые частично исполняются на видеокарте через js API. Дмитрий делился опытом по работе с WebGl для Яндекс.Панорама. Главный показатель производительности, за который стоит бороться - это fps. Для ускорения таких приложений были даны советы такие как: осторожно использовать синхронные методы, которые могут заблокировать контекст, не допускать рисование поверх и откладывать тяжелые операции на "свободное" время (когда пользователь ничего не запрашивает).
WebGL приложения, это клиентские приложения, которые частично исполняются на видеокарте через js API. Дмитрий делился опытом по работе с WebGl для Яндекс.Панорама. Главный показатель производительности, за который стоит бороться - это fps. Для ускорения таких приложений были даны советы такие как: осторожно использовать синхронные методы, которые могут заблокировать контекст, не допускать рисование поверх и откладывать тяжелые операции на "свободное" время (когда пользователь ничего не запрашивает).
Эффективные алгоритмы поиска подобных объектов для терабайтов данных - Евгений Журин
Это был завершающий доклад второго дня конференции, в котором подробно был описан алгоритм поиска похожих пользователей. Была дана большая база профилей и профили "хороших" пользователей. Перед командой стояла задача найти еще "хороших" пользователей. Профиль пользователя состоял из посещенных им ресурсов. Первой задачей был выбор расстояния, т.е. как численно определять похожесть пользователей. Вторая часть задачи посвящена непосредственно отбору и также была описана в докладе.
Это был завершающий доклад второго дня конференции, в котором подробно был описан алгоритм поиска похожих пользователей. Была дана большая база профилей и профили "хороших" пользователей. Перед командой стояла задача найти еще "хороших" пользователей. Профиль пользователя состоял из посещенных им ресурсов. Первой задачей был выбор расстояния, т.е. как численно определять похожесть пользователей. Вторая часть задачи посвящена непосредственно отбору и также была описана в докладе.
Комментариев нет :
Отправить комментарий