понедельник, 31 октября 2011 г.

Difference between Application Pool and Application Domain


This question normally arises when configuring web applications.
To summarize, an AppPool consists of one or more processes.  Each web application that you are running consists of (usually, IIRC) one application domain.  The issue is when you assign multiple web applications to the same AppPool, while they are separated by the application domain boundary they are still in the same process.  This can be less reliable/secure than using a separate AppPool for each web application.  On the other hand, it can improve performance by reducing the overhead of multiple processes.
ASP.NET has its own forums.  I'd recommend you ask there if you have additional questions about how to set up ASP.NET: http://forums.asp.net/
Here are some quotes from the documentation:
Application Pool
[quote]
An Internet Information Services (IIS) application pool is a grouping of URLs that is routed to one or more worker processes. Because application pools define a set of Web applications that share one or more worker processes, they provide a convenient way to administer a set of Web sites and applications and their corresponding worker processes. Process boundaries separate each worker process; therefore, a Web site or application in one application pool will not be affected by application problems in other application pools. Application pools significantly increase both the reliability and manageability of a Web infrastructure.
[/quote]
Application Domain
[quote]
A boundary that the common language runtime establishes around objects created within the same application scope (that is, anywhere along the sequence of object activations beginning with the application entry point). Application domains help isolate objects created in one application from those created in other applications so that run-time behavior is predictable. Multiple application domains can exist in a single process.
[/quote]

Global.asax Events


HttpApplication Events:
Application_AcquireRequestStateOccurs when ASP.NET acquires the current state (for example, session state) that is associated with the current request. 
Application_AuthenticateRequestOccurs when a security module has established the identity of the user. 
Application_AuthorizeRequest
Occurs when a security module has verified user authorization. 
Application_BeginRequest
Occurs as the first event in the HTTP pipeline chain of execution when ASP.NET responds to a request. 
Application_Disposed
Adds an event handler to listen to the Disposed event on the application. 
Application_EndRequest
Occurs as the last event in the HTTP pipeline chain of execution when ASP.NET responds to a request. 
Application_Error
Occurs when an unhandled exception is thrown. 
Application_PostAcquireRequestState
Occurs when the request state (for example, session state) that is associated with the current request has been obtained. 
Application_PostAuthenticateRequest
Occurs when a security module has established the identity of the user. 
Application_PostAuthorizeRequest
Occurs when the user for the current request has been authorized. 
Application_PostMapRequestHandler
Occurs when ASP.NET has mapped the current request to the appropriate event handler. 
Application_PostReleaseRequestState
Occurs when ASP.NET has completed executing all request event handlers and the request state data has been stored. 
Application_PostRequestHandlerExecute
Occurs when the ASP.NET event handler (for example, a page or an XML Web service) finishes execution. 
Application_PostResolveRequestCache
Occurs when ASP.NET bypasses execution of the current event handler and allows a caching module to serve a request from the cache. 
Application_PostUpdateRequestCacheOccurs when ASP.NET completes updating caching modules and storing responses that are used to serve subsequent requests from the cache. 
Application_PreRequestHandlerExecuteOccurs just before ASP.NET begins executing an event handler (for example, a page or an XML Web service). 
Application_PreSendRequestContentOccurs just before ASP.NET sends content to the client. 
Application_PreSendRequestHeaders
Occurs just before ASP.NET sends HTTP headers to the client. 
Application_ReleaseRequestState
Occurs after ASP.NET finishes executing all request event handlers. This event causes state modules to save the current state data. 
Application_ResolveRequestCache
Occurs when ASP.NET completes an authorization event to let the caching modules serve requests from the cache, bypassing execution of the event handler (for example, a page or an XML Web service). 
Application_UpdateRequestCache
Occurs when ASP.NET finishes executing an event handler in order to let caching modules store responses that will be used to serve subsequent requests from the cache. 
Application_Init
This method occurs after _start and is used for initializing code.

Application_Start
As with traditional ASP, used to set up an application environment and only called when the application first starts.
Application_End
Again, like classic ASP, used to clean up variables and memory when an application ends.
Session Events:
Session_Start
As with classic ASP, this event is triggered when any new user accesses the web site.
Session_End
As with classic ASP, this event is triggered when a user's session times out or ends. Note this can be 20 mins (the default session timeout value) after the user actually leaves the site.
Profile Events:
Profile_MigrateAnonymous
Occurs when the anonymous user for a profile logs in.
Passport Events:
PassportAuthentication_OnAuthenticate
Raised during authentication. This is a Global.asax event that must be named PassportAuthentication_OnAuthenticate.
 
Possibly more events defined in other HttpModules like:
System.Web.Caching.OutputCacheModule
System.Web.SessionState.SessionStateModule
System.Web.Security.WindowsAuthentication
System.Web.Security.FormsAuthenticationModule
System.Web.Security.PassportAuthenticationModule
System.Web.Security.UrlAuthorizationModule
System.Web.Security.FileAuthorizationModule
System.Web.Profile.ProfileModule

вторник, 4 октября 2011 г.

Internet Explorer 10 — новые горизонты производительности


После очередного превью платформы Internet Expolorer 10 стало очевидным, что Microsoft продолжает работу по оптимизации своего браузера. Как и ранее в центре внимания оказались HTML5 технологии, а также поддержка новых спецификаций и API рабочих групп W3C.
Производительность HTML5
При просмотре специально подготовленных демо непривычно было наблюдать, как всякий раз IE10 оказывался быстрее своих конкурентов — Chrome, Firefox и Opera. Internet Explorer 10 действительно показал незаурядную скорость при работе с HTML5 видео, аудио и canvas, а также CSS3 градиентами.
Демо Flying Images
Асинхронное выполнение скриптов
Наличие атрибута async делает загрузку и выполнение кода JavaScript асинхронной относительно других объектов страницы. Тем самым решается проблема нежелательных блокировок и уменьшается общее время загрузки в тех случаях, когда между файлами скриптов не явных зависимостей.
Данный атрибут является частью стандарта W3C HTML5 и уже поддерживается многими современными браузерами.
Web Workers
Для большинства браузеров традиционной являлась однопоточная реализация, при которой выполнение скриптов и рендеринг страниц не могли выполняться параллельно. Внедрение технологии Web Workers сделало возможным фоновое выполнение кода JavaScript.
Новый объект Worker в качестве аргумента требует имя файла, который будет получен посредством асинхронного запроса к серверу:
var myWorker = new Worker('worker.js');
Взаимодействие с фоновым потоком осуществляется с помощью системы сообщений. Для отправления данных используется метод postMessage, а получение ответа реализуется через событие onmessage.
В следующем примере показано создание Worker потока, который ожидает сообщение от скрипта:
var hello = new Worker('hello.js');
 
hello.onmessage = function(e) {
  alert(e.data);
};
«Рабочий» поток в свою очередь отправляет сообщение для отображения на экране
postMessage('Hello world!');
Page Visibility API
Page Visibility позволяет разработчикам явно отслеживать текущее состояние документа и назначать необходимые действия при изменениях видимости страницы сайта. API включает в себя два свойства document.hidden и document.visibilityState, а также одно событие visibilitychange.
С помощью Page Visibility API можно более эффективного распоряжаться вычислительными ресурсами, не нагружая ПК пользователей в те моменты, когда страница невидима. Кроме того, можно более грамотно реализовывать фоновое предварительное кэширование статических объектов.
Методы requestAnimationFrame и setImmediate
Поддержка двух новых методов requestAnimationFrame и setImmediate станет решением ряда проблем, связанных с выполнением кода JavaScript.
Часто случается, что анимации на веб-страницах выполняются в то время, когда документ находится на фоновой вкладке, или окно браузера и вовсе свернуто. Также нередким случаем является отсутствие синхронизации между частотой дисплея и таймерами JavaScript.
Например, если раньше интервалы для анимации задавались с помощью setInterval:
var handle = setInterval(renderLoop, PERIOD);
то теперь можно использовать более эффективный метод requestAnimationFrame, который автоматически выравнивает частоту обновления приложений и интервалы рендеринга самого бразузера:
var handle = msRequestAnimationFrame(renderLoop);
В свою очередь метод setImmediate является альтернативой методу setTimeout с нулевым периодом тайм-аута. Если ранее код имел вид:
var handle = setTimeout(spellCheck, 0);
То более эффективный подход будет выглядеть следующими образом:
var handle = msSetImmediate(spellCheck);
Источник: IEBlog