повышение производительности для веб-сайта asp.net на производственном сервере

Question

У меня на рабочем сервере есть приложение asp.net webforms, и оно было очень медленным.Поэтому я решил получить несколько советов по производительности от моих коллег-пользователей SO.

Я применил их для повышения производительности моего сайта asp.net,

1. Set debug=false

2. Поворот off Трассировка

3. Кэширование изображений

          <caching>
           <profiles>
               <add extension=".png" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" location="Any" />
               <add extension=".jpg" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" location="Any" />
               <add extension=".gif" policy="CacheUntilChange" kernelCachePolicy="CacheUntilChange" location="Any" />
           </profiles>
       </caching>
   

Любой другой реальный усилитель производительности вы знаете?Любое предложение ...

Answer 1

Веб-страница может быть быстрой только в дизайне.

Простая опция не может заставить вашу страницу загружаться быстрее. Функция debug = off исключает только дополнительные функции отладки, и фактически, если вы их не используете, это не может заставить многих задуматься.

Я согласен со всем, что говорит Павел, и вы можете найти их здесь с более подробной информацией , и я должен сказать, что как дополнительный ...

Вам нужно следовать некоторым руководствам и проделать большую работу, чтобы сделать их очень быстрыми. За чем я следую.

1. Я использую (настраиваемый) кеш для своих действий с базой данных , которые действительно повышают скорость загрузки данных, но в то же время делают код намного больше и я трачу много времени.
2. Я использую профилировщик, чтобы найти мои медленные точки на странице и исправить их.
3. Я использую Inspector в браузере Google Chrome для определения медленной загрузки и проблем с двойной загрузкой.
4. У меня есть исключить двойное использование / создание любых переменных в пользовательских элементах управления.
5. Я использую кеш на базе клиентского браузера на это предложения .
6. Я использую webfarm и / или webgarden (более одного пула).

Как узнать скорость вашей страницы: http://code.google.com/speed/page-speed/docs/using.html

Оптимизировать кеш: http://code.google.com/speed/page-speed/docs/caching.html

Многие общие темы от Google можно найти здесь: http://code.google.com/speed/articles/

О кешировании: http://www.mnot.net/cache_docs/

Надеюсь, это поможет.

Answer 2

Не напрямую ASP.NET, но

1) Убедитесь, что сжатие включено в IIS.

2) Если на вашем сайте установлены «тяжелые» файлы cookie статических файлов хоста (изображения, CSS иJS) в отдельном домене.Каждый запрос обратно на сервер должен отправлять всю информацию о файлах cookie сайта обратно на сервер.Таким образом, если использование файлов cookie составляет 10 КБ +, тогда 20 ссылок на статические файлы на странице приведут к дополнительной отправке 200 КБ на сервер.Если вы переместите статические файлы в домен, который не имеет требований к файлам cookie, вы удалите эти издержки.Стоит отметить, что из-за «ошибки» в том, как IE обрабатывает вещи, вы не получаете никакой выгоды в использовании поддоменов, IE, похоже, настаивает на отправке всех доменных файлов cookie в субдомены.Дополнительным преимуществом является то, что разрешается параллельное HTTP-запросов

Answer 3

Прекратите взламывать свой рабочий сервер (что может привести к функциональным ошибкам) ​​и сделайте шаг назад. Можете ли вы воспроизвести проблемы с производительностью в непроизводственной среде? Если нет, то попробуйте.

Вы должны попытаться воспроизвести проблему следующим образом:

• Получите производственное оборудование в своей тестовой среде - веб-серверы, серверы баз данных и т. Д. - на том же оборудовании, что и на производстве
• Запустите тот же набор программного обеспечения, что и для производства, - он включает ту же конфигурацию ASPNET и все другие используемые сервисы.
• Загрузка данных производственного размера (производственных данных, если это возможно) в ваши базы данных (не забудьте настроить брандмауэр вашей лаборатории из Интернета, чтобы он не мог отправлять почту или другие вещи в Интернет, или ваши пользователи могут начать получать уведомления по электронной почте из теста система, которая была бы плохой!)
• Создание смоделированного трафика на сайт до уровня производства - это довольно сложно, но есть много доступных инструментов

Теперь у вас есть шанс повторить проблему в тестировании, вы можете попробовать решения.

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

• Делать меньше запросов
• Оптимизация запросов, которые вы делаете (получать меньше данных, использовать соответствующие индексы и т. Д.)
• Измените структуру базы данных, чтобы упростить для нее запросы (кластеризованные индексы и т. Д., Возможно, денормализовать)

Но любое изменение, которое вы вносите, попробуйте применить его в своей тестовой системе, измерить результаты, и, если это не поможет, ОБРАТИТЕ ВЕРНУТЬСЯ.

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

---

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

Ваша база данных помещается в ОЗУ? Может ли это вписаться в оперативную память? Если ответы на эти вопросы - «нет» и «да» соответственно, купите больше памяти для базы данных Это один из самых дешевых способов сделать вашу БД быстрее без изменений кода.