Я запускаю веб-приложение ASP.Net на выделенном сервере и недавно сделал значительное обновление серверного оборудования. К моему удивлению, прироста производительности нет абсолютно.
старый сервер: один xeon x3220 2 гигабайта оперативной памяти База данных Windows 2003 IIs6 работает на отдельном сервере, старый xeon.
новый сервер: 32 гигабайта ram raid 1 0 твердотельных накопителей Windows 2008 Standard IIs7 dual xeon x5660 DB, работающих на той же машине
В новом сервере все значительно лучше, но никаких улучшений. Мы вносим обновления в само веб-приложение, но мне интересно, что можно сделать с точки зрения конфигурации сервера / IIS7, чтобы ускорить этот процесс. Мне кажется невозможным, чтобы это веб-приложение не улучшилось с этим обновлением.
Было ли выполнено обновление сервера, потому что приложение работало недостаточно хорошо?
Да, все, что вы описываете, должно ускорить работу. То, что они не сделали, предполагает ... (резкий аккорд), что проблема масштабируемости не в платформе.
Вам необходимо профилировать свое приложение. IIS может служить лоты запросов в секунду без какой-либо серьезной оптимизации, и маловероятно, что вы бы уже изменили какие-либо настройки по умолчанию (верно?), так что ... это оставляет приложение. Или фреймворк приложения (.Net, верно? Уже установлена компиляция debug = false?)
Поскольку вы сейчас используете IIS 7, я предлагаю в первую очередь искать отслеживание неудачных запросов (установите компонент Tracing), а затем подключите правило, нацеленное на любой код ответа (100-599), получите журнал FREB и посмотрите, где тратится время (для этого подходит компактный вид). Если вы видите, что модуль занимает непропорционально много времени, исследуйте его.
Посмотрите веб-журналы - видите ли вы больше запросов, чем вы думаете? (Удивительно, насколько часто при рассмотрении оптимизации производительности отвечают «да»). К результатам измерения времени указывают, что да, сервер считает, что производительность низкая?
Есть ли на странице javascript? Может ли это быть проблемой восприятия производительности клиента?
Если это не обеспечивает достаточной глубины, посмотрите либо на инструментирование приложения, либо на подключение к нему профилировщика, чтобы определить, на что тратится время.
Дело в том, что если обновление оборудования не дает никакого эффекта - а это похоже на серьезный Обновить - ты не привязан к оборудованию. Вы, наверное, никогда не были. Просить «общих настроек ускорения» - это не то, что вам нужно - вам нужно измерять, изменять, тестировать, повторять. Как только вы определите причину, решение будет простым. Но ты еще не там.
Прежде всего нам нужно прояснить, что вы имеете в виду под «отсутствием улучшений». Главное, что нужно помнить при оптимизации производительности, - это измерять.
Если раньше загрузка ваших страниц занимала всего миллисекунды, то теперь они, вероятно, занимают на 1-2 миллисекунды меньше. То, что это незаметно для человеческого глаза, не означает, что этого не происходит.
Конечно, есть разница в производительности между скоростью загрузки страниц и количеством одновременных запросов, которые сервер может обработать. Вы можете обнаружить, что даже если кажется, что сервер отвечает одинаково, может потребоваться больше одновременных пользователей.
Если ваше приложение является базовым приложением CRUD, то добавление большего количества процессора и памяти, вероятно, не будет иметь никакого значения, потому что это не то, где ваше узкое место. Я ожидал, что перенос БД на тот же компьютер даст вам небольшое увеличение, но опять же, это зависит от того, как вы его измеряете.
Я бы посоветовал использовать счетчики производительности для измерения нагрузки на сервер, анализировать журналы IIS, проверять время отклика страницы и определять причину проблемы.