我們的團隊使用Sharepoint和一些自定義Web部件構建了一個站點。我們注意到,該網站在上午第一次訪問該網站時需要一段時間才能加載。隨後的訪問沒問題。我們懷疑Sharepoint重新列出了它的名單等。Sharepoint站點需要一段時間才能在早上加載第一件事
有沒有其他人看過Sharepoint的這個問題?有沒有人有建議的修復?
我們的團隊使用Sharepoint和一些自定義Web部件構建了一個站點。我們注意到,該網站在上午第一次訪問該網站時需要一段時間才能加載。隨後的訪問沒問題。我們懷疑Sharepoint重新列出了它的名單等。Sharepoint站點需要一段時間才能在早上加載第一件事
有沒有其他人看過Sharepoint的這個問題?有沒有人有建議的修復?
默認情況下,IIS應用程序將在夜間回收其工作進程。您可以在IIS管理器中關閉此功能,但更好的選擇可能是將熱身腳本添加到定時作業中。您可以在SharePoint中執行此操作,但更簡單的做法可能是在Windows中添加計劃任務以在回收完成後啓動熱身腳本。
一種「熱身的SharePoint腳本」谷歌將產生幾個結果,including this,這實際上也說明了:-)同樣的情況
不,我猜想應用程序中的已編譯組件已經從內存中卸載並且必須重新加載到緩存中。這也發生在我的ASP.NET Web應用程序中。我特別注意到QA站點幾乎沒有經常碰到,因此在訪問它們時幾乎總是從緩存中刷新。
您可以考慮增加您的站點的app pool在回收空閒工作進程之前等待的時間。
同意tvanfosson,它聽起來很像你用aspnet應用程序獲得的啓動延遲。
一個快速而骯髒的修復可能是設置一個計劃任務,將WebClient指向該站點,並在人們開始使用它之前每天早上將其啓動。
我的猜測是,應用程序池的工作進程設定在一定的時間來回收每天晚上在IIS中,這導致在早上第一件事延遲。右鍵單擊IIS - >屬性 - >中的應用程序池,然後查看它在「以下時間回收工作進程:」的位置以查看自己。
您可以禁用此選項來修復您的問題,但我不建議這樣做,因爲每天晚上有工作進程的回收站將回收任何可能泄漏的內存。內存泄漏在SharePoint開發過程中尤其可能,因爲您可能知道SharePoint對象模型中的許多對象在無人值守的內存中執行大部分工作。如果這些對象沒有正確處理大量的內存,可能會佔用.NET內存垃圾收集器上的內存壓力,並延緩垃圾收集。
Best Practices: Using Disposable Windows SharePoint Services Objects
我同意建立一個計劃任務加載該網站在早上來解決延遲問題的seanb的建議。只要確保在工作流程明顯回收之後安排一段時間。
當然,比約恩強調了「問題」的主要原因。應用程序池在夜間得到回收。
但是,這應該需要30秒。
如果需要2或3分鐘的時間,請考慮閱讀this。如果你的服務器無法訪問互聯網,它主要解釋它爲什麼如此緩慢。只要嘗試從microsoft.com下載證書撤銷列表,看看它是否有所作爲。
如果您運行的是Windows Server 2008 R2,則現在有一個IIS 7.5
available for free的應用程序預熱擴展。在撰寫本文時,它處於測試階段。
這會「熱身」從IIS直接配置的應用程序池,也可以使用自定義初始化邏輯進行擴展。
應用程序預熱擴展已不再可用,並將「重新調整爲下一個版本的IIS」according to Microsoft。
這聽起來很理想,但不幸的是它似乎被拉了。不過謝謝。 – 2011-11-15 08:30:27