優(yōu)化ASP.NET 2.0 Profile Provider
優(yōu)化ASP.NET 2.0 Profile Provider
你可知道優(yōu)化ASP.NET 2.0 Profile Provider中有兩個能進行優(yōu)化的重要存儲過程嗎?如果在沒有進行任何必要優(yōu)化的情況下使用過它們,你的服務(wù)器將會因為業(yè)務(wù)量的增長而變得異常繁忙。這里有一個故事:
在2006年3月份的MIX大會上展示了Pageflakes。當(dāng)時我們是我們最富有魅力的時候。我們是作為支持Showcase of Atlas Web site的第一家公司。每天訪問站點的用戶數(shù)量接連攀升。有一天我們注意到,數(shù)據(jù)庫服務(wù)器不再工作了。然后我們重新啟動了服務(wù)器,工作恢復(fù)了正常,可過了一小時后,服務(wù)器再次死掉了。在我們對服務(wù)器主體部分進行了檢查分析之后,我們發(fā)現(xiàn)CPU占用率高達100%并且IO使用率更高。
硬盤驅(qū)動器發(fā)熱,并進行了自動關(guān)閉以保護其不受損壞。這對我們來說感到十分驚奇,因為我們原以為我們一直都很聰明,并且針對每個單獨的Web服務(wù)功能都使用了 profile。因此,我們對上百兆的日志進行了分析希望能找到那個Web服務(wù)耗費了這么多時間。我們對其中一個產(chǎn)生了懷凝。它是加載用戶頁面配置的第一個功能。我們將這個功能分解成了很多小的部分以便我們能快速找到那一部分花費了大部分時間。
- private GetPageflake(string source, string pageID, string userUniqueName)
- {
- if( Profile.IsAnonymous )
- {
- using (new TimedLog(Profile.UserName,"GetPageflake"))
- {
正如你所看到的情形,整個方法主體就是用于計時。如果你想了解這種計時是如何工作的,我會在一篇新的文章中進行解釋。我們也對其中一小部分我們懷凝最耗費資源的功能進行了計時。但是在我們的代碼中需要花費大量時間處理的部分很多。我們的代碼一直都是經(jīng)過優(yōu)化的(畢竟,你知道是誰在查看它,就是我)。
同時,用戶開始了大叫,管理也開始混亂,支持部門的員工也開始抱怨這么多電話。開發(fā)人員搞得焦頭亂額此時也變得胡言亂語。這并不是什么特殊情況,僅僅就是一個每個月會遇到2次的一個典型解決方案。
現(xiàn)在你一定在大聲叫喊了,“你可以使用SQL Profiler啊,你這個傻瓜!”。問題是我們使用的是SQL Server工作組版本。不支持SQL Profiler這個功能。因此我們不得不采用我們的方法來解決這個問題,無論怎樣也得使其在服務(wù)器上正常運行。不要問這個到底如何實現(xiàn)。在運行了SQL Profiler以后,孩子,真讓我們吃驚!原來才是這個巨大的存儲過程dbo.aspnet_Profile_GetProfiles給我們帶來了痛苦!
我們習(xí)慣大量使用(并且一直使用)Profile provider這個工具。
- CREATE PROCEDURE [dbo].[aspnet_Profile_GetProfiles]
- @ApplicationName nvarchar(256),
- @ProfileAuthOptions int,
- @PageIndexint,
- @PageSize int,
- @UserNameToMatch nvarchar(256) = NULL,
- @InactiveSinceDate datetime = NULL
- AS
- BEGIN
- DECLARE @ApplicationId uniqueidentifier
- SELECT @ApplicationId = NULL
- SELECT @ApplicationIdApplicationId = ApplicationId
- FROM aspnet_Applications
- WHERE LOWER(@ApplicationName)
- = LoweredApplicationName
- IF (@ApplicationId IS NULL)
- RETURN
- -- Set the page bounds
- DECLARE @PageLowerBound int
- DECLARE @PageUpperBound int
- DECLARE @TotalRecords int
- SET @PageLowerBound = @PageSize * @PageIndex
- SET @PageUpperBound = @PageSize - 1 + @PageLowerBound
- -- Create a temp table TO store the select results
- CREATE TABLE #PageIndexForUsers
- (
- IndexId int IDENTITY (0, 1) NOT NULL,
- UserId uniqueidentifier
- )
- -- Insert into our temp table
- INSERT INTO #PageIndexForUsers (UserId)
- SELECT u.UserId
- FROMdbo.aspnet_Users
- u, dbo.aspnet_Profile p
- WHERE ApplicationId = @ApplicationId
- AND u.UserId = p.UserId
- AND (@InactiveSinceDate
- IS NULL OR LastActivityDate
- <= @InactiveSinceDate)
- AND (
- (@ProfileAuthOptions = 2)
- OR (@ProfileAuthOptions = 0
- AND IsAnonymous = 1)
- OR (@ProfileAuthOptions = 1
- AND IsAnonymous = 0)
- )
- AND (@UserNameToMatch
- IS NULL OR LoweredUserName
- LIKE LOWER(@UserNameToMatch))
- ORDER BY UserName
- SELECT u.UserName, u.IsAnonymous, u.LastActivityDate,
- p.LastUpdatedDate, DATALENGTH(p.PropertyNames)
- + DATALENGTH(p.PropertyValuesString)
- + DATALENGTH(p.PropertyValuesBinary)
- FROMdbo.aspnet_Users
- u, dbo.aspnet_Profile p, #PageIndexForUsers i
- WHERE
- u.UserId = p.UserId
- AND p.UserId = i.UserId
- AND i.IndexId >= @PageLowerBound
- AND i.IndexId <= @PageUpperBound
- DROP TABLE #PageIndexForUsers
- END
- END
以上是優(yōu)化ASP.NET 2.0 Profile Provider。
【編輯推薦】