Определение количества поддерживаемых пользователей для веб-приложения

Question

Я разрабатываю веб-приложение asp.net, ориентированное на бизнес-клиентов. Может ли кто-нибудь дать некоторые рекомендации о том, как я могу определить количество пользователей, которых может поддерживать мое приложение?

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

Answer 1

Вы можете использовать сервер состояния сеанса, работающий во втором сеансе или sql-сервере, поддерживающем сеансы, чтобы обойти проблему с одним ящиком.

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

Answer 2

Знаете ли вы, что сеанс может быть создан для работы с несколькими веб-серверами очень просто, переместив его в базу данных sql-сервера.

Беглый как можно here

Что касается исходного вопроса, я хотел бы посмотреть на нагрузочное тестирование. Надеюсь, будут другие плакаты, которые знают об этом больше. Я бы сосредоточил внимание на просмотрах страниц, в отличие от пользователей.

Answer 3

Измерьте ресурсы (ЦП, память, диск, пропускную способность), необходимые для типичных действий в вашем приложении. Разделите доступные ресурсы ресурсами, необходимыми для пользовательской «сессии», и у вас есть приблизительный номер.

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

Answer 4

Хороший балансировщик нагрузки может гарантировать, что пользователь вернется на тот же сервер.

Answer 5

Только вы/ваша команда можете определить точные номера, которые могут быть поддержаны.

Ваш ключ к пониманию вашего проблемного домена и четкое разделение уровней обработки.

Разделение позволяет изолировать узкие места и настраивать производительность самого низкого коэффициента производительности намного легче, а затем перейти к следующему уровню/ограничению производительности.

Не делайте предположений, так как вы найдете влияние, не связанное с вашими предположениями, которые могут вас удивить.

1. дизайн в масштабе
2. Design, чтобы иметь отдельные «слои» по соображениям настройки производительности, а также собственное здравомыслие - это также лучший принцип конструкции, и это непосредственно, одна из причин развития сегментирован.
3. Испытание - конструкция испытания «прохождение/сбой» слоев на конструктивную спецификацию - это только один аспект тестирования. На ваш вопрос отвечает влияние технологии, архитектуры и инструментов, которые вы предпочитаете использовать в своем приложении. Планируйте внести изменения в каждую часть вашего приложения для решения проблем производительности.
4. Собрать показатели производительности с каждого слоя, настроить каждый уровень, как вы делаете открытия прироста производительности.Планируйте и узнайте, как количественно оценить производительность каждого слоя.
5. Вы должны в какой-то момент выполнить компромисс между характеристиками и «круто/вау». Каждый из них повлияет на вашу способность продавать ваше решение, и вы должны определить, какое из них будет иметь наибольшее влияние.

Это один из PAIN факторов, которые я использую для измерения качества в конструкциях - Р LAN LL Я ncremental N eeds и в другом месте и Рассматриваются: в блогах.

Лично я часто принимаю решения по дизайну, основанному на производительности, но ваша маркетинговая стратегия может отличаться.