優(yōu)化ASP.NET 2.0 Profile Provider
優(yōu)化ASP.NET 2.0 Profile Provider
你可知道優(yōu)化ASP.NET 2.0 Profile Provider中有兩個(gè)能進(jìn)行優(yōu)化的重要存儲(chǔ)過程嗎？如果在沒有進(jìn)行任何必要優(yōu)化的情況下使用過它們，你的服務(wù)器將會(huì)因?yàn)闃I(yè)務(wù)量的增長(zhǎng)而變得異常繁忙。這里有一個(gè)故事：
在2006年3月份的MIX大會(huì)上展示了Pageflakes。當(dāng)時(shí)我們是我們最富有魅力的時(shí)候。我們是作為支持Showcase of Atlas Web site的第一家公司。每天訪問站點(diǎn)的用戶數(shù)量接連攀升。有一天我們注意到，數(shù)據(jù)庫服務(wù)器不再工作了。然后我們重新啟動(dòng)了服務(wù)器，工作恢復(fù)了正常，可過了一小時(shí)后，服務(wù)器再次死掉了。在我們對(duì)服務(wù)器主體部分進(jìn)行了檢查分析之后，我們發(fā)現(xiàn)CPU占用率高達(dá)100％并且IO使用率更高。
硬盤驅(qū)動(dòng)器發(fā)熱，并進(jìn)行了自動(dòng)關(guān)閉以保護(hù)其不受損壞。這對(duì)我們來說感到十分驚奇，因?yàn)槲覀冊(cè)詾槲覀円恢倍己苈斆?，并且針?duì)每個(gè)單獨(dú)的Web服務(wù)功能都使用了 profile。因此，我們對(duì)上百兆的日志進(jìn)行了分析希望能找到那個(gè)Web服務(wù)耗費(fèi)了這么多時(shí)間。我們對(duì)其中一個(gè)產(chǎn)生了懷凝。它是加載用戶頁面配置的第一個(gè)功能。我們將這個(gè)功能分解成了很多小的部分以便我們能快速找到那一部分花費(fèi)了大部分時(shí)間。
- private GetPageflake(string source, string pageID, string userUniqueName)
- {
- if( Profile.IsAnonymous )
- {
- using (new TimedLog(Profile.UserName,"GetPageflake"))
- {
正如你所看到的情形，整個(gè)方法主體就是用于計(jì)時(shí)。如果你想了解這種計(jì)時(shí)是如何工作的，我會(huì)在一篇新的文章中進(jìn)行解釋。我們也對(duì)其中一小部分我們懷凝最耗費(fèi)資源的功能進(jìn)行了計(jì)時(shí)。但是在我們的代碼中需要花費(fèi)大量時(shí)間處理的部分很多。我們的代碼一直都是經(jīng)過優(yōu)化的（畢竟，你知道是誰在查看它，就是我）。
同時(shí)，用戶開始了大叫，管理也開始混亂，支持部門的員工也開始抱怨這么多電話。開發(fā)人員搞得焦頭亂額此時(shí)也變得胡言亂語。這并不是什么特殊情況，僅僅就是一個(gè)每個(gè)月會(huì)遇到2次的一個(gè)典型解決方案。
現(xiàn)在你一定在大聲叫喊了，“你可以使用SQL Profiler啊，你這個(gè)傻瓜！”。問題是我們使用的是SQL Server工作組版本。不支持SQL Profiler這個(gè)功能。因此我們不得不采用我們的方法來解決這個(gè)問題，無論怎樣也得使其在服務(wù)器上正常運(yùn)行。不要問這個(gè)到底如何實(shí)現(xiàn)。在運(yùn)行了SQL Profiler以后，孩子，真讓我們吃驚！原來才是這個(gè)巨大的存儲(chǔ)過程dbo.aspnet_Profile_GetProfiles給我們帶來了痛苦！
我們習(xí)慣大量使用（并且一直使用）Profile provider這個(gè)工具。
- 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。
【編輯推薦】
