theme selector from profile

Maxxim · July 1st, 2007, 06:23 PM

Hello,

tell me one thing:

How it is possible to know profTheme.Preferences.Theme of user that is seeing the page?
It has of being made a linking to the database, right?

With this code in basePage:

Code:

Protected Overrides Sub OnPreInit(ByVal e As System.EventArgs)
            Dim id As String = Globals.ThemesSelectorID

            If id.Length > 0 Then
                Dim profTheme As ProfileCommon = HttpContext.Current.Profile
                If Me.Request.Form("__EVENTTARGET") = id AndAlso _
                        Not String.IsNullOrEmpty(Me.Request.Form(id)) Then
                    Me.Theme = Me.Request.Form(id)
                    profTheme.Preferences.Theme = Me.Theme
                Else
                    If Not String.IsNullOrEmpty(profTheme.Preferences.Theme) Then
                        Me.Theme = profTheme.Preferences.Theme
                    End If
                End If
            End If

            MyBase.OnPreInit(e)
        End Sub

The system make one connection to database(adding to all the others throughout the page) everytime the page is postback...

Are you sure this is a good strategy ?

Thanks

englere · July 1st, 2007, 10:01 PM

I don't know if the ASP.NET 2.0 Profile provider for SQL Server includes caching or not. Maybe it does not, so every page hit goes all the way to SQL Server. Each page hit probably does anyway for other things. This is probably not a serious slowdown but you could do some benchmarking to see if it has an effect.

You could always cache it yourself by simply remembering the value you get the first time, and then sticking it in session state. Or you could stick it in the cache along with user identification (I'd use session). But the profile concept is very easy to use and I'd try to avoid doing my own cache unless a benchmark test should that it is a bottleneck. Out of process session state would probably be as slow as hitting SQL Server, so any kind of cache here probably only makes sense with in process session state, or the data cache with the extra code to isolate it by user.

You have to remember that SQL Server caches query plans and this is an indexed hit into a table. It's probably very fast. The frequently requested DB table pages will be kept in memory on the SQL Server box so that helps, also. Just the pain of leaving your IIS process and going over to a SQL process is the biggest hit. Perhaps only a few milliseconds...

Eric

Maxxim · July 1st, 2007, 10:35 PM

Thanks Englere,

Don't be mad about what I go to say, but I have found all the pages based on âtheBeerHouseâ very slowâ¦ and I have to understand Why!!

Maybe it's all that little things!

This site it's slower than thePhille... Even on my localmachine (TheBeerHouse sourceCode).

With "thePhile" i have a forum with thousands of posts but every page render fast!
In theBeerHouse i have to wait for a (2...3seconds) "blank screen" every time navigate from page to other page...
Everytime that I go to your page i have to wait (4...5 seconds)

I have a 16Mb InternetConnection

Maybe it is bad luck with hostingCompanies...

Max