IIS App init 筆記
改完setting要行iisreset先會生效.
Call svc / default 有無分別
App init 會行完application_start, 如throw exception 唔會自已重試, 直到下一個client call. 至於Call .svc跟 直接call directory的分別暫時已知有一個, 如果MEX endpoint 為enable時, 當.svc收到第一個http get request先會開始generate 個Metadata, 包括掃一次所有暴露出街的class, 而所需時間會依據數量而增加(所以公司個____ service咁慢). 但[慢]只係講緊gen個meta慢, 個service其實已經起好左, call d method都係秒速回應.
至於點解個metadata要等收到第一個call先gen, 而唔係app init個度做埋就待研究=.=
https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/startup-time-of-wcf-client-applications-using-the-xmlserializer
AutoStart:
StartMode: Always Running 就會殺左個Process都識自已起返**不等於做application initialization, worker process = container/pool of sites..
serverAutoStart
preloadEnabled:
serviceAutoStartEnabled:
started = 全部Application_started, 就算application start超耐都唔會有個gap
Update web.config又會唔會INIT?
睇serviceAutoStartEnabled, 唔關application initialization.
application initlization for recycle only?
The response times for the first requests in an Overlapped Recycling scenario are reduced by also pre-loading dependencies. The recycled worker process will only communicate its readiness and will start accepting requests after it finishes loading and initializing the resources as specified by the configuration.
https://www.iis.net/downloads/microsoft/application-initialization
Why first call is a bit slow?
Usually the first call takes more time because in that call the
https://stackoverflow.com/questions/10859832/why-is-the-first-wcf-client-call-slow
preLoadEnabled
Optional Boolean attribute.
Specifies that IIS simulates a user request to the default page of an application or virtual directory so that it is initialized. In effect IIS starts the application when the application pool is started without having received a request. This increases performance by performing initialization tasks such as loading managed modules and compiling managed code. No log is generated in the IIS logs. The application pool's startMode setting must be set to
The default value is
https://docs.microsoft.com/en-us/iis/configuration/system.applicationhost/sites/site/applicationdefaults
-------
未裝之前:
唔識overlap recycle,一按recycle就會殺原有process
-----
裝左之後:
(Application set to always running and site set preloadenabled is okay already= =")
識overlap recycle, 會行完Application_start先至殺(唔會有個GAP位) 做到seamless recycle.
---
Monitoring:
https://gallery.technet.microsoft.com/scriptcenter/Script-to-monitor-3b7c571f
----
Reading:
https://blogs.msdn.microsoft.com/msdntaiwan/2014/04/15/iis-asp-net-iis/
http://www.codingblog.cn/blog/80992.html
https://blog.johnwu.cc/article/iis-optimized-setting.html
https://forums.asp.net/t/1909234.aspx?preloadenabled+and+serviceAutoStartProvider+in+web+application
Advantages of using IIS recycling feature
. All the clients can connect IIS server, and every requests will be handled without downtime.
. There’s no connection loss.
. Faster operation than IISRESET to initialize system resource(memory).
Common problems of IISRESET & Recycling
. Any data, stored in a worker process(W3WP.EXE) will be lost.
: In-Proc session state, compiled binaries of ASP/ASP.NET in a process memory, application cache
ref: https://fullsocrates.wordpress.com/2012/07/25/iisreset-vs-recycling-application-pools/
userDeaultWebProxy = "False" <-將第一個call由兩秒減到秒開
https://social.msdn.microsoft.com/Forums/vstudio/en-US/1acc0774-2f29-4c41-83c7-e889b3a32520/wcf-first-call-seems-to-be-very-slow-from-the-client-any-idea?forum=wcf
try use url rewrite for http warm up message, as app init dont support https
---------------------------6月23 日更新-----------------------------------------------------------------------------------------
好喇因應Change controller要求 順便當學習 整左個program仔去狂call WCF Service 去驗証app init既功效~~
一個簡單既WCF, 唯獨係係佢Application Start時迫佢會總共Sleep 10秒, 容易D睇到佢個效果, 另外有一個method Ping() 就咁return True
C# Console App:
Set 到個binding SendTimeout 得一秒, 總之令到佢一秒內return唔到就當timeout
Client-side Timeouts
On the client side:
SendTimeout – used to initialize the OperationTimeout, which governs the whole process of sending a message, including receiving a reply message for a request/reply service operation. This timeout also applies when sending reply messages from a callback contract method.
OpenTimeout – used when opening channels when no explicit timeout value is specified.
CloseTimeout – used when closing channels when no explicit timeout value is specified.
ReceiveTimeout – is not used.
Service-side Timeouts
On the service side:
SendTimeout, OpenTimeout, CloseTimeout are the same as on the client.
ReceiveTimeout – used by the Service Framework Layer to initialize the session-idle timeout which controls how long a session can be idle before timing out.
Ref: https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/configuring-timeout-values-on-a-binding
裝app init之前, IIS site剛剛start:
裝完App init, set好哂config 後:
後記: 係自已機debug 用iisexpress host,再用WcfTestClient Add service果陣一路都無問題. 但當掉去行緊IIS7.5, Windows Server 08R2 既virtual box 果陣就唔知點解ADD極都唔得,個error類似
XPath: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:portType
定乜鬼,搞左成半日, 最後係VM入面既C:/Windows/Temp加返IIS USER D permission就得左, 唔知點解-,-
上次整左以下三個method:
process(由process ID睇得出) 會等到新果個READY先會route request去新果個, 同時殺舊個process.
而最下果個method 我估因為支thread/connection/session已經死左, 所以一
recycle會即死@@?
點解我update完webconfig 無trigger到 application_start架~~
用返上面三個CALL黎試, 就算裝左application_init, 係佢行緊果陣update webconfig, 都係除左最尾個CALL會即死外, 上面2個都會繼續行, 但行完之後下一個call又會觸發application_init, 而process id不變.
因為次次recycle完個process id 都會轉的 有人就咁講, 話因為改web config係reload appdomain, 而唔係application pool, 一個process = application pool
https://forums.iis.net/t/1214971.aspx?Application_Start+not+firing+on+change+of+web+config
13/7/2018 update----------------------------------------
話說intern整左個Check Health既asp.net , 個概念就係放係IIS Top site個directory度, 咁一開佢就會掃哂所有同一site之下既.svc file, 睇下有無error, 咁就發現每次update左最上層個webconfig果時, 所有下面既application 既appdomain都似乎upload左, 變左下一次CALL先會行application_start, 就變到好慢>_<
睇返msdn 有段咁既野:
Configuration level
估計應該同呢個有關, 所以一改就等於郁哂之下既所有application的web.config
https://msdn.microsoft.com/en-us/library/ms178685.aspx
延申閱讀: https://weblogs.asp.net/jongalloway/10-things-asp-net-developers-should-know-about-web-config-inheritance-and-overrides
https://www.treeloop.com/blog/iis-application-domain-and-pool-recycling
15/7/2018 小小測試----------------------------------------------
*已裝app init
16/7/2018 Deploy Script Test--------------------------------
ApplicationPool 相關:
AutoStart
StartMode
IDLETime
Recycle Time
Site 相關:
serverAutoStart
Application 相關:
serviceAutoStart
preloadEnabled
第一條script:
"C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy" -verb:sync -source:apphostconfig="NathanTesting" -dest:apphostconfig="NathanTesting",computername=server1
^除了ApplicationPool 相關之外的settings會全抄
第二條:
"C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy" -verb:sync -source:apphostconfig="NathanTesting" -enableLink:AppPoolExtension -dest:apphostconfig="NathanTesting",computername=server1
^全部都抄
第三條:
"C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy" -verb:sync -source:apphostconfig="NathanTesting" -enableLink:AppPoolExtension -skip:objectName=recycling -dest:apphostconfig="NathanTesting",computername=server1
^同2一樣 不過會SKIP哂recycle類既野.
| 裝warmup 前的設定. |
| 裝warmup前的設定(2). |
| After |
| After(2) |
Call svc / default 有無分別
App init 會行完application_start, 如throw exception 唔會自已重試, 直到下一個client call. 至於Call .svc跟 直接call directory的分別暫時已知有一個, 如果MEX endpoint 為enable時, 當.svc收到第一個http get request先會開始generate 個Metadata, 包括掃一次所有暴露出街的class, 而所需時間會依據數量而增加(所以公司個____ service咁慢). 但[慢]只係講緊gen個meta慢, 個service其實已經起好左, call d method都係秒速回應.
至於點解個metadata要等收到第一個call先gen, 而唔係app init個度做埋就待研究=.=
https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/startup-time-of-wcf-client-applications-using-the-xmlserializer
AutoStart:
StartMode: Always Running 就會殺左個Process都識自已起返**不等於做application initialization, worker process = container/pool of sites..
serverAutoStart
preloadEnabled:
serviceAutoStartEnabled:
started = 全部Application_started, 就算application start超耐都唔會有個gap
Update web.config又會唔會INIT?
The difference between sites and application pools.
application initlization for recycle only?
The response times for the first requests in an Overlapped Recycling scenario are reduced by also pre-loading dependencies. The recycled worker process will only communicate its readiness and will start accepting requests after it finishes loading and initializing the resources as specified by the configuration.
https://www.iis.net/downloads/microsoft/application-initialization
Why first call is a bit slow?
Usually the first call takes more time because in that call the
Channel Factory is instantiated and prepared ready for the communication and that costs time. The created Channel Factory will be cached and reused in subsequent calls and so the time will be lesshttps://stackoverflow.com/questions/10859832/why-is-the-first-wcf-client-call-slow
preLoadEnabled
Optional Boolean attribute.
Specifies that IIS simulates a user request to the default page of an application or virtual directory so that it is initialized. In effect IIS starts the application when the application pool is started without having received a request. This increases performance by performing initialization tasks such as loading managed modules and compiling managed code. No log is generated in the IIS logs. The application pool's startMode setting must be set to
AlwaysRunning.The default value is
False.https://docs.microsoft.com/en-us/iis/configuration/system.applicationhost/sites/site/applicationdefaults
-------
未裝之前:
唔識overlap recycle,一按recycle就會殺原有process
-----
裝左之後:
(Application set to always running and site set preloadenabled is okay already= =")
識overlap recycle, 會行完Application_start先至殺(唔會有個GAP位) 做到seamless recycle.
---
Monitoring:
https://gallery.technet.microsoft.com/scriptcenter/Script-to-monitor-3b7c571f
----
Reading:
https://blogs.msdn.microsoft.com/msdntaiwan/2014/04/15/iis-asp-net-iis/
http://www.codingblog.cn/blog/80992.html
https://blog.johnwu.cc/article/iis-optimized-setting.html
https://forums.asp.net/t/1909234.aspx?preloadenabled+and+serviceAutoStartProvider+in+web+application
Advantages of using IIS recycling feature
. All the clients can connect IIS server, and every requests will be handled without downtime.
. There’s no connection loss.
. Faster operation than IISRESET to initialize system resource(memory).
Common problems of IISRESET & Recycling
. Any data, stored in a worker process(W3WP.EXE) will be lost.
: In-Proc session state, compiled binaries of ASP/ASP.NET in a process memory, application cache
ref: https://fullsocrates.wordpress.com/2012/07/25/iisreset-vs-recycling-application-pools/
userDeaultWebProxy = "False" <-將第一個call由兩秒減到秒開
https://social.msdn.microsoft.com/Forums/vstudio/en-US/1acc0774-2f29-4c41-83c7-e889b3a32520/wcf-first-call-seems-to-be-very-slow-from-the-client-any-idea?forum=wcf
try use url rewrite for http warm up message, as app init dont support https
---------------------------6月23 日更新-----------------------------------------------------------------------------------------
好喇因應Change controller要求 順便當學習 整左個program仔去狂call WCF Service 去驗証app init既功效~~
一個簡單既WCF, 唯獨係係佢Application Start時迫佢會總共Sleep 10秒, 容易D睇到佢個效果, 另外有一個method Ping() 就咁return True
C# Console App:
Set 到個binding SendTimeout 得一秒, 總之令到佢一秒內return唔到就當timeout
Client-side Timeouts
On the client side:
SendTimeout – used to initialize the OperationTimeout, which governs the whole process of sending a message, including receiving a reply message for a request/reply service operation. This timeout also applies when sending reply messages from a callback contract method.
OpenTimeout – used when opening channels when no explicit timeout value is specified.
CloseTimeout – used when closing channels when no explicit timeout value is specified.
ReceiveTimeout – is not used.
Service-side Timeouts
On the service side:
SendTimeout, OpenTimeout, CloseTimeout are the same as on the client.
ReceiveTimeout – used by the Service Framework Layer to initialize the session-idle timeout which controls how long a session can be idle before timing out.
Ref: https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/configuring-timeout-values-on-a-binding
裝app init之前, IIS site剛剛start:
![]() |
| 可以睇到 個Service無preload, 要靠個program仔第一個call去[踼著]佢, 而因為Application_Start入面既Thread.Sleep,而令到佢有一段時間Timeout左. |
![]() |
| 試下手動recycle佢, 同樣要等果十秒init, 從而令到downtime出現 |
![]() |
| 同樣地update webconfig結果同recycle一樣, 都係有個GAP位 備注: 以上三個動作 都需要有第一個call先會行application_initialization果十秒.
咁至於裝完之後會有咩唔同呢~~~
|
![]() |
| 剛Start service, 可以見到時間比未裝時短, 因為唔洗等個program call, IIS已經自已整左個假request 去自已預先init |
![]() |
| Recycle果陣我禁左兩下, 見到同時間有兩個instance 係度行緊application_initialization. 呢度見到無downtime即表示Overlapped recycle發揮作用 |
![]() |
| 至於update Web config則同樣會有down time |
後記: 係自已機debug 用iisexpress host,再用WcfTestClient Add service果陣一路都無問題. 但當掉去行緊IIS7.5, Windows Server 08R2 既virtual box 果陣就唔知點解ADD極都唔得,個error類似
XPath: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:portType
定乜鬼,搞左成半日, 最後係VM入面既C:/Windows/Temp加返IIS USER D permission就得左, 唔知點解-,-
上次整左以下三個method:
[OperationContract]
public void LongProcess(int val)
{
WriteToFile("Received LongProcess: " + val);
for (int i = 0; i < val; i++)
{
WriteToFile(i.ToString());
Thread.Sleep(1000);
}
WriteToFile("LongProcess completed");
}
[OperationContract(IsOneWay = true)]
public void OneWayLongProcess(int val)
{
WriteToFile("Received OneWayLongProcess: " + val);
for (int i = 0; i < val; i++)
{
WriteToFile(i.ToString());
Thread.Sleep(1000);
}
WriteToFile("OneWayLongProcess completed");
}
[OperationContract]
public bool NewThreadTest(int val)
{
Action a = new Action(() =>
{
string path = AppDomain.CurrentDomain.BaseDirectory + @"\NewThreadTest.log";
System.IO.File.AppendAllText(path, "Received val: " + val);
for (int i = 0; i < val; i++)
{
System.IO.File.AppendAllText(path, Environment.NewLine + i);
Thread.Sleep(1000);
}
System.IO.File.AppendAllText(path, Environment.NewLine + "done.");
});
Task.Factory.StartNew(a);
return true;
}
除左最下開新thread個method外, 其他都可以受惠於app init, 總之會做埋先回收本身個process(由process ID睇得出) 會等到新果個READY先會route request去新果個, 同時殺舊個process.
而最下果個method 我估因為支thread/connection/session已經死左, 所以一
recycle會即死@@?
點解我update完webconfig 無trigger到 application_start架~~
用返上面三個CALL黎試, 就算裝左application_init, 係佢行緊果陣update webconfig, 都係除左最尾個CALL會即死外, 上面2個都會繼續行, 但行完之後下一個call又會觸發application_init, 而process id不變.
因為次次recycle完個process id 都會轉的 有人就咁講, 話因為改web config係reload appdomain, 而唔係application pool, 一個process = application pool
https://forums.iis.net/t/1214971.aspx?Application_Start+not+firing+on+change+of+web+config
13/7/2018 update----------------------------------------
話說intern整左個Check Health既asp.net , 個概念就係放係IIS Top site個directory度, 咁一開佢就會掃哂所有同一site之下既.svc file, 睇下有無error, 咁就發現每次update左最上層個webconfig果時, 所有下面既application 既appdomain都似乎upload左, 變左下一次CALL先會行application_start, 就變到好慢>_<
睇返msdn 有段咁既野:
Configuration level
| File name | File description | |
|---|---|---|
| Server | Machine.config | The Machine.config file contains the ASP.NET schema for all of the Web applications on the server. This file is at the top of the configuration merge hierarchy. |
| Root Web | Web.config | The Web.config file for the server is stored in the same directory as the Machine.config file and contains default values for most of the system.web configuration sections. At run time, this file is merged second from the top in the configuration hierarchy. |
| Web site | Web.config | The Web.config file for a specific Web site contains settings that apply to the Web site and inherit downward through all of the ASP.NET applications and subdirectories of the site. |
| ASP.NET application root directory | Web.config | The Web.config file for a specific ASP.NET application is located in the root directory of the application and contains settings that apply to the Web application and inherit downward through all of the subdirectories in its branch. |
| ASP.NET application subdirectory | Web.config | The Web.config file for an application subdirectory contains settings that apply to this subdirectory and inherit downward through all of the subdirectories in its branch. |
| Client application directory | ApplicationName.config | The ApplicationName.config file contains settings for a Windows client application (not a Web application). |
| IIS | ApplicationHost.config | ApplicationHost.config is the root file of the
IIS 7.0 configuration system. It includes definitions of all sites,
applications, virtual directories, and application pools, as well as
global defaults for the Web server settings. It is in the following
location: %windir%\system32\inetsrv\config |
估計應該同呢個有關, 所以一改就等於郁哂之下既所有application的web.config
https://msdn.microsoft.com/en-us/library/ms178685.aspx
延申閱讀: https://weblogs.asp.net/jongalloway/10-things-asp-net-developers-should-know-about-web-config-inheritance-and-overrides
https://www.treeloop.com/blog/iis-application-domain-and-pool-recycling
15/7/2018 小小測試----------------------------------------------
*已裝app init
| IISRESET | Recycle | Edit web.config | |
| One way long process | 繼續做最多20秒(iisreset default, 可以改) 跟住會自已重開 | 做完先死, 跟住會自已重開(仲識得overlap reclcye) | 唔包會做完 唔知等幾耐就會殺... |
| NewThreadTest | 即死 | 做做多唔知幾多十秒.. | 即死 |
16/7/2018 Deploy Script Test--------------------------------
ApplicationPool 相關:
AutoStart
StartMode
IDLETime
Recycle Time
Site 相關:
serverAutoStart
Application 相關:
serviceAutoStart
preloadEnabled
第一條script:
"C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy" -verb:sync -source:apphostconfig="NathanTesting" -dest:apphostconfig="NathanTesting",computername=server1
^除了ApplicationPool 相關之外的settings會全抄
第二條:
"C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy" -verb:sync -source:apphostconfig="NathanTesting" -enableLink:AppPoolExtension -dest:apphostconfig="NathanTesting",computername=server1
^全部都抄
第三條:
"C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy" -verb:sync -source:apphostconfig="NathanTesting" -enableLink:AppPoolExtension -skip:objectName=recycling -dest:apphostconfig="NathanTesting",computername=server1
^同2一樣 不過會SKIP哂recycle類既野.









留言
張貼留言