Вопросы проектирования для поддержки около 400+ одновременно работающих пользователей в веб-приложении

Question

Я нахожусь в начале проекта asp.net c # среднего размера и с требованием к производительности приложения, чтобы иметь возможность поддерживать около 400+ одновременно работающих пользователей.

Что нужно иметь в виду при разработке приложения для соответствия таким стандартам производительности и доступности? Страница должна быть подана менее чем за 5 секунд. Я планирую разместить приложение и базу данных на отдельных физических машинах. С точки зрения кодирования и многоуровневого применения: -

• Если уровень базы данных открыт для уровня приложения через Служба WCF, это будет препятствовать производительности? Должен ли я использовать прямой вместо tcp соединения?
• Будет ли иметь значение, если я использую Entity Framework или какой-либо другой ORM или блок данных корпоративной библиотеки?
• Должен ли я регистрировать исключения в базе данных или текстовом файле?
• Как проверить во время разработки, будет ли создаваемый код в конечном итоге соответствовать этим стандартам производительности? Или это даже вопрос, о котором мне нужно беспокоиться на этапе разработки?
• Нужно ли помещать код подключения к моей базе данных и другие классы, содержащие справочные данные, которые редко меняют в течение срока службы приложения, в статические классы, чтобы он был доступен в течение всего срока службы приложения?
• Какую политику кэширования следует применять?
• Какие бесплатные инструменты я могу использовать для измерения и тестирования производительности? Я знаю инструменты для измерения производительности Red-Gate, но у них высокая стоимость лицензий, поэтому я бы предпочел бесплатные инструменты.

Прошу прощения, если этот вопрос слишком открытый. Любые советы или мысли о том, как мне поступить?

Спасибо за ваше время.

Answer 1

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

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

ORM действительно могут привести к снижению производительности в вашем приложении.Это связано с тем, что у вас меньше контроля над сгенерированными SQL-запросами, что затрудняет их настройку.Это не значит, что вы не должны использовать ORM.Нужно просто быть осторожным с тем, какой SQL он плюет, и настроить его с вашим администратором БД.Существуют также легкие ORM, такие как dapper , PetaPoco и Massive , которые вы можете рассмотреть.

Что касается статических классов, онине улучшит производительность по сравнению с классами экземпляров.Создание экземпляра класса в CLR - довольно быстрая операция, как Айенде объясняет .Статические классы обеспечат тесную связь между уровнем доступа к данным и уровнем потребления.Так что на данный момент вы можете забыть о статических классах.

Для регистрации ошибок я бы порекомендовал вам ELMAH .

Для тестирования производительности достаточно много инструментов, Apanche Bench прост в использовании.

Answer 2

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

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

Во-первых, вам нужно превратить целевой показатель производительности в числа, которые вы можете измерить; для веб-приложений это обычно «динамические запросы страниц в секунду». 400 одновременно работающих пользователей, вероятно, не все запрашивают страницы в одно и то же время - они обычно тратят некоторое время на чтение страницы, заполнение форм и т. Д. С другой стороны, AJAX-ориентированные сайты запрашивают намного больше динамических страниц.

Используйте Excel или что-то еще для работы от пиковых одновременных пользователей до динамических генераций страниц в секунду, основанных на времени ожидания, запросах на взаимодействие и построении в буфере - я обычно перерасход на 50%.

Например:

400 одновременно работающих пользователей с продолжительностью сеанса 5 взаимодействий и 2 динамические страницы на взаимодействие означают 400 * 5 * 2 = 4000 запросов страниц.

При времени ожидания 30 секунд эти запросы будут распределены в течение 30 * 5 = 150 секунд.

Таким образом, среднее число запросов страниц в секунду составляет 4000/150 = 27 запросов в секунду.

При 50% буфере вам необходимо поддерживать пиковую скорость примерно 40 запросов в секунду.

Это не тривиально, но ни в коем случае не исключение.

Затем настройте среду тестирования производительности, характеристики которой вы полностью понимаете и можете реплицировать, а также можете сопоставить с производственной средой. Я обычно не рекомендую воссоздавать производство на этом этапе. Вместо этого сократите количество поколений страниц / второй тест, чтобы соответствовать среде тестирования производительности (например, если у вас 4 сервера в работе и только 2 в среде тестирования производительности, уменьшите вдвое).

Как только вы начинаете разработку, регулярно (не реже одного раза в неделю, в идеале каждый день) развертывайте свою незавершенную работу в этой среде тестирования. Используйте генератор нагрузочных тестов (для меня работают Apache Benchmark или Apache JMeter), пишите нагрузочные тесты, имитирующие типичные поездки пользователей (но без времени ожидания), и запускайте их в своей среде тестирования производительности. Измерьте успех, выбрав целевой целевой показатель «количество поколений страниц в секунду». Если вы не достигли отметки, выясните, почему (профилировщик ANTS от Redgate - ваш друг!).

Когда вы приблизитесь к концу проекта, попробуйте создать тестовую среду, которая ближе к производственной системе с точки зрения инфраструктуры. Разверните свою работу и повторно запустите тесты производительности, увеличив нагрузку, чтобы отразить «реальные» требования страниц в секунду. На этом этапе у вас должно быть хорошее представление о характеристиках производительности приложения, поэтому вы действительно проверяете только свои предположения. Как правило, гораздо сложнее и дороже получить такую ​​«производственную» среду, и обычно намного сложнее вносить изменения в программное обеспечение, поэтому вы должны использовать это исключительно для проверки, а не для выполнения обычной работы по проектированию производительности.