15

公司的Sharepoint Portal(現在應該叫MOSS，但我老覺得會跟摩斯漢堡搞混)上線後，效能一直不太理想。

在Portal中，我們有另外開發了一些Web Application程式，有ASP也有ASPX，掛在SPS的網站下建成Virtual Directory。結果一到尖峰時間，偶爾會發生所有的ASP/ASPX網頁就會傳回"Out of Memory"錯誤的狀況，但實際上w3wp.exe的記憶體用量大約在800M左右，整台機器的記憶體也還有剩，不像是記憶體真的耗盡，這些錯誤會在IISRESET後恢復正常，然後又可以再撐個一兩天。

由於沒有明確的Capacity數據可以參照，我們不確定是機器不夠力還是系統沒調好，只好且戰且走... 直到有一天在Event Log中看到一個怪異的ASP.NET 2.0 Error。

Event code: 3008
Event message: A configuration error has occurred.
Event time: 8/23/2007 12:53:03 PM
Event time (UTC): 8/23/2007 4:53:03 AM
Event ID: 19a6172d33a84ca299e93af831c8fe0b
Event sequence: 240346
Event occurrence: 1
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/1481090595/ROOT/NEWOA-1-128322900009164404
Trust level: Full
Application Virtual Path: /Blah
Application Path: D:\WWW\Blah\Boo\
Machine name: MOSSWEB1
Process information:
Process ID: 6000
Process name: w3wp.exe
Account name: MyDomain\SPSAccount
Exception information:
Exception type: ConfigurationErrorsException
Exception message: Could not create Windows user token from the credentials specified in the config file. Error from the operating system 'The parameter is incorrect.
' (c:\spsweb\protal\web.config line 122)
Request information:
Request URL: http  : //mossweb1.corp.com.tw/Blah/Images/Brown80.jpg
Request path: /Blah/Images/Brown80.jpg
User host address: 192.168.1.160
User:
Is authenticated: False
Authentication Type:
Thread account name: MyDomain\SPSAccount
Thread information:
Thread ID: 67
Thread account name: MyDomain\SPSAccount
Is impersonating: False
Stack trace: at System.Web.Configuration.IdentitySection.InitializeToken()
at System.Web.Configuration.IdentitySection.get_ImpersonateToken()
at System.Web.HttpContext.get_ImpersonationToken()
at System.Web.ClientImpersonationContext.Start(HttpContext context, Boolean throwOnError)
at System.Web.HttpApplication.OnThreadEnterPrivate(Boolean isThreadStateInitialized, Boolean setImpersonationContext)
at System.Web.HttpApplication.ApplicationStepManager.ResumeSteps(Exception error)
Custom event details:

啥? 只不過是JPG檔，怎麼也跟ASP.NET 2.0扯上關係?

後來，同事小熊子找到一個關鍵設定，原來WSS 3.0有個新設計，叫做SPVirtualPathProvider，它可以由WSS資料庫讀出檔案，有點URLRewrite的味道。但是他做了一個討厭的設定:

如上圖，所有掛在Sharepoint網站下的Virtual Dirctory都會繼承這個設定，Wildcard Application Maps意味著對任何檔案(包含htm, jpg, png, zip, ...)都要先透過ASP.NET檢查，這似乎就解釋了上面看到的那筆詭異JPG + ASP.NET 2.0 Error Event。

連jpg, css都需要經過ASP.NET來跑，會不會比較耗效能呢? 於是我用ACT(Application Center Test)做了多Thread連續讀取同一JPG檔的壓力測試，其中藍線為設定Wildcard Application Maps的情況，紫線是移除後的結果。實驗證明，關閉Wildcard Application Mapping後速度上升了約兩倍。

這個Wildcard Application Maps的效能殺傷力真有這麼恐怖? 我沒有足夠的證據/理論可以做此判決，至少，在關閉Sharepoint下這些自訂Web Application的該設定後，已經好久沒有看到Out of Memory Error囉!


Comments

# by Heidi

I used Google to translate your article and it seems like we have a similar problem with the same error message and out of memory exceptions. But I don't really understand the google translation of how you fixed the problem. Can anyone explain this for me in English or Swedish? Thank you!

# by Jeffrey

To Heidi, We met a serious performance problem where our MOSS site go live as a portal site for thousands-users. The asp/aspx throw out of memory excpetion in peak time even when the memory is still adequate. Someday when I found that a jpeg request throw ASP.NET 2.0 exception in IIS log, I knew something wrong and I understood that MOSS always set a wildcard app maps for Sharepont enabled web site and the setting force every request (html, jpeg, gif, css, js, asp...) to be processed by ASP.NET 2.0 framework and cause a very poor performance. After I removed the wildcard app maps setting from IIS, I got a 2.5 times speed up and the out-of-memory exception is gone. Hope these explaination can help you to understand the issue I met and how I solved it. Jeffrey

# by Heidi

Thank you Jeffrey! Now I understand. This is great information! This is the only site google had that refered to this error message - thanks so much for helping me. /heidi

# by Heidi

Are you using any Sharepoint caching? I just wonder why it is automatically configured on a sharepoint enabled site. Could there be a benefit to this configuration - perhaps for caching or perhaps for something else. regards, Heidi

# by Heidi

Are you using Sharepoint Caching? I am just wondering why the Wild Card Application Map is configured automatically for sharepoint enabled sites. Could it have a benefit? Maybe for caching?

# by Heidi

(sorry about the double post! I couldn't see it there when I checked - I hope you can delete the extras...)

# by Jeffrey

To Heidi, I am not a Sharepoint guy, so here is just my guess... Sharepoint forces every request be processed by ASP.NET framework so it can add some logic and play some tricks, just like store the file content in database and retrieve them like they are in the physical folder(some kind of UrlRewrite...), maybe it's a good way to handle versionging.

# by 宗

請問關閉是把 Wildcard Application Maps裡的.net移除掉就好了嗎 我現在碰到上傳多張圖片常常傳不上去的問題 而且圖片檔案也很小 不知道是不是這個問題所造成的 謝謝^^

# by Jeffrey

to 宗, 關閉方法是將那條設定移除沒錯，但它影響的是jpg, gif等非ASPX程式是否要經過ASP.NET framework處理? 你所說的圖檔上傳應該也還是POST給ASPX程式接收，看起來不像是這個問題造成的。

# by Bel

I have had lots of problems with sharepoint services. There are known bug with it that don't have solutions (yet).

# by Steven

請教Jeffery: 我們公司的wss再移除掉Wildcard Application Maps後 發現下面兩點問題： 1.我們自製的Masterpage圖片都不見了（這個好解決，應該是路徑的問題） 2.IIS中不存在的網頁（default.aspx) 他不會自動加上 會變成找不到網頁的錯誤 請問您有碰到過嗎？

# by Jeffrey

to Steven, 聽你的描述好像連基本的WSS功能受損了，不知是否因不小心拿掉什麼不該刪的設定所致。WSS我只懂皮毛，經驗也有限，推薦你到TechNet論壇提問看看: http://social.technet.microsoft.com/Forums/zh-TW/sharepointserviceszhcht/threads/

# by Chris

to Jeffery 大大 , 當出現此exction, 移除ASP.NET ISAPI篩選器後,我也出現如同Steven的問題, 參考了microsoft網站上的SharePoint 基礎結構文件: http://www.microsoft.com/taiwan/sharepoint/content/resources/articles/003.aspx , wss上有開發.NET應用程式, 此ASP.NET ISAPI篩選器看來有其存在的必要,而日前wss v3 sp2已release,我upgrade後, ASP.NET ISAPI篩選器設定還在,但Out of Memory exception不會再發生, 提供給您參考,但此sp2之前會有upgrade後,將wss改為試用版的bug, 只要上hotfix kb971620即可解決~

# by 小千

Event time: 8/23/2007 12:53:03 PM Event time (UTC): 8/23/2007 4:53:03 AM 想要請教這兩個時間分別的意思是什麼呢?

# by Jeffrey

to 小千，Event time是事件發生時間(中午12:53)，而Event time(UTC)是換算成格林威治時間，台灣為UTC+8，快了8小時，所以相當於格林威治時間早上4:53。

Post a comment