Что такое типичное среднее количество сессий ASP.NET за центральный процессор или за память?
(ОТРЕДАКТИРУЙТЕ: переписанный вопрос сделать это более ясным, значение не изменилось),
Вы можете создать приложение и измерить его использование. Но что я хотел бы знать, если Вы решаете заранее о применении ASP.NET, насколько одновременные пользователи (сессии), как правило, вписываются в одну машину.
Давайте предположим, что следующий дефолт упростил установку: сессии Inproc, ASP.NET 3.5, NHibernate + кэширование L2, интернет-магазин (свойства корзины на сессии).
В то время как я мог установить, что сессия не поднимет выше, скажем, 20 КБ, мой опыт показывает мне, что есть огромное верхнее в целом, даже с заявлениями, «хорошо изложенными». Я ищу то простое вычисление, которое Вы можете сделать на липкой ноте.
Для щедрости: какой центральный процессор / Мадам была бы Вы советовать своему управлению для каждого X одновременных пользователей, игнорируя требования пропускной способности. Т.е. и ответ мог быть: на Xeon на 2 ГГц с мадам на 1 ГБ, Win2k8, Вы можете безопасно служить 500 одновременным сессиям, но выше которого он требует тщательного планирования или большего количества hardwarere
4 ответа
Раз уж вы ищете настоящий #, я вам его предоставлю. Мы создаем безопасное приложение для HR с использованием ASP.NET MVC. Как и Вы, мы хотели получить хорошее ощущение для максимальных одновременных соединений, которые мы определили как максимальное # количество обслуживаемых страниц за 10 секунд (предполагается, что пользователь не будет ждать более 10 секунд для страницы).
Так как мы искали верхнюю границу, мы использовали очень простую страницу. SSL + несколько переменных сессии. На четырехъядерном Dual Xeon (всего 8 ядер), с 16 ГБ памяти и SQL Express в качестве бэкэнда, мы смогли ударить ~ 1000 "одновременных" соединений. Ни память, ни SQL Express не были ограничивающим фактором, хотя, в первую очередь, это был процессор и ввода-вывода для нашего теста. Обратите внимание, что мы не использовали кэширование, хотя для корзины я сомневаюсь, что вы бы тоже. Эта страница попала в базу данных ~3 раза, и отправила ~150KB данных (в основном png изображений, не кэшированных). Мы проверили, что было создано 1000 сеансов, хотя каждый из них был небольшим.
Наш POV показывает, что 1000 сеансов, скорее всего, нереалистичны. Тесты, включающие страницы с бизнес-логикой и реальными пользовательскими данными, показали ~200 одновременных пользователей максимум. Однако, некоторые пользователи также будут запускать отчеты, которые могут пережевать целое ядро на срок до 30 секунд. В этом сценарии 9 одновременных отчетов пользователей в принципе могут сделать систему непригодной для других. Это относится и к другим постерным точкам ... вы можете захватить другую производительность # сколько угодно, но ваша система может вести себя совершенно по-другому, основываясь на том, что она делает.
Это во многом зависит от того, сколько работы вы выполняете на сервере. Некоторые приложения могут выставлять сотню, другие - только десятки.
знаете ли вы «качество» кода?
плохой код может стоить очень дорого, в то время как хороший код не может стоить ничего
Обновление на основе комментария
Несколько лет назад мне приходилось поддерживать плохо выполненные приложения, они использовали 500 мегабайт оперативной памяти (иногда 1,5 гигабайта), и мне требовалось несколько минут, чтобы показать материал, мне пришлось переписать все это, и после этого потребовалось только необходимое количество память (почти в 10-15 раз меньше), и он быстро показывал материал, я говорю здесь за миллисекунды.
Количество циклов и плохо кэшированных данных в памяти, которые были выполнены неправильно, было ... невероятно грустно смотреть в. Просто скажу вам, что у меня в памяти было 3 версии целой долбаной базы данных (то есть 4 с реальной базой данных), и код должен был обновлять все версии одну за другой. Все остальное в приложениях было основано на версиях в памяти.
Во всяком случае, в конце концов. Я удалил 25 тысяч строк кода.
Качество кода ЯВЛЯЕТСЯ важным.
второе обновление
обнаружило это, может быть хорошо
третье обновление
В приложении, которое В настоящее время я разрабатываю asp.net 3.5, используя linq to sql, разговаривая (конечно) с sql server 2005. многие читают в db и не так много пишут.
на моей собственной машине dev, которая является старой p4 prescott с 3 гиг барана. загрузка всей страницы занимает в среднем от 20 до 100 мс, в зависимости от того, какая страница: -) сеанс
(использование памяти) очень низкий, наверняка меньше 20 КБ
, если я пойду отсюда, мой плохая математика будет:
Если у меня 100 одновременных пользователей, загрузка страницы займет около 2 секунд, и на время сеанса потребуется не менее 2 мегабайт оперативной памяти.
плохая математика нужна? что вам нужно для 1 пользователя, и из этого просто умножьте 1 пользователя на WhatYouThinkYouShouldBeAbleToHandle
Я не думаю, что есть другой способ узнать. Потому что, опять же, код под страницей имеет значение.
Вы, очевидно, понимаете, что это зависит от приложения, и лучший способ понять, что приложение может делать или поддерживать, - это измерить его. В прошлом я использовал методику анализа транзакционных издержек от Microsoft, чтобы получить достаточно хорошие оценки. В свое время я использовал ее в Site Server Commerce Edition 3.0, а сегодня - в современных приложениях ASP.net, и она довольно хорошо работает.
Эта ссылка - отрывок из книги "Улучшение производительности и масштабируемости приложений .Net" от Microsoft, и в ней подробно описаны формулы, которые вы можете использовать с данными о производительности (использование процессора, счетчика IIS и т.д.) для подсчета количества пользователей, которых вы можете поддерживать на вашем сайте. Я не смог разместить вторую ссылку на книгу, но если вы будете искать scalenet.pdf в Google/Bing, то найдете ее. Надеюсь, это поможет
.