Оптимизирован ли DataSnap для одновременного реагирования более чем на 1 тыс. Пользователей?
Мы хотим запустить большое многоуровневое приложение. Приложение на стороне сервера должно одновременно отвечать более чем 1000 пользователям. Мы хотим создать серверное приложение на 64-битном компиляторе и на стороне клиента с 32-битным. В этом случае мы не знаем, DataSnap может ответить на все клиенты без каких-либо проблем или нет? В этом случае серверный компьютер является очень мощным (многопроцессорным и более 16 ГБ ОЗУ), а системой управления базами данных является FireBird 2.5.
3 ответа
Вам нужен способ выполнить реалистичные нагрузочные тесты.
Для базы данных Firebird вы можете моделировать одновременных пользователей с помощью бесплатного инструмента Apache JMeter. Он может запускать операторы SQL и записывать их статистику времени выполнения (среднее, минимальное / максимальное и т. Д.). Таким образом, вы можете, например, создать группу потоков с двадцатью различными запросами SQL, а затем запустить двадцать потоков, каждый из которых будет выполнять эти запросы последовательно.
JMeter позволяет определять ограничения времени для запроса SQL, и JMeter рассматривает его как ошибку, если запрос превышает этот предел. Затем вы можете попытаться найти максимальное число клиентов, где общая частота ошибок все еще меньше (например) пяти процентов.
Но вам также необходимо знать, насколько высокой будет ожидаемая загрузка базы данных, и вам также понадобится тестовая база данных с реалистичным размером, а не только несколько записей. Кроме того, некоторые запросы к базе данных, такие как отчеты, могут вызывать более высокую нагрузку - они также должны быть включены в симуляцию, поскольку они могут повлиять на общую производительность. В JMeter вы можете создать вторую группу потоков, работающую параллельно с первой, для этих долгосрочных операторов с различными настройками (меньше симулированных клиентов).
Тестирование базы данных покажет, есть ли уже узкое место в этой области. Например, результатом теста может быть то, что база данных может обслуживать двадцать клиентов с общей средней скоростью транзакций 20 TPS (транзакций в секунду), что означает, что один клиент выполняет одну транзакцию в секунду. Но это значение TPS будет уменьшаться с увеличением количества пользователей.
Смежный вопрос: использование Firebird в больших проектах, где также есть ссылка на http://www.firebirdsql.org/en/case-studies-catalog/
Относительно моделирования нагрузки клиента DataSnap: это можно сделать с помощью скриптового клиента, который выполняет предопределенный набор операторов / команд по соединению. Для одновременного запуска большого количества клиентов с нагрузочным тестированием вы можете использовать сервис, такой как Amazon Elastic Compute Cloud ( EC2), для запуска клонов образа тестового компьютера, что экономит ваши затраты на оборудование. Но, конечно, я бы начал с небольшой клиентской машины, которая просто запускает десять или двадцать скриптовых клиентов.
Насколько я знаю, DataSnap основан на Indy. И модель обработки соединений Indy не очень масштабируема - один поток на соединение, что требует очень много ресурсов. Я думаю, что даже использование пулов потоков Indy не вариант... Также в Windows (32-разрядная версия), например, существует ограничение на максимальное количество потоков, которые вы можете создать (2000 IIRC). В любом случае - использование большого количества потоков нехорошо и снижает производительность сервера (для справки - книга Windows Internals, блог Windows Performance Team и т. Д.)
Масштабируемый, надежный и профессиональный сервер приложений будет использовать порты IO Completion (IOCP) для обработки данных. Но я не знаю, сможет ли DataSnap воспользоваться этим.
ОБНОВЛЕНИЕ: На CodeRage7 я задавал похожие вопросы о масштабируемости. Вот ответы:
Вопрос: Недавно в Stackru возник вопрос о масштабируемости / производительности DataSnap. Так может ли DS обрабатывать, например, 2000 или более параллельных пользовательских запросов на уровне сети и приложений?
О: масштабируемость основана на масштабируемости TCP/HTTP/HTTP и количестве соединений, разрешенных в операционной системе вашего сервера. Также основано на используемой памяти и оборудовании. В DataSnap нет особых ограничений.
Мой комментарий: Хотя это так, модель обработки соединений Indy, то есть один поток на соединение, создает узкое место, особенно в 32-битной Windows (максимум 2000 потоков). В Win64 это не должно быть такой большой проблемой, но опять-таки - такая обработка потока данных приводит к снижению производительности.
Вопрос: поддерживает ли DataSnap какое-то распределение нагрузки?
A: Не напрямую. Вы можете сделать это в коде на вашем сервере (ах) DataSnap.
Мой комментарий: я нашел очень хорошую статью о реализации Failover/Load Balancing в DataSnap в блоге Андреано Лануссе
Вопрос: Поддерживает ли DataSnap порты завершения ввода-вывода для лучшей масштабируемости?
Этот мой вопрос остался без ответа.
Надеюсь это поможет!
UPDATE2:
Я нашел очень интересную статью о производительности DS: анализ DataSnap на основе тестов скорости и стабильности
Update3:
Когда спецификации для системы сделаны, вы должны быть очень точными, когда речь идет о нескольких пользователях.
Например: вы создаете сайт, и клиент ожидает 15 000 уникальных пользователей. Затем клиент обычно предъявляет требование, чтобы система поддерживала 15.000 одновременных пользователей, что очень наивно.
Вам понадобится более подробная спецификация, чем эта.
Обычно разумнее сказать что-то вроде: в 99% запросов 99% пользователей могут получить ответ на свой запрос в среднем в течение 5 секунд.
При обычном использовании вы никогда не увидите, чтобы все пользователи отправляли запрос в течение одной секунды. Если в какой-то момент они все появятся в одну и ту же минуту (что очень маловероятно), у вас будет намного меньше одновременных пользователей.
Даже для веб-сайтов с десятками тысяч пользователей, где большинство из них подключаются ежедневно, веб-сервер простаивает большую часть времени, и время от времени он переходит на 5%, а в крайних случаях на 20%. Если бы нам действительно приходилось обслуживать всех этих пользователей сразу, мы бы облажались, но этого никогда не произойдет, и нереально подготовить сервер к таким нагрузкам.