Блог

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

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

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

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

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

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

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

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

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

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

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

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

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

Во-первых, вам нужно преобразовать вашу целевую производительность в числа, которые вы можете измерить; для веб-приложений это обычно «динамические запросы страниц в секунду». 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 profiler от Redgate — ваш друг!).

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