asp.net profile questions

[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

 

[Gregory Beamer]

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 ?

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 ?

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.

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 ?

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 ?

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

 

[bruce barker]

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)