Ужасная производительность DotNetNuke

Question

Я участвую в проекте, использующем DotNetNuke, версия 05.01.04 Community Edition .Мы строим наш новый Интранет, используя его, но производительность ужасна.

У нас есть пять человек, которые добавляют страницы и контент к нему, и каждые 15-30 секунд они испытывают паузу в 10 секунд илипрежде чем система продолжит работу и загрузятся следующие экраны.

Сервер - Windows 2003, 3,8 ГГц с 1 ГБ ОЗУ.Администратор нашего сервера сказал мне, что производительность процессора и памяти не является узким местом.

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

Я просто не вижу, где находится узкое место.Есть ли смысл определять узкое место при использовании DotNetNuke?

Установленные модули

• Публикация: Engage (В настоящее время не используется)
• Page Blaster (не обеспечивает кэширование при входе пользователей с помощью встроенной аутентификации)
• SimpleGallery
• XMod
• Content Manager

Настройка IIS
Перезапуск приложения полностью отключен (кроме перезапуска в 2 часа ночи)

Новые результаты: 18 марта 2010
Основное узкое место было связано с ошибкой версии 5.1.4, которая вызвала 1300 обращений к базе данных на средней странице из-за сбоя кэширования базы данных в памяти.Мы обновились до версии 5.2.4, которая устранила это узкое место.

Теперь следующим самым большим узким местом является навигация.Мы использовали DDR: Меню и DDN: Nav, но оба имеют большое влияние на производительность.

Существует ли какой-либо навигационный интерфейс, который не снижает производительностьтак плохо?

Answer 1

Я думаю, вам нужно начать исследовать это с помощью инструментов профилирования производительности.Для самого приложения DNN я бы взял что-то вроде JetBrains DotTrace или Red Gate ANTS Performance Profiler .

Для базы данных SQL Server Profiler был бы первым выбором илиинструмент, такой как SQL Response .

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

И, как отметил Тим в своем комментарииустановка Firebug в Firefox с надстройкой YSlow, чтобы узнать, какие ресурсы затрачиваются дольше всего для обслуживания браузера.

Answer 2

У Митчела Селлерса есть несколько хороших учебных пособий и контрольных списков, которые нужно пройти в отношении производительности в DNN. Начните с Объяснение высокопроизводительной конфигурации и управления DotNetNuke (что указывает на некоторые из его предыдущих статей).

Answer 3

У меня есть несколько лет опыта разработки и сопровождения dnn, когда у меня возникают проблемы такого рода, я начинаю делать что-то из очистки базы данных .Следующее - найти недостающие индексы и / или периодически перестраивать все индексы (запланированное для этого задание sql), но основной выигрыш в производительности будет связан с очисткой таблицы

Еще одним хорошим соображением может быть отключение трассировки,Отладьте режим в false и отключите функции dnn, которые вы не используете (планировщик отключает первым)

Редактировать: рассмотреть также сохранить Надеюсь, это поможет

Answer 4

Рассматривали ли вы создание этой партии страниц напрямую через TSQL? Это не сложно сделать и может сэкономить вам много времени.

Answer 5

Ваша база данных на этом сервере? Если это так, просто добавьте больше оперативной памяти или получите более быстрый дисковый массив ...