Падение производительности при использовании runat = server для элементов управления html

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

Для переопределения URL-адресов в asp.net я хотел бы объявить все изображения и другие ресурсы в моем приложении с атрибутом runat = "server", чтобы воспользоваться синтаксисом пути к серверу "~ / images". Отладка на locahost особенно сложна при использовании относительных путей (при использовании перезаписи URL). Я знаю, что могу изменить файлы хоста, чтобы частично решить эту проблему, но это невозможно из-за объема проектов, над которыми мы работаем.

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

Я также понимаю, что у движка времени выполнения asp net есть больше элементов управления, которые нужно обрабатывать и обрабатывать, но действительно ли это серьезная потеря производительности ...?

Есть ли серьезные накладные расходы при объявлении изображений таким образом, и если да, может ли кто-нибудь объяснить, откуда именно произойдет основная часть снижения производительности.

Заранее спасибо.


asp.net performance runatserver
person gg.    schedule 13.11.2009    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Предполагая, что вы спрашиваете о различиях между:

1) <img runat="server" EnableViewState="false" src="~/images/img.png" />

и

2) <img src='<%= ResolveUrl ("~/images/img.png") %>' />

Для построения 1) фактический сгенерированный код (более или менее) выглядит следующим образом:

System.Web.UI.HtmlControls.HtmlImage __ctrl;
__ctrl = new System.Web.UI.HtmlControls.HtmlImage();
this._bctrl_1 = __ctrl;
__ctrl.EnableViewState = false;
__ctrl.Src = "~/image.png";

Затем этот __ctrl добавляется в дерево элементов управления:

__parser.AddParsedSubObject(this._bctrl_1); // _bctrl_1 is __ctrl from above

Любое событие в жизненном цикле страницы (Init, Load ...) будет передано этому элементу управления, будет вызываться RenderControl для получения от него HTML, вызывается ResolveUrl () для получения фактического URL-адреса и, наконец, Dispose () тоже будет называться.

Теперь, в случае 2), элемент управления не добавляется к своему родительскому элементу обычным способом, но вместо этого вы получаете что-то вроде этого:

__ctrl.SetRenderMethodDelegate(new System.Web.UI.RenderMethod(this.__RenderTree));

Это устанавливает делегата, который будет вызываться, когда придет время для рендеринга ‹img›. В __RenderTree часть, которая записывает интересующий нас тег:

__output.Write("\n<img src='");
__output.Write( ResolveUrl ("~/image.png") );
__output.Write("' />\n");

Итак, да, в 1) выполняется «много» кода, который не выполняется в 2). Что касается влияния на фактическое время выполнения, я думаю, что это не так уж и важно. Я тестировал пустую страницу только с тегом / элементом управления img, и разница между ними в нескольких запусках была в диапазоне -0,5 мс / + 0,5 мс на запрос. Совершенно незначительно.

person Gonzalo    schedule 13.11.2009
comment
Именно то, что я искал ... спасибо :) никогда не задумывался о варианте 2 ... гг - person gg.; 13.11.2009

arrow_upward
0
arrow_downward

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

Рассмотрим разметку, описывающую серию элементов HTML. Она рассматривается как простой буквальный «элемент управления», который очень эффективно отправляет все свое содержимое в ответ в соответствующей точке рендеринга страницы.

Сравните это со всеми теми же элементами, создаваемыми как полные элементы управления, со всем созданием объекта, анализом элемента стиля, проверкой и т. Д. И созданием локального состояния. Затем код запускается, чтобы взять локальное состояние и в значительной степени отобразить ту же разметку HTML, которая использовалась для его определения на странице ASP.NET в первую очередь.

Очевидно, что с точки зрения памяти и ЦП использование большого количества runat = "server" будет более дорогостоящим. В индивидуальном случае это, вероятно, не проблема, но для сайта со значительной активностью это вполне может быть.

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

Если вы разрабатываете приложение, предназначенное для отдельного сайта, то в свойствах проекта или сайта измените виртуальный путь в категории «Веб-сервер разработчика» на просто «/». Таким образом, при отладке у вас не будет дополнительной части / myprojectname / в URL-адресе. Это позволит вам использовать абсолютный путь к некоторым ресурсам или папке с изображениями.

person AnthonyWJones    schedule 13.11.2009
comment
Спасибо за ответ, Энтони ... Проблема с переписыванием URL-адресов и относительными путями заключается в том, что страница, находящаяся в корневом каталоге /product.aspx?pid=1, может быть переписана как /products/productgroup/some-product.aspx. Таким образом, все изображения и ресурсы, заявленные на странице, больше не будут действительны. Во-вторых, мы используем IIS для отладки и просто подключаемся к процессу w3wp.exe, мы не используем сервер веб-разработчика, что также исключает эту опцию. Я понимаю, что вы говорите о затратах на производительность, и ценю информацию. Я полагаю, это будет зависеть от характера сайта (объем трафика и т. Д.) - person gg.; 13.11.2009
comment
Если вы переписываете URL-адреса и это корневой сайт, просто используйте для изображений абсолютные пути. - person AnthonyWJones; 13.11.2009