Сдавая веб-сервер в повседневную эксплуатацию, нужно быть уверенным, что он выдержит планируемую нагрузку. Как понять, что код написанный разработчиками выдержит запланированный наплыв посетителей? И что важнее, как понять какой при этом будет запас мощности?
Необходимо провести тест производительности сайта, чтобы выявить потенциально узкие места и наметить планы по их рефакторингу. Рассмотрим методологию тестирования.
РИТ-2013: Доклад о решениях по асинхронной обработке данных, внедреннных в Мамбе. 1) собственный Comet-сервер, 2) Неудачное внедрение Gearman, 3) RabbitMQ: основы работы, тонкости и особенности внедрения.
Сдавая веб-сервер в повседневную эксплуатацию, нужно быть уверенным, что он выдержит планируемую нагрузку. Как понять, что код написанный разработчиками выдержит запланированный наплыв посетителей? И что важнее, как понять какой при этом будет запас мощности?
Необходимо провести тест производительности сайта, чтобы выявить потенциально узкие места и наметить планы по их рефакторингу. Рассмотрим методологию тестирования.
РИТ-2013: Доклад о решениях по асинхронной обработке данных, внедреннных в Мамбе. 1) собственный Comet-сервер, 2) Неудачное внедрение Gearman, 3) RabbitMQ: основы работы, тонкости и особенности внедрения.
Защищаемость от DDoS на этапе проектирования системы / Рамиль Хантимиров (Sto...Ontico
HighLoad++ 2017
Зал «Пекин + Шанхай», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2891.html
- Защищаемость системы от DDoS (Protectability - The ability to receive protection) - это важный параметр, которому стоит уделять внимание при проектировании. В настоящее время он не сформулирован в явном виде, однако сильно влияет на дальнейшую судьбу системы, особенно если она подвержена риску DDoS-атак.
- Уже на этапе проектирования можно обезопасить себя и заложить в систему такие элементы, которые облегчат и повысят эффективность защиты системы от DDoS-атак в будущем.
...
Доклад об очередях сообщений / задач, прочитанный на конференции YAPC::Russia 2015, в котором описываются методы построения очередей и принципы протокола AMQP
Как балансировать на «сетевом» канате под куполом тяжелой нагрузки? / Сергей ...Ontico
Цель доклада – рассмотреть и систематизировать информацию о том, как балансировка нагрузки помогает делать миллионы людей счастливыми, сохраняя им нервные клетки, спасает беззащитные ПК и прочие девайсы от приступов ярости их владельцев во время бесконечных загрузок сайтов, а посетителям онлайн магазинов не дает побросать их виртуальные корзинки в бесконечных очередях на кассе.
Вашему вниманию будет представлен небольшой сравнительный анализ методов балансировки трафика, мы рассмотрим плюсы и минусы каждой схемы. Я расскажу, к каким хитростям можно прибегать, минуя большие затраты на покупку готовых решений и получая максимум профита от существующей инфраструктуры.
Доклад будет полезен всем, кто хочет знать, но боится спросить, благодаря чему HighLoad-проекты такие устойчивые и надежные. Тема наверняка заинтересует тех, кто только начинает свои шаги на пути к уверенному и высокопроизводительному сервису.
Тезисы доклада:
1. Что такое балансировка и зачем она вообще нужна? Когда хорошо бы об этом задуматься?
2. Реализация балансировки: виды, способы, практики.
3. Методы локальной балансировки
3.1. Балансировка на канальном уровне (L2-метод)
• Используем отдельным балансировщик
• Сократим расходы, избавимся от выделенного балансировщика
• Плюсы и минусы
3.2. Балансировка на сетевом уровне (L3-метод)
• Преимущества и недостатки
4. Методы глобальной балансировки
4.1. DNS балансировка.
• DNS Round Robin
• Сильные и слабые стороны подхода
4.2. HTTP Redirect
• Механизм балансировки на основе Redirect запросов
• Плюсы и минусы метода
4.3. Балансировка на базе Anycast
• Когда Anycast – это хорошо, а когда - не очень?
5. Некоторые не менее расп
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного se...Sergey Xek
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного server-side API десктопного приложения. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
SETCON'18 - Dzmitry Nichyparuk - Designing reliable softwareNadzeya Pus
По-настоящему надежное программное обеспечение всегда скептически настроено и готово к отказам. Другие системы оно держит на расстоянии, так как слишком тесное взаимодействие может быть небезопасным. Оно не доверяет даже себе устанавливая внутренние барьеры для защиты от сбоев.
История небольшого успеха с PostgreSQL – Владимир БородинYandex
В докладе речь пойдёт о том, как в Яндекс.Почту для хранения метаданных сборщиков внедрили PostgreSQL. Владимир расскажет, зачем и почему это сделали и каким образом решили масштабироваться. А также о репликации и средствах обеспечения отказоустойчивости, о возникших проблемах и способах их решения.
Защищаемость от DDoS на этапе проектирования системы / Рамиль Хантимиров (Sto...Ontico
HighLoad++ 2017
Зал «Пекин + Шанхай», 8 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/2891.html
- Защищаемость системы от DDoS (Protectability - The ability to receive protection) - это важный параметр, которому стоит уделять внимание при проектировании. В настоящее время он не сформулирован в явном виде, однако сильно влияет на дальнейшую судьбу системы, особенно если она подвержена риску DDoS-атак.
- Уже на этапе проектирования можно обезопасить себя и заложить в систему такие элементы, которые облегчат и повысят эффективность защиты системы от DDoS-атак в будущем.
...
Доклад об очередях сообщений / задач, прочитанный на конференции YAPC::Russia 2015, в котором описываются методы построения очередей и принципы протокола AMQP
Как балансировать на «сетевом» канате под куполом тяжелой нагрузки? / Сергей ...Ontico
Цель доклада – рассмотреть и систематизировать информацию о том, как балансировка нагрузки помогает делать миллионы людей счастливыми, сохраняя им нервные клетки, спасает беззащитные ПК и прочие девайсы от приступов ярости их владельцев во время бесконечных загрузок сайтов, а посетителям онлайн магазинов не дает побросать их виртуальные корзинки в бесконечных очередях на кассе.
Вашему вниманию будет представлен небольшой сравнительный анализ методов балансировки трафика, мы рассмотрим плюсы и минусы каждой схемы. Я расскажу, к каким хитростям можно прибегать, минуя большие затраты на покупку готовых решений и получая максимум профита от существующей инфраструктуры.
Доклад будет полезен всем, кто хочет знать, но боится спросить, благодаря чему HighLoad-проекты такие устойчивые и надежные. Тема наверняка заинтересует тех, кто только начинает свои шаги на пути к уверенному и высокопроизводительному сервису.
Тезисы доклада:
1. Что такое балансировка и зачем она вообще нужна? Когда хорошо бы об этом задуматься?
2. Реализация балансировки: виды, способы, практики.
3. Методы локальной балансировки
3.1. Балансировка на канальном уровне (L2-метод)
• Используем отдельным балансировщик
• Сократим расходы, избавимся от выделенного балансировщика
• Плюсы и минусы
3.2. Балансировка на сетевом уровне (L3-метод)
• Преимущества и недостатки
4. Методы глобальной балансировки
4.1. DNS балансировка.
• DNS Round Robin
• Сильные и слабые стороны подхода
4.2. HTTP Redirect
• Механизм балансировки на основе Redirect запросов
• Плюсы и минусы метода
4.3. Балансировка на базе Anycast
• Когда Anycast – это хорошо, а когда - не очень?
5. Некоторые не менее расп
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного se...Sergey Xek
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного server-side API десктопного приложения. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
SETCON'18 - Dzmitry Nichyparuk - Designing reliable softwareNadzeya Pus
По-настоящему надежное программное обеспечение всегда скептически настроено и готово к отказам. Другие системы оно держит на расстоянии, так как слишком тесное взаимодействие может быть небезопасным. Оно не доверяет даже себе устанавливая внутренние барьеры для защиты от сбоев.
История небольшого успеха с PostgreSQL – Владимир БородинYandex
В докладе речь пойдёт о том, как в Яндекс.Почту для хранения метаданных сборщиков внедрили PostgreSQL. Владимир расскажет, зачем и почему это сделали и каким образом решили масштабироваться. А также о репликации и средствах обеспечения отказоустойчивости, о возникших проблемах и способах их решения.
Высоконагруженные трейдинговые системы и их тестирование Iosif Itkin
Доклад посвящен особенностям технологических платформ, используемых брокерами и биржами.
В докладе рассматриваются следующие темы:
Балансировка нагрузки, отказоустойчивость и узкие места производительности трейдинговых систем;
Способы оптимизации времени отклика и пропускной способности системы;
Аппаратное ускорение с использованием Infiniband, FPGA, Overclocking, GPU и TOE;
Особенности моделирования нагрузки для биржевых систем;
Требования к генераторам нагрузки и другим инструментам, используемым при тестировании трейдинговых систем.
Целевая аудитория
Широкий круг специалистов, работающих с высоконагруженными системами.
Слушатели смогут сопоставить особенности архитектуры, методов ускорения и тестирования систем особого типа (биржевых площадок) с системами, над которыми они работают (например, высоконагруженными интернет-сервисами).
This document discusses improving MySQL application performance with Sphinx. It provides an introduction to Sphinx, describing it as a standalone full-text search engine that can be scaled horizontally and has many features beyond full-text search. It explains that Sphinx indexes data separately from MySQL and must be queried separately, though it can return attribute values to MySQL. The document outlines important facts about MySQL's index usage and limitations, and Sphinx's grouping, attribute storage, and block-based data organization to optimize attribute filtering. It provides an example comparing full-text search performance between MySQL and Sphinx.
The document discusses Rakudo Perl 6, the most actively developed compiler for the Perl 6 programming language. It describes how Rakudo works by parsing source code into an abstract syntax tree, then generating intermediate code for the Parrot Virtual Machine. The document provides examples of everyday programming problems and how to solve them in Perl 6, such as reading input, checking value ranges, adding numbers in a list, and iterating over lists.
UI testing involves verifying that a graphical user interface functions as expected. There are different approaches to test automation, including record and replay, coding tests, and using test libraries. The effectiveness of test automation depends on how tests are designed and maintained over time as the application evolves.
4. DNS Round Robin
Плюсы:
●
Не зависит от протокола высокого уровня
●
Не зависит от нагрузки
●
Не требует дополнительных ресурсов
●
Не требует связи между серверами
●
Низкая стоимость решения
Минусы:
●
Возможно неравное распределение нагрузки (например при наличии
клиентов на Windows Vista)
●
Сложно отключать не отвечающие сервера
●
На практике максимальное число IP-адресов ограничивается размером
UDP пакета в DNS
5. А можно по-другому?
Можно:
●
Используем короткий TTL
●
Выдаем по одной записи на каждый DNS запрос
Плюсы:
●
Отсутствие неравномерности при небольшом числе
серверов
Минусы:
●
Малый TTL записей (больше нагрузка на DNS)
●
Принудительное кеширование на DNS серверах
8. Балансировка на 2-ом уровне
Плюсы:
●
Не зависит от протокола высокого уровня
●
Есть методы без выделенного балансировщика
●
Есть возможность пускать ответы мимо
балансировщика
●
Относительное малое потребление ресурсов
Минусы:
●
Сервера должны находиться в одном сегменте сети
●
Необходима специфическая настройка серверов и
сетевого оборудования
10. Балансировка на 3-ем уровне
Плюсы:
●
Не зависит от протокола высокого уровня
Минусы:
●
Обратный трафик от серверов должен проходить через
балансировщик
12. Проксирование
Плюсы:
●
Позволяет делать привязку клиента к серверу
●
Позволяет распределять разные типы запросов по
разным серверам
●
Возможность модификации запроса/ответа,
возможность кеширования ответов
Минусы:
●
Относительно большое потребление ресурсов
●
Протоколозависимость