none
Общие сведения о жизненном цикле приложения ASP.NET - часть 3 RRS feed

  • Вопрос

  • Как известно, после запроса клиентом страницы ASP.NET (при первом запросе), создается рабочий процесс, инициализируется CLR, создается в рамках .net процесса  домен приложения, в котором создаются HttpRuntime, который в свою очередь создает HttpApplicationFactory.

    Этот HttpApplicationFactory, на основе url запроса создает обработчик HttpApplication из файла Global.asax (Причем он парсит этот файл и в итоге компилирует в готовый класс).

    После обработки запроса и отправки его пользователю, происходит событие извещающее об этом SetEndOfSendNotification, в этом обработчике производится освобождение ресурсов, занятых объектами HttpRequest и HttpResponse. Но в итоге домен не выгружается с экземплярами классов HttpApplication, и сам объект HttpApplication тоже не уничтажается, потому что ресурсоемко его при каждом запросе компилировать.

    Вопросы:

    1) Как долго по времени домен может не выгружаться в стандартном случае? Может ли это настраиваться?

    2) Знаю, что после компиляции HttpApplication,  хэш всех сборок запоминается где-то в папках .net'а для того чтобы asp.net выясняла изменялись  ли файлы. Не сохраняется ли сам скомпилированный класс HttpApplication тоже, чтобы после выгрузки домена, не компилировать его обратно, а загрузить например сразу из dll?

    Спасибо за внимание! Буду благодарен если вы уделите внимание и ответите на вопросы

     
    24 июля 2013 г. 12:46

Ответы

  • "Как долго по времени домен может не выгружаться в стандартном случае? Может ли это настраиваться?" - прямых настроек именно для домена нет. Но вот есть масса параметров которые влияют на время жизни домена. Это в первую очередь время жизни самого пула приложения (w3wp), которое настраивается. Максимальная очередь запросов, лимит памяти и т.п. Ошибки и исключения. Также изменение файлов приложение. Т.е. домен не выгружается пока не наступит одно из этих событий.

    "Не сохраняется ли сам скомпилированный класс HttpApplication тоже, чтобы после выгрузки домена, не компилировать его обратно, а загрузить например сразу из dll?" - не совсем понял, что тут имеется ввиду. Но если правильно понял, то: повторно ничего не компилируется. Класс приложения компилиркется во время компиляции проекта, и повторно ничего не нужно собирать. Т.е. при повторной загрузке dll он загружается прямо из той же библиотеки.


    Сделаем содержимое сообщества лучше, вместе!

    • Помечено в качестве ответа Higgs.Boson 25 июля 2013 г. 6:36
    • Снята пометка об ответе Higgs.Boson 25 июля 2013 г. 9:35
    • Помечено в качестве ответа Higgs.Boson 25 июля 2013 г. 18:03
    24 июля 2013 г. 19:28
    Модератор
  • Теперь уже понятно. "вот там как раз говорится о компиляции HttpApplication. Вот непонятно, всегда ли сохраняется скомпилированный HttpApplication в dll, чтобы заново не делать компиляцию при выгрузке домена." - дело в том, что статья была написана в 2006 году, а во времена visual studio 2005 не было проекта веб-приложения, она была добавлена позже. Была модель веб-сайта (безпроектной разработки). Так вот в модели веб-сайта, приложение компилируется не во время разработки, а во время запуска. Скорее всего в статье имеется ввиду именно это. Так как в нынешних проектах класс приложения компилируется в сборку, и повторная перекомпиляция не нужна.

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

    "И еще. При изменении файлов страниц, заставляющих пересобирать (перекомпилировать) HttpApllication, уничтожаются ли сессионные данные??? В случае встроенной в домен структуры сессий (mode=InProc), в случае aspnet_state.exe (mode=StateServer)?" в первом случае да, во втором нет (после перезапуска домена данные сесси не теряются, так как находятся в отдельном процессе).


    Сделаем содержимое сообщества лучше, вместе!

    • Помечено в качестве ответа Higgs.Boson 25 июля 2013 г. 6:35
    • Снята пометка об ответе Higgs.Boson 25 июля 2013 г. 9:35
    • Помечено в качестве ответа Higgs.Boson 25 июля 2013 г. 18:03
    25 июля 2013 г. 5:41
    Модератор
  • В случае с MVC стопроцентно сказать не могу, не пробовал, но думаю так как инфраструктура одна, то и там должно быть так же. При модификации файлов aspx домен перезапускается. "Получается при каждом обращении, содержимое страницы может меняться, получается каждый раз происходит перекомпиляция и загрузка новой сборки в домен."- под изменением страницы подразумевается физическое изменение файла, а то что данные подставляются в него динамически не в счёт. Переход на новый домен происходит плавно. В некоторый момент существуют два домена. Новый обрабатывает новые запросы, старый иничтожается по завершении обработки старых запросов ( данные сеанса которого существовали в нём). "Так получается что домен "распухает" с каждым очередным запросом?" - особой нагрузки это не несёт, так как сама природа домена в .NET легковесна, по сравнению с понятием "процесс" в Windows. Да и подобное часто наблюдается на этапе разработки и тестирования, а на промышленных серверах мало кто прибегает к этому, разве только в крайнем случае.

    Сделаем содержимое сообщества лучше, вместе!

    • Помечено в качестве ответа Higgs.Boson 25 июля 2013 г. 18:03
    25 июля 2013 г. 17:48
    Модератор
  • Статья которую нашли вы наверное самая детальная и подробная, но это всего лишь "вершина айсберга". Я хотел написать подобную, как в случае с MVC (которую тоже по причине нехватки времени пока ещё не закончил). Более подробных обзоров я не встречал, может их попросту нет. Но к счастью символы отладки .NET доступны для загрузки, можете их загрузить и просматривать работу управляемого конвейера. Я именно так и делаю в свободное время. Детальнее этого думаю некуда,  а будут вопросы смело задавайте.

    Сделаем содержимое сообщества лучше, вместе!

    • Помечено в качестве ответа Higgs.Boson 18 сентября 2013 г. 11:59
    25 июля 2013 г. 18:11
    Модератор
  • Декомпиляция неуправляемого кода намного сложнее, чем управляемого. Но вот начиная с IIS 7  весь конвейер работает в управляемом режиме, и острой необходимости "копать" дальше нет. Но если есть свободное время, то почему бы и нет. Но вот помимо этого советую посвятить время другим немаловажным частям платформы ASP.NET.

    Сделаем содержимое сообщества лучше, вместе!

    • Помечено в качестве ответа Higgs.Boson 18 сентября 2013 г. 11:59
    25 июля 2013 г. 18:30
    Модератор

Все ответы

  • "Как долго по времени домен может не выгружаться в стандартном случае? Может ли это настраиваться?" - прямых настроек именно для домена нет. Но вот есть масса параметров которые влияют на время жизни домена. Это в первую очередь время жизни самого пула приложения (w3wp), которое настраивается. Максимальная очередь запросов, лимит памяти и т.п. Ошибки и исключения. Также изменение файлов приложение. Т.е. домен не выгружается пока не наступит одно из этих событий.

    "Не сохраняется ли сам скомпилированный класс HttpApplication тоже, чтобы после выгрузки домена, не компилировать его обратно, а загрузить например сразу из dll?" - не совсем понял, что тут имеется ввиду. Но если правильно понял, то: повторно ничего не компилируется. Класс приложения компилиркется во время компиляции проекта, и повторно ничего не нужно собирать. Т.е. при повторной загрузке dll он загружается прямо из той же библиотеки.


    Сделаем содержимое сообщества лучше, вместе!

    • Помечено в качестве ответа Higgs.Boson 25 июля 2013 г. 6:36
    • Снята пометка об ответе Higgs.Boson 25 июля 2013 г. 9:35
    • Помечено в качестве ответа Higgs.Boson 25 июля 2013 г. 18:03
    24 июля 2013 г. 19:28
    Модератор
  • ТОт момент который Вам не понятен (может я не правильно поставил вопрос) изложен тут в разделе "Парсинг и компиляция ASP.NET-файлов" вот там как раз говорится о компиляции HttpApplication. Вот непонятно, всегда ли сохраняется скомпилированный HttpApplication в dll, чтобы заново не делать компиляцию при выгрузке домена.

    И еще. Вопрос уже касается самой выгрузки домена, но уже связанный с сессией. При выгрузке домена (при настройке в web.config mode=InProc), т.к. сессионые данные создаются в самом домене приложения, то, соответсвенно они будут уничтожаться. Из собственного опыта, эта сессия очень долго может не затираться, выходит, что домен не выгружается все это время? Или есть некие внутренние механизмы, которые при выгрузке домена, сохраняют сесиию куда-нибудь, а потом восстанавливает? или на самом деле это так долго не выгружается домен?

    И еще. При изменении файлов страниц, заставляющих пересобирать (перекомпилировать) HttpApllication, уничтожаются ли сессионные данные??? В случае встроенной в домен структуры сессий (mode=InProc), в случае aspnet_state.exe (mode=StateServer)?

    Спасибо!



    • Изменено Higgs.Boson 24 июля 2013 г. 20:20 dfhdgfjsfdfhsr
    24 июля 2013 г. 19:52
  • Теперь уже понятно. "вот там как раз говорится о компиляции HttpApplication. Вот непонятно, всегда ли сохраняется скомпилированный HttpApplication в dll, чтобы заново не делать компиляцию при выгрузке домена." - дело в том, что статья была написана в 2006 году, а во времена visual studio 2005 не было проекта веб-приложения, она была добавлена позже. Была модель веб-сайта (безпроектной разработки). Так вот в модели веб-сайта, приложение компилируется не во время разработки, а во время запуска. Скорее всего в статье имеется ввиду именно это. Так как в нынешних проектах класс приложения компилируется в сборку, и повторная перекомпиляция не нужна.

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

    "И еще. При изменении файлов страниц, заставляющих пересобирать (перекомпилировать) HttpApllication, уничтожаются ли сессионные данные??? В случае встроенной в домен структуры сессий (mode=InProc), в случае aspnet_state.exe (mode=StateServer)?" в первом случае да, во втором нет (после перезапуска домена данные сесси не теряются, так как находятся в отдельном процессе).


    Сделаем содержимое сообщества лучше, вместе!

    • Помечено в качестве ответа Higgs.Boson 25 июля 2013 г. 6:35
    • Снята пометка об ответе Higgs.Boson 25 июля 2013 г. 9:35
    • Помечено в качестве ответа Higgs.Boson 25 июля 2013 г. 18:03
    25 июля 2013 г. 5:41
    Модератор
  • Спасибо!

    И, наверное, последний вопрос.

    Когда компилируется страница (в случае ASP.net web forms), из двух файлов *.aspx и соответствующему ему серверной *.aspx.cs создаются сборки и загружаются в домен. Но, вот мне не приходилось ни раз работать с web forms, но я знаю, что в случае MVC, в представлении можно модифицировать информацию в зависимости от результата алгоритма выполнения контроллера, в случае веб-формс наверное в aspx тоже можно так делать. Вот вопрос связан с этим. Получается при каждом обращении, содержимое страницы может меняться, получается каждый раз происходит перекомпиляция и загрузка новой сборки в домен. при чем известно, что "старый" код из домена не удаляется, пока не выгрузишь домен. Так получается что домен "распухает" с каждым очередным запросом?



    • Изменено Higgs.Boson 25 июля 2013 г. 9:58 ываывппавап
    25 июля 2013 г. 6:35
  • В случае с MVC стопроцентно сказать не могу, не пробовал, но думаю так как инфраструктура одна, то и там должно быть так же. При модификации файлов aspx домен перезапускается. "Получается при каждом обращении, содержимое страницы может меняться, получается каждый раз происходит перекомпиляция и загрузка новой сборки в домен."- под изменением страницы подразумевается физическое изменение файла, а то что данные подставляются в него динамически не в счёт. Переход на новый домен происходит плавно. В некоторый момент существуют два домена. Новый обрабатывает новые запросы, старый иничтожается по завершении обработки старых запросов ( данные сеанса которого существовали в нём). "Так получается что домен "распухает" с каждым очередным запросом?" - особой нагрузки это не несёт, так как сама природа домена в .NET легковесна, по сравнению с понятием "процесс" в Windows. Да и подобное часто наблюдается на этапе разработки и тестирования, а на промышленных серверах мало кто прибегает к этому, разве только в крайнем случае.

    Сделаем содержимое сообщества лучше, вместе!

    • Помечено в качестве ответа Higgs.Boson 25 июля 2013 г. 18:03
    25 июля 2013 г. 17:48
    Модератор
  • Начал глубже изучать asp.net - такая сложная штука, и как вообще работает, стоит только удивляться. А если вспомнить историю создания, то его насколько я помню сырую версию написали в течении рождественских каникул.

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

    Спасибо за помощь. Без Вас освоить это было бы непосильно.

    Есть какие-нибудь статьи в таком же духе? Вы наверняка знаете хорошие
    • Изменено Higgs.Boson 25 июля 2013 г. 18:04 Поправка
    25 июля 2013 г. 18:03
  • Статья которую нашли вы наверное самая детальная и подробная, но это всего лишь "вершина айсберга". Я хотел написать подобную, как в случае с MVC (которую тоже по причине нехватки времени пока ещё не закончил). Более подробных обзоров я не встречал, может их попросту нет. Но к счастью символы отладки .NET доступны для загрузки, можете их загрузить и просматривать работу управляемого конвейера. Я именно так и делаю в свободное время. Детальнее этого думаю некуда,  а будут вопросы смело задавайте.

    Сделаем содержимое сообщества лучше, вместе!

    • Помечено в качестве ответа Higgs.Boson 18 сентября 2013 г. 11:59
    25 июля 2013 г. 18:11
    Модератор
  • Вот конечно хотелось бы разобрать еще класс ISAPIRuntime с HttpWorkerRequest которые какбы являются мостом между IIS и приложением ASP.nET. Я изучал через ILSpy, но там он уже взаимодействует с win32. К сожалению в win32 мои познания очень слабые. Поэтому я это оставил на потом.
    • Изменено Higgs.Boson 25 июля 2013 г. 18:30 Поправка
    25 июля 2013 г. 18:24
  • Декомпиляция неуправляемого кода намного сложнее, чем управляемого. Но вот начиная с IIS 7  весь конвейер работает в управляемом режиме, и острой необходимости "копать" дальше нет. Но если есть свободное время, то почему бы и нет. Но вот помимо этого советую посвятить время другим немаловажным частям платформы ASP.NET.

    Сделаем содержимое сообщества лучше, вместе!

    • Помечено в качестве ответа Higgs.Boson 18 сентября 2013 г. 11:59
    25 июля 2013 г. 18:30
    Модератор
  • Да вроде и начинал ведь с важных частей конвейера asp.net. Обложился 3-4 статьями, книгами, в том числе Вашей серией статей про конвейер обработки запросов. И как начнешь изучать, понимаешь, что этого ты не знаешь, идешь глубже, а потом выясняется, что это непонятно как работает, еще глубже спускаешься, в итоге чуть ли не в http.sys начинаешь разбираться. И в итоге получается, что лучше изучать прям с самых истоков конвейера.
    25 июля 2013 г. 18:41