Сколько запросов в секунду должно обрабатывать мое приложение asp (class)

Question

Я профилирую asp (классический) веб-сервис. Веб-служба выполняет вызовы из базы данных, читает / записывает в файлы и обрабатывает XML. На компьютере под управлением Windows Server 2003 (2,7 ГГц, 4 ядра, 4 ГБ ОЗУ) сколько запросов в секунду я должен обрабатывать до того, как что-то начнется.

Я создаю инструмент для проверки этого, но я ищу количество запросов в секунду, по которым нужно стрелять.

Я знаю, что это довольно расплывчато, но, пожалуйста, дайте наилучшую оценку. Если вам нужна дополнительная информация, пожалуйста, спросите.

Answer 1

95% производительности любого приложения, управляемого данными, зависит от базы данных: 1) способ выполнения ваших вызовов, 2) индексы, 3) оборудование под базой данных (в частности, дисковая подсистема).

Я видел, как машина, как вы описываете, обрабатывает 40 запросов в секунду (2500 / минута), но более частыми являются числа типа 10 в секунду (600 / минута).Я ожидал бы еще ниже, если вы работаете с БД на той же машине, и еще ниже, если эта БД - SQLExpress или MSAccess.

Кроме того, при загрузке ваше приложение, вероятно, не выйдет из строя, но IIS поставит в очередьзапросов, как только он будет насыщен, и может истечь некоторые из этих запросов по таймауту, если он не сможет их обслуживать до истечения времени ожидания.

Кстати, вместо того, чтобы создавать инструмент для тестирования вашего приложения, вы можете захотеть изучитьиспользуя инструмент тестирования, такой как Microsoft WCAT.Он довольно гладкий и простой в использовании.

Answer 2

Да, я бы также сказал, что 10 в секунду - это хороший тест. Для высокопроизводительного приложения вы хотели бы получить больше, чем это, но если у вас нет конкретной цели, вы, как правило, сможете получать не менее 10 запросов в секунду для общей веб-страницы с кучей запросов к базе данных.

Answer 3

Как быстро это должно быть?Достаточно быстро.

Насколько быстро достаточно быстро?Это вопрос, на который могут ответить только вы и ваши пользователи.Если ваш сервис ужасно неэффективен и идет в ногу со спросом, он достаточно быстр.Если ваш сервис оптимизирован для сборки, молниеносен и перегружен запросами, он недостаточно быстр.

Если сервер обрабатывает свою фактическую рабочую нагрузку, не беспокойтесь о том, насколько быстро он «должен» быть,Когда на сервере возникают проблемы, или когда вы ожидаете, что это скоро произойдет, вам следует подумать об улучшении кода или обновлении аппаратного обеспечения.Помните закон Кнута - преждевременная оптимизация - корень всего зла.Любая работа, которую вы делаете сейчас, чтобы ускорить ее, может никогда не окупиться, и вы можете быть вынуждены идти на компромиссы с гибкостью или ремонтопригодностью.Также помните старую пословицу - если она не сломана, не исправляйте ее.