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