В допълнение към нашия код, всеки от входящите заявки и изходящите отговори се обработват ASP.NET компоненти. Някои механизми на един ASP.NET, като например ViewState, бяха предоставени за нуждите на развитие, но те могат да повлияят на цялостното представяне на заявлението. Когато фина настройка се препоръчва прилагането на ASP.NET, за да промените поведението по подразбиране на някои от тези механизми, въпреки че понякога тези промени могат да изискват промени в кода на приложението.
Деактивиране на проследяване и отстраняване на грешки механизми ASP.NET
ASP.NET проследяване механизъм проследяване позволява на разработчиците да получат информация за диагностика за дадена страница, като времето за изпълнение, по пътя си, статус на сесията, както и списък на HTTP заглавната част.
Докато механизъм проследяване позволява да се получи ценна информация по време на развитие и отстраняване на грешки на ASP.NET приложения, има и отрицателен ефект върху цялостното представяне на заявлението, да се съберат данни за всяка заявка за данни. Това е, ако подкрепата на следа е била включена в фазата на развитие, да го спрете преди да изградим вашата кандидатура в производствена среда, която е съвсем проста, за да промените настройките на следа във файла web.config:
По подразбиране, освен ако изрично е посочено друго, проследяване е забранено (активиран = "фалшива"), следователно, за да изключите проследяването може също просто премахване на следи опция от файла web.config.
Когато създавате нов ASP.NET базиран уеб приложение във файла web.config автоматично се добавя към system.web раздела конфигурация -> компилация с атрибут за отстраняване на грешки, разположен в са верни:
Проблемът с този вариант е, че разработчиците често забравят да го настроите да невярна при разгръщане на съществуващия уеб сървър или специален отпуск по смисъла на истина, за да могат да получат повече информация в случай на изключения. Това може да доведе до редица проблеми, свързани с изпълнението:
Скриптове, които се изтеглят с помощта WebResources.axd манипулатор. например, когато се използва в страниците на валидиране няма да бъдат кеширани от браузъра. Когато флагът за отстраняване на грешки е настроено на фалшиви, отговор от страна на водача ще бъдат снабдени с позиции, оставяйки място за кеширане, което позволява на браузъри, за да съхранява резултатите в кеша за бъдеща употреба.
Когато параметърът за отстраняване на грешки е невярна, време за изчакване не е настроена за обработка на заявки. Въпреки, че това е много полезно при откриване на грешки, такова поведение не е желателно в промишлена среда, тъй като тези искания могат да доведат до това, че сървърът не е в състояние да обслужва други искания, или дори да доведе до прекомерно натоварване на процесора, повишена консумация на памет и да причинят други проблеми разпределението на ресурсите.
Монтаж стойност за отстраняване на грешки флаг за фалшива позволява ASP.NET по време на работа се определи време за изчакване за обработка на заявката в съответствие с httpRuntimeExecutionTimeout настройки (стойност по подразбиране 110 секунди).
Когато опцията за отстраняване на грешки е настроен да е истина, JIT-компилатор няма да оптимизират кода. Тази оптимизация е един от най-важното предимство на околната среда .NET и може да осигури значително увеличаване на работата на приложенията ASP.NET без промяна на кода. Настройка за отстраняване на грешки на фалшива ще позволи на JIT-компилатор да си свърши работата и да направи вашата кандидатура по-бързо и по-ефективно.
Променете тази настройка е много проста: просто премахнете напълно отстраняване на грешки атрибут в конфигурационния файл, или да го настроите да невярно:
Ако се страхувате, че ще забравите да промените тази настройка, когато приложението се разполага на съществуващия сървър, можете да направите всички ASP.NET приложения пренебрегват възможността за отстраняване на грешки на сървъра, следния код във файла machine.config на сървъра:
Деактивирането механизъм ViewState
Механизъм за съхраняване оглед състояние ViewState се използва в ASP.NET уеб форми на приложенията да запазват състоянието на оформлението на страницата показва в HTML (ASP.NET MVC приложения не използват този механизъм). ViewState механизъм позволява ASP.NET, за да запазите състоянието на страницата, за да го изпрати обратно на потребителя. Данните се съхранен във формат, е криптирана (криптиране по подразбиране е изключена), кодиран в Base64 низ и се съхранява в скрито поле. Когато потребителят изпраща страницата обратно съдържанието на полето декодират и се превръщат отново в асоциативен масив. Много сървърни контроли използват ViewState механизъм за съхраняване на собствената си информация, като стойностите на техните свойства.
Увеличаването на обема на страници с помощта на механизма за ViewState обикновено остава скрита за клиенти, осъществяващи достъп до уеб сървър в локалната мрежа. Това се дължи на факта, че локални мрежи обикновено имат висок процент на трансфер и транспортни много големи страници в такива мрежи е милисекунди (в оптимално конструирани гигабитова LAN пропускателна способност може да достигне
40-100 Mbytes / сек, в зависимост от използвания хардуер). Въпреки това, по-бавно, глобални мрежи като Интернет, увеличаване на размера става все по-ясно изразен.
Ако дадена заявка не е необходимо да се използва този механизъм, по-добре е да я изключите. Изключване на механизъм ViewState може да бъде в web.config файл за целия прилагането в пълен размер:
Ако не може да бъде забранено за цялото приложение, можете да деактивирате използването на механизъм ViewState в отделна страница и всичките му контроли:
Възможно е също така да деактивирате ViewState индивидуални настройки:
Предишните версии на ASP.NET 4 поддържа деактивиране на механизъм страница ViewState, направиха невъзможно за включването му в отделните контролите на страницата. Започвайки с версия на ASP.NET 4 тази възможност е добавен. Това се постига чрез използване на ViewStateMode собственост. Например, следния код деактивира механизъм ViewState за цяла страница, с изключение на контрола на ListView:
Инсталиране EnableViewState атрибут за фалшива има по-висок приоритет от ViewStateMode атрибути. Това означава, че ако имате намерение да използвате ViewStateMode атрибути, не забравяйте да зададете EnableViewState атрибут за истина или просто да го изтриете (по подразбиране тя е настроена да е вярно).
Теглене на пари от страна на сървъра
ASP.NET страници са динамични, по отношение на съдържанието, обаче, често е динамично съдържание на страницата, не се променя с течение на времето. Така например, на страницата, може да се идентификаторът на продукта и да се върне на HTML маркирането на описанието им. Самата страница е динамичен, тъй като тя може да се върне с различно описание за различните продукти, но описанието на даден продукт не се променя, поне толкова дълго, тъй като тя не се променя базата данни.
Продължение на примера по с продукта, за да се предотврати извършването на многократните искания към базата данни всеки път, когато потребител иска описание на продукта, можете да спестите описанието в локалния кеш и да осигури по-бързо своето възстановяване, но все още трябва да се генерира HTML маркиране в отговор на всяко искане , Вместо това, кеширането на източник на данни, ASP.NET предоставя още една възможност - ASP.NET Output Cache механизъм. където тя спаси HTML маркирането.
Чрез този механизъм е възможно да се спаси HTML маркиране, които ще бъдат върнати автоматично в отговор на последващо искане, заобикаляйки етапа на изпълнение на програмен код, който генерира страницата. О кеш в ASP.NET подкрепя за приложения, базирани на уеб форми, където страниците се съхраняват в кеш паметта и приложения, базирани на ASP.NET MVC, където се съхраняват контролер резултатите от дейността.
Например, следния код използва изход кеша за съхраняване на презентацията се върне на работа ASP.NET MVC контролер за до 30 секунди:
Ако операцията по индекс в примера по-горе отнема параметър на идентификатора на продукта, и връща представяне на информация за даден продукт, ние ще трябва да се кешират няколко версии на продукция за различни идентификатори. Ето защо, кеша изход поддържа не само способността да се спаси една единствена версия на продукцията, но и различните версии на данни, генерирани от една и съща операция, причинени от различни параметри.
В допълнение към механизма за кеширане параметри продукция също така да се вземе предвид заглавките HTTP-заявка, като Accept-Encoding и Accept-Language. Например, ако методът на контролера може да се върне на съдържанието на различни езици, в зависимост от HTTP-заглавието Accept-Language, можете да зададете записи този удар с глава и се съхранява в кеш различните версии на изхода на различни езици.
Ако се прилагат едни и същи настройки хеширане към различни страници или операции, можете да създадете профил кеш и да го използвате, вместо да задавате повторение отново и отново. Профилите се кеширане във файла web.config, вижте system.web -> кеширане. Например, следния код декларира профил кеша, че трябва да се използва заедно с различни страници:
Сега, този профил може да се приложи към индекса на експлоатация:
Свързани статии