Another nice thing about the Profile is that it follows the Provider model and ships with a pre-working SQL Server implementation.
In a recent ASP.NET application, we made some extensive use of the Profile in our searchscreens, however since we were working on an Oracle database, we had to create our own custom Provider. This is however absolutely no problem since DotNet makes it really easy to do so, and to plug your resulting custom provider into your application without any hassle.
However, we did notice a performance degradation upon use of the Profile, and we occasionally even got Oracle errors, when the application received a lot of strain. When we finally found some time to investigate the issue, we discovered that the SetPropertyValue method of the Provider was being called on each and every visit to the page and this for every available property in our Profile, resulting in at least 15-20 extra database calls per page access. Needless to say, this did not help performance one bit.
After digging around some more, it turned out that the Profile mechanism has in fact an auto-load and auto-save mechanism built-in. In other words:
- at the start of the page cycle, all properties get read from the data store
- at the end of the page cycle, all properties get persisted to the data store
Fortunately, there was also an option to turn this automatic save off, this by a simple modification of the web.config.
< profile automaticSaveEnabled="false">Not quite as well-documented as I'd hoped though...
*** Note that the Profile can however be enabled for anonymous usage, in this case you will need cookies again for this to work. :)
No comments:
Post a Comment