Sitefinity is hammering our database

I'm doing some eCommerce module development on Sitefinity and I've noticed that start-up time when running from Visual Studio is extremely slow. So I fired up SQL Profiler and discovered that Sitefinity is beating our database to death. On startup, it prepares and issues over 50,000 queries! Even when apparently idle it's issuing ~1,000 per second! There are so many it's hard to pin down the main culprits, but two frequent offenders are of the form:
exec sp_execute 1,@p0='9AEB5845-1B98-4669-8F18-3E51940B9EE0'
exec sp_execute 2,@p0='/Blogs',@p1='7D68C543-AE50-46F8-B70E-51038DE1CB11'

The GUIDs are different in every statement -- but I didn't check them all :-). I only caught the sp_prepexec statement for #1:

declare @p1 int
set @p1=23
exec sp_prepexec @p1 output,N'@p0 uniqueidentifier',N'SELECT
[description_] AS COL1, [title_] AS COL2, [url_name_] AS COL3, [allow_comments]
AS COL4, [allow_track_backs] AS COL5, [app_name] AS COL6, [approve_comments] AS
COL7, [content_state] AS COL8, [date_created] AS COL9, [default_page_id] AS
COL10, [draft_culture] AS COL11, [email_author] AS COL12, [expiration_date] AS
COL13, [last_modified] AS COL14, [last_modified_by] AS COL15, [original_content_id]
AS COL16, [ownr] AS COL17, [post_rights] AS COL18, [publication_date] AS COL19,
[source_key] AS COL20, [status] AS COL21, [vrsion] AS COL22, [views_count] AS
COL23, [visible] AS COL24, [votes_count] AS COL25, [votes_sum] AS COL26,
[author_name_] AS COL27, [content_] AS COL28, [comment_status] AS COL29,
[commented_item_i_d] AS COL30, [commented_item_type] AS COL31, [email] AS
COL32, [ip_address] AS COL33, [provider_name] AS COL34, [website] AS COL35,
[voa_version] AS COL36 FROM [sf_commnt] WHERE [content_id] =
@p0                                      
',@p0='F659041A-4B5C-4786-B217-196FB5DC6868'
select @p1

Any ideas? The slow response is making development miserable. I haven't profiled our production system but I have heard no complaints.

Does anyone have any advice for me on this? Are others experiencing the same problems? Developing custom pages is a nightmare when it takes 3-5 minutes for the site to come up. Another developer got significant improvement using a local database but that doesn't address the root cause.

1) Everytime you build, asp.net will need to go through and compile every template it needs on the page, open your task manager and look for csc.exe.  When you stop seeing that appear, the site should come back.

2) Set your app pool to Enable 32-bit, the site will come back faster, only needs to get to 200(ish) megs of ram instead of 500-800 Megs.

...aside from that until they let us precompile it's always gonna take a few minutes, the more custom controls you have the slower she's gonna go.

If you think it IS related to the DB though, put in a support ticket and let them see the project for themselves to validate, maybe you have something here?

Hello Steve,

Thank you for the answer.

Jamie, please try the suggested scenarios and if you are still experiencing this problem, do not hesitate to contact us.

Regards,
Nikolay Dimitrov
Telerik

Thanks for the replies. To be clear, the main problem I am having is with SF in a development environment. I'm developing MVC modules in Visual Studio and using IIS Express to debug. We have several other large VS C# solutions, both Web Forms and MVC, and I have never experienced performance as slow as this.

We're running SF with the ECommerce module. I profiled a typical startup from Visual Studio and found:
- csc.exe runs on 3-4 threads for about the first, minute, then 1 thread pops up occasionally
- total time for the first page to fully load was 3:20 (min:sec)
- SQL Profiler recorded 1212 database operations
- Navigating in the application is slow but acceptable for development
- The admin screens are very slow, 1-2 or more minutes per page

Is this normal performance? It really makes development miserable and time-consuming.

Yep, thats normal...I mean depending on the machine

I've never profiled sql, so like I said, perhaps put in a ticket and have them check that.  Maybe you've identified someplace that can be improved upon.

Once you're done all the csc compilation, and the service calls in the backend have fired at least once everything should be nice and peppy...but yeah...this is what we deal with

Thanks for confirming the bad news Steve. I don't know about you but it's unacceptable to me. It's killing productivity and it's a big part of the reason I'm spending my entire weekend working. Unfortunately my module relies on calls to SF manager classes, otherwise I'd create a separate development project for it.

Running the database locally significantly improves performance to pokey but it doesn't allow for collaboration.

...and the more custom controls you have the more csc.exe hits you get and the slower you go

Please though, put in a ticket with the SQL results...there might be something there