2013年6月14日 星期五

System.Transactions 裡的 Timeouts 與 Azure 中的設定

在進行交易的過程中,主要有三個 Timeout 時間。而真正的可交易時間,是取下面三者的最小值。

Command.CommandTimeout

這個 timeout 是最基本的 Timeout 時間,預設為 30 秒。這個設定是執行sql指令的可執行時間。

TransactionScope 的Timeout

在執行交易時,TransactionScope 也有一個 Timeout 時間。這個時間是由 TransactionScope 的建構子中的參數來指定的。預設值是60秒,可由 TransactionManager.DefaultTimeout 取得設定值。

TransactionManager 的  MaximumTimeout

TransactionManager 裡頭也有一個 timeout。這個 timeout 時間是是全機的交易管理員的最大可交易的時間。在 .NET 2.0 預設可由子層的 config 或程式來覆寫。但在 .NET 4.0,就不能被子層來覆寫了,如果需要修改,則必須到 %windir%\Microsoft.NET\Framework\v4.0.30319\Config\machine.config (32 位元),或 %windir%\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config 中以管理員的權限進行修改。

<system.transactions>
    <machineSettings maxTimeout="02:00:00" />
</system.transactions>

Azure 中設定

微軟的 Windows Azure Cloud Service 環境中,當然我們可以使用遠端桌面的方式,連線到每個伺服器進行上述的修改。但是一旦重新掛載作業系統後,這些人工設定又全部跑掉必須重設,非常不人道。幸好部署時有 Start Task 的機制, 可以執行 cmd 的指令。cmd 指令如下

windir%\system32\inetsrv\appcmd set config /commit:MACHINE /clr:4 -section:machineSettings -maxTimeout:02:00:00

此指令必須寫成 .cmd 檔,放在 WebRole 或 WorkerRole 的 project 內,以 content/Always copy to Output Directory 的型式加入專案

image   image

接著,在Azure 專案的 ServiceDefinition.csdef 中加上 Startup Task 的指令

<Startup>
  <Task commandLine="timeout.cmd" executionContext="elevated" taskType="simple" />
</Startup>

如下圖

image

其中 executeContext=”elevated” 指的是必須以管理員的權限進行修改

結論

TransactionScope 的 Timeout 設定有點複雜,除了.NET 版本,32/64 版本,%windir%\system32\ 與 %windir%\SysWOW64\ 的不同外,現在又增加了雲端的設定。真是不太容易。

參考

  1. http://stackoverflow.com/questions/1348191/default-transaction-timeout
  2. https://github.com/Aaronontheweb/azure-webroleperformance-scripts
  3. http://blogs.inkeysolutions.com/2012/01/managing-timeouts-while-using.html

2013年6月13日 星期四

jQuery 取得 checkbox 至少有一個選取

客戶的需求中,「當使用者至少要選取一筆資料才能進行下一個動作」。常見的 UI 設計,當然是使用 checkbox。

而我的 case,是資料有一萬多筆,此時整個網頁非常痴肥而難以接受。問題是,客戶就是要這樣的網頁,客戶拒絕分頁

jQuery length

問題來了,此時我使用了如下的 jQuery 語法查詢是否有選取一個 checkbox

var isChecked = $('input[name=chk]:checked').length > 0;

相當然爾,網頁就硬生生當在那裡,動也不能動。效能不好

jQuery is

根據我「多年」「 .NET」的經驗,使用 length 等同於計算所有被勾選的項目,然後再計算出總筆數,這樣的效能當然不好啊。於是趕快找一找 jQuery document,很快的就發現了 jQuery is 非常符合我的需求。於是馬上改了程式

   1: var isChecked = $('input[name=chk]')is(':checked');

滿心期待效能飛快,但「更慢了」。怎麼會…

效能比較

找到一個測試,也證實了這樣的結果。怎麼會這樣…

另外,又找了一個 checkboxtests,這次加入了自己寫的 .each() 來測試是否會比較快?結論是:不會。

心得

到了 javascript 的世界,以前許多經驗值就必須大打折扣了。

2013年6月3日 星期一

將 Visual Studio 打包好的 package 佈署到 IIS 6

之前的許多經驗,都是把打包好的 package 佈署到 IIS 7 以上的版本。此中又依據權限,再分成管理員權限的佈署及非管理員權限的佈署方式

這次,我被要求佈署到 IIS 6 上了。

IIS 6

我之前的態度,是一味地以「Windows Server 2003 大舊了,現在沒有人在用了」來推託一翻。雖然言之有理,但其是一大部份原因是:懶!
然而,債還是要還的。客戶出錢,我們做人家小的還是要出力,即使入不敷出。

IIS 6 與之後的 IIS 7有個根本上的不同,是IIS 7 對 metabase 的全面改版,並且 IIS 7 可支援非管理員來管理 IIS。在 Visual Studio 發行的結果,是對 Web Deploy 是再包裝過精簡後的工具,處理的對象是  IIS 7 的 metabase。對於 IIS 6,只能自行尋找文件。

如果直接使用 Visual Studio 所產出的 cmd 指令執行到 IIS 6,會出現如下的錯誤訊息。

SNAGHTML243900aa

使用 MSDeployAgentService

在同一個目錄中,可以找到 Visual Studio 為我們寫好的 readme 檔案,其實裡面已經寫的很清楚了,是可以使用這些工具部署到 IIS 6的。

The service URL can also be in the following format:
        http://<DestinationServer>/MSDeployAgentService 
    This format requires administrative rights on the destination server, and it requires that Web Deploy Remote Service (MsDepSvc) be installed on the destination server. IIS 7 does not have to be installed on the destination server.

也就是說, 我們必須使用 http://serverName/MSDeployAgentService 使用管理員權限來進行部署。

改一下指令,如下

package.cmd /T /M:http://localhost/MSDeploymentService

結果不如人願,非常類似的錯誤訊息還是打擊了我一下。

SNAGHTML2429b1de

解法

注意到了問題了嗎?另一個重點在於 Metabase 路徑,新舊版本不一樣。所以,我偷偷修改了SetParameters.xml,由原來的

<setParameter name="IIS Web Application Name" value="Default Web Site/myApp" />

改成

<setParameter name="IIS Web Application Name" value="/lm/w3svc/1/ROOT/myApp" />

再執行相同的指令

package.cmd /T /M:http://localhost/MSDeploymentService

就完成了我的需求了。

其實,如果是在本機的話,指定機器的 /M 指令也不用加了。只需要

package.cmd /T 即可

進階

由於使用了 MSDeploymentService,就必須使用管理員的權限。既然是管理員權限,在別台機器(只需要安裝 Web Deploy Tool)當然也可以下指令,不必遠端桌面登入到該伺服器。

package.cmd /Y /M:http://serverIpOrHostName/msdeployagentService /U:administrator /P:Password

PS: 對部署來說,這個權限要求實在大到不行,對於無限上綱的資訊安全管理說,就是很好發揮的題材。誰叫你還要用 Windows Server 2003 呢?

Share with Facebook