asp.net profile questions

  • Thread starter Thread starter tiago.private
  • Start date Start date
T

tiago.private

Hi Everybody,

I have a few questions related to asp.net profile (behaviour):

1) as an example during the asp.net cycle, accessing (READ) the
profile data, in 3 different places: httpmodule, page, control/
usercontrol, the profile data is "cached" or each item is going to the
database ?

1.1) If is cached where is cached (i.e Context.Items, Session ) ?
1.2) caching is per property or as whole (user profile)

2) imagining that are several requests with the same user session, is
the profile still going to the database, there is no (internal
caching) like a singleton or even using user session ?


The questions behind are the performance/cost of using asp.net
Profile with several properties (most of them readonly) or at least
changed once in a while.

If the asp.net Profile "logic" is to fetch each property/per request
from the database, that will hurt my application performance and
question is the asp.net profile useful in critical applications or is
a nice toy ?

Are other alternatives to improve ? like for instance creating a
custom asp.net Profile and caching in a Session or in a Singleton ?

did some crossed these issues ?


Feedback will be appreciated!

Regards,
Tiago
 
Hi Everybody,

I have a few questions related to asp.net profile (behaviour):

1) as an example during the asp.net cycle, accessing (READ) the
profile data, in 3 different places: httpmodule, page, control/
usercontrol, the profile data is "cached" or each item is going to the
database ?
Click to expand...

If you use the standard implementation, every time you ask for profile data,
there is a hit on the database. You can move this information to session or
cache, if you desire, but if you have a caching need, you might also look at
a custom provider.
1.1) If is cached where is cached (i.e Context.Items, Session ) ?
1.2) caching is per property or as whole (user profile)

2) imagining that are several requests with the same user session, is
the profile still going to the database, there is no (internal
caching) like a singleton or even using user session ?
Click to expand...

By default, every time you instantiate the profile object, you take a trip
to fill it. This means a database hit.
The questions behind are the performance/cost of using asp.net
Profile with several properties (most of them readonly) or at least
changed once in a while.
Click to expand...

There is only one hit for each use of the profile object, no matter how many
properties there are. But, if you have a page loaded with controls that each
get the profile object, you end up with lots of hits. In this type of
instance, I would add a constructor to load profile or add a profile
property to the control and feed it (inversion of control of sorts). Then
the page is responsible for getting the data once and doling it out.
If the asp.net Profile "logic" is to fetch each property/per request
from the database, that will hurt my application performance and
question is the asp.net profile useful in critical applications or is
a nice toy ?
Click to expand...

Overall, I detest the default profile provider. This does not make it a toy,
but I have personally found it is problematic, at best.
Are other alternatives to improve ? like for instance creating a
custom asp.net Profile and caching in a Session or in a Singleton ?
Click to expand...

Custom provider with cache might be a better option in your case. I would
not completely reinvent the wheel.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Blog:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************
 
the Profile is a class instance, that is stored in the HttpContext. when
it is created all the properties are read into a private collection. in
the case of the sqlserver provider the propeties are all stored in one
column in one row. at the end of the request the properties are written
back to the store.

you need no additional caching to use the profile. just remember all
profile properties are serialized in and out for each request to
sqlserver, so don't make them too large.


-- bruce (sqlwork.com)
 
Back
Top