Ужасная производительность DotNetNuke
Я участвую в проекте, использующем DotNetNuke версии 05.01.04 Community Edition. Мы строим наш новый Интранет, используя его, но производительность ужасна.
У нас есть пять человек, которые добавляют страницы и контент к нему, и каждые 15-30 секунд они испытывают паузу в 10 секунд или дольше, прежде чем система продолжит работу и загрузится следующий экран.
Сервер Windows 2003, 3,8 ГГц с 1 ГБ оперативной памяти. Администратор нашего сервера сказал мне, что производительность процессора и памяти не является узким местом.
В настоящее время у нас есть 350 страниц в системе, мы планируем добавить 1000. Поэтому нам нужно решить эту проблему производительности, чтобы мы могли вводить контент и чтобы мы могли начать работу.
Я просто не вижу, где находится узкое место. Есть ли смысл определять узкое место при использовании DotNetNuke?
Модули установлены
- Опубликовать: Engage (в данный момент не используется)
- Page Blaster (не обеспечивает кэширование при входе пользователей с помощью встроенной аутентификации)
- SimpleGallery
- XMOD
- Контент менеджер
Настройка IIS
Рециркуляция приложений полностью отключена (кроме перерыва на 2 часа ночи)
Новые результаты: 18 марта 2010
Основное узкое место было связано с ошибкой версии 5.1.4, которая вызвала 1300 обращений к базе данных на средней странице из-за неправильного кэширования базы данных в памяти. Мы обновились до 5.2.4, что позволило устранить это узкое место.
Теперь следующим большим узким местом является навигация. Мы использовали DDR: Меню и DDN:Nav, но оба имеют большое влияние на производительность.
Есть ли навигационный интерфейс, который не так сильно снижает производительность?
5 ответов
Я думаю, что вам нужно начать исследовать это с помощью инструментов профилирования производительности. Для самого приложения DNN я бы взял что-то вроде JetBrains DotTrace или ANTS Performance Profiler от Red Gate.
Для базы данных SQL Server Profiler будет первым выбором или инструментом, таким как SQL Response от Red Gate.
Без профилирования приложения вы будете тянуть за соломинку.
И, как отметил Тим в своем комментарии, установка Firebug в Firefox с надстройкой YSlow, чтобы увидеть, какие ресурсы требуются дольше всего для обслуживания браузера.
У Митчела Селлерса есть несколько хороших учебных пособий и контрольных списков, касающихся работы в DNN. Начните с объяснения высокопроизводительной конфигурации и управления DotNetNuke (что указывает на некоторые из его более ранних статей).
У меня есть несколько лет опыта в области разработки и сопровождения dnn, когда у меня возникают подобные проблемы, я начинаю делать вещи из базы данных. Следующее - найти недостающие индексы и / или периодически перестраивать все индексы (для этого запланировано задание sql), но основной выигрыш в производительности будет связан с очисткой таблицы.
Еще одно полезное соображение: отключить трассировку, режим отладки до false и отключить функции dnn, которые вы не используете (планировщик - первый, который отключает)
Редактировать: рассмотреть вопрос о сохранении в живых, а также надеюсь, что это помогает
Ваша база данных на этом сервере? Если это так, просто добавьте больше оперативной памяти или получите более быстрый дисковый массив...
Рассматривали ли вы создание такого количества страниц непосредственно через TSQL? Это не сложно сделать и может сэкономить вам много времени.