2011-07-04 21 views
6

最近我們的客戶開始抱怨我們的某臺服務器性能不佳。 這包含多個大型CMS實現和使用Sitefinity的很多小型網站。 我們的主機團隊正在嘗試找到我們環境中的瓶頸,因爲加載時間存在一些主要問題。我已經被賦予了指定一個需要注意的大列表,分爲不同的部分(IIS,ASP.NET,Web特定)。 我認爲根據Sitecore文檔e.d.可以找出我們可以在一臺服務器上運行多少個Sitecore CMS實例。我們希望能夠監控並找出現在我們的瓶頸所在。我們的一些網站加載非常緩慢,其他網站加載非常快。我們在該服務器上運行的大多數Sitecore實現都具有較差的後端性能,編譯後的加載時間可怕。 我們的Sitecore解決方案在運行Microsoft SQL Server 2008 for db的Win 2008 64服務器上運行。 我明白,指定有關我們設置的更詳細信息可能會很方便,但我希望能夠獲得有關如何監視和查找e.d.的瓶頸的一些有用的基本信息。ASP.NET /數據庫性能清單

什麼工具/提示/技巧&你有什麼竅門?

+0

大多數用戶使用Sitecore或Sitefinity提供的大約15%,這就是爲什麼您不應該託管這些大型Web應用程序。這就是爲什麼他們慢慢編譯。 您應該檢查編譯時間和對同一應用程序提出的請求之間是否存在關係。 – eugeneK

+0

通過使用Sitecore提供的約15%,你的意思是什麼? 編譯時間和對同一應用程序的請求之間沒有關係。我想我知道你要去哪裏,但我們使用Keep alive services來停止Web應用程序進入睡眠狀態。該應用程序不會在常規基礎上編譯。 – Younes

回答

5
  • 不使用太多不同的asp.net池,被稱爲plesk中的專用池。將更多網站放在同一個池中。
  • 更多的內存,或停止不使用的程序/服務在服務器
  • 檢查,如果你對應用程序池內存限制,使該池會繼續自動重新啓動。
  • 在數據庫上,將恢復模式設置爲簡單。
  • 收縮數據庫文件,並在所有這一切重新索引數據庫,從程序
  • 碎片整理您的磁盤

檢查與process explorer內存。
要檢查服務器的啓動使用autoruns,但要小心不要停止任何關鍵服務,並且計算機永遠不會再啓動。不要停止自動運行的服務,請使用服務管理器將類型更改爲手動。還有許多sql服務服務,如果你從未使用它們,它們不需要運行。

其他一些技巧

  • 移動的臨時文件/也許asp.net build目錄到不同的磁盤
  • 刪除臨時目錄(CD%TEMP%)

所有文件使用進程exporer確保空閒的物理內存不爲零。如果它接近零,那麼你的服務器需要內存,或者需要停止不使用程序運行。

要將多個網站放置在同一個池下,您需要更改新共享池下的網站的權限。這並不困難,只需要花點時間,組織起來就可以知道什麼網站在哪個網站下運行。現在假設您有10個站點,最好使用2個不同的池,並根據每個站點的負載將這些站點分佈到這個池中。

1

不能說Sitefinity,但會提供一些Sitecore提示。

  • 儘可能使用Sitecores緩存,在XSLTs上(因爲它們往往比佈局&子佈局更簡單,因此Sitecore緩存不會打破它們,因爲Sitecore緩存對asp.net回發沒有影響),只有在重新訪問子緩存等時纔會有幫助。使用/sitecore/admin/stats.aspx?site=website檢查未緩存
  • 使用Sitecores探查的東西,在事件探查器打開了一個項目,看看哪些sublayouts等正在服用時間
  • 僅使用XSLT文件進行最簡單的內容,如果它變得更復雜,我會去sublayouts(asp.net控件),這是有點偏見,因爲我不喜歡XSLT,但經驗表明.ascx的更快
  • 使用IIS對靜態文件的內容過期(prob all/sitecore,如果你有一些圖像,這個是IIS 6的:msdn link
  • 用Sitecore檢查數據庫訪問時間Databasetest.aspx(o NE對Sitecore的6比簡單的一,關於Sitecore的5 & 6作品)Sitecore SDN link

好了很多,這就是我可以從我的頭頂想到的。

2

Sitecore性能調整沒有直接的答案。但這裏有一些重要提示:

1)CACHING

緩存就是一切。對於任何應用程序,默認的Sitecore緩存參數很少正確。如果你有大量的內存,則應該增加高速緩存大小:

http://learnsitecore.cmsuniverse.net/en/Developers/Articles/2009/07/CachingOverview.aspx

http://sitecorebasics.wordpress.com/2011/03/05/sitecore-caching/

http://blog.wojciech.org/?p=9

很不幸,這是後話了開發者需要知道的部署安裝時,不事系統管理員應該關心...

2)數據庫

數據庫是檢查的最後一個瓶頸。我很少碰到數據庫。然而,DB的性能可以用適當的設置來增加:

數據庫屬性可以改善性能:

http://www.theclientview.net/?p=162

這篇文章在索引碎片是非常有幫助的:

http://www.theclientview.net/?p=40

1

Sitecore有一個主要缺陷,其用途主鍵的GUID(以及其他選擇不當的數據類型),這將從第一次插入的表中分割出來,並且如果您有大量使用的Sitecore數據庫,則碎片在一小時內可能會超過90%。這些並不是一個設計良好的數據庫,並且建議您在解決此問題之前查看其他產品,這會導致我們出現重大性能問題(時間和金錢)。 我們暫時還不能再添加內存無法更頻繁地重建索引

0

另外,設置您的IIS以在特定時間每天僅回收app_pool一次。我通常把我的礦時間定爲凌晨3點。通過這種方式,應用程序永遠不會進入睡眠,回收或等最佳狀態以減少啓動時間。

此外,將IIS配置爲'始終運行'而不是'在starup上'。這樣,當應用程序重新啓動時,它會立即重新編譯,隨時可以咆哮。

Sitefinity真的是一個夢幻般的軟件(希望我的技巧上面得到大拇指,而不是我的產品認可)。 haha