asp.net c # ускорение занятий

Question

Я работаю над большим проектом в компании. Мы собираем данные, которые получаем с помощью методов API CMS.

ех.

DataSet users = CMS.UserHelper.GetLoggedUser(); // returns dataset with users

Теперь на некоторых страницах нам нужно много разных данных, не только пользователей, но и узлов дерева CMS или конкретных данных поддерева.

Итак, мы подумали о написании собственного «вспомогательного класса», в котором позже мы сможем легко получать разные данные.

например:

MyHelperClass.GetUsers();
MyHelperClass.Objects.GetSingleObject( ID );

Теперь проблема в том, что наш «класс помощников» действительно большой, и теперь нам нравится собирать разные данные из «класса помощников» и записывать их в типизированный набор данных. Позже мы можем дать повторитель, который набрал набор данных, который содержит данные из разных таблиц. (что даже происходит от методов, которые я писал ранее через API)

Проблема в том, что теперь так медленно, даже при загрузке страницы! Он загружает или инициализирует весь класс ??

Кстати, CMS - это Kentico, если кто-то с ним работает.

Я устал. Пробовал всю ночь .. но это так медленно. Пожалуйста, посмотрите на эту архитектуру. Может быть, вы найдете некоторые преступления, которые не допускаются: S

Надеюсь, мы сделаем это быстрее. Спасибо.

альтернативный текст http://img705.imageshack.us/img705/3087/classj.jpg

Answer 1

Узкие места обычно бывают нескольких форм:

• Медленная или ненадежная сеть.
• Тяжелое чтение / запись на диск, поскольку дисковый ввод-вывод в 1000 раз медленнее, чем чтение или запись в память.
• Дроссель ЦП, вызванный длительным или неэффективно реализованным алгоритмом.

На это может повлиять множество вещей, в том числе запросы и индексы базы данных, количество людей, обращающихся к вашему сайту, нехватка памяти на вашем веб-сервере, много отражений в вашем коде, просто медленное оборудование и т. Д. расскажите, почему ваш сайт работает медленно, вам нужно его профилировать.

---

Для какой цели вы задали вопрос об архитектуре API - с точки зрения кода она выглядит хорошо. Нет ничего плохого в копировании полей из одного класса в другой, и снижение производительности, понесенное при преобразовании класса-оболочки с object на Guid или bool, вероятно, будет настолько крошечным, что его можно будет пренебречь

Поскольку вы спрашивали о производительности, не очень понятно, почему вы связываете классовую архитектуру с производительностью. Есть действительно крошечные микрооптимизации, которые вы можете применить к своим классам, которые могут или не могут повлиять на производительность, но четыре или пять наносекунд, которые вы получите с этими микрооптимизациями, уже потеряны, просто прочитав этот ответ. Сетевая задержка и запросы к БД абсолютно затормозят тонкости производительности вашего API.

В комментарии вы указали ", поэтому нет проблем со статическими классами или моей основной ошибкой ". С точки зрения производительности, нет. С точки зрения веб-приложения, наверное. В частности, статические поля являются глобальными и инициализируются один раз для каждого AppDomain, а не для каждого сеанса - переменные mCurrentCultureCode и mcurrentSiteName соответствуют конкретным сеансам, а не глобальным для AppDomain. Я бы дважды проверил их, чтобы они правильно отображали ваш сайт, когда пользователи с разными настройками культуры одновременно получают доступ к сайту.

Answer 2

Вы уже используете Кэширование и Сеанс состояние?

Основная идея заключается в том, чтобы отложить как можно большую часть загрузки данных на эти носители, а не делать это при загрузке отдельных страниц. Кэширование особенно полезно, если вам нужно получить данные только один раз и поделиться ими между пользователями и с течением времени.

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

Answer 3

Я предлагаю вам попытаться профилировать вашу заявку и посмотреть, где находятся узкие места:

Медленная загрузка из БД?

Медленный сетевой трафик?

Медленный рендеринг?

Слишком много трафика для клиента?

Мир профилирования должен быть частью почти каждого старшего программиста. Это часть общего инструментария. Изучите это, и вы получите ответы сами.

Ура! * * 1013

Answer 4

Первым делом ... Включите Trace для своего приложения и попытайтесь оптимизировать размер ответа, кэширование и работу с некоторыми приложениями и профилировщиками БД ... Я просто боюсь, что никто не сможет вам помочь лучше.