title: Creating a sub site in SharePoint takes a very long time
body: <p>I am working in a MOSS 2007 project and have customized many parts of it. There is a problem in the production server where it takes a very long time (more than 15 minutes, sometimes fails due to timeouts) to create a sub site (even with the built-in site templates). While in the development server, it only takes 1 to 2 minutes.</p>
  
  <p>Both servers are having same configuration with 8 cores CPU and 8 GIGs RAM. Both are using separate database servers with the same configuration. The content db size is around 100 GB. More than a hundred subsites are there.</p>
  
  <p>What could be the reason why in the other server it will take so much time? Is there any configuration or something else I need to take care?</p>
  
  <h2>Update:</h2>
  
  <p>So today I had the chance to check the environment with my clients. But site creation was so fast though they said they didn't change any configuration in the server.</p>
  
  <p>I also used that chance to examine the database. The disk fragmentation was quite high at 49% so I suggested them to run defrag. And I also asked the database file growth to be increased to 100MB, up from the default 1MB.</p>
  
  <p>So my suspicion is that some processes were running heavily on the server previously, that's why it took that much of time.</p>
  
  <h2>Update 2:</h2>
  
  <p>Yesterday my client reported that the site creation was slow again so I went to check it. When I checked the db, I found that instead of the reported <strong>100GB</strong>, the content db size is only around <strong>30GB</strong>. So it's still far below the recommended size.</p>
  
  <p>One thing that got my attention is, the site collection recycle bin was holding almost <strong>5 millions items</strong>. And whenever I tried to browse the site collection recycle bin, it would take a lot of time to open and the whole site collection is inaccessible.</p>
  
  <p>Since the web application setting is set to the default (30 days before cleaning up, and 50% size for the second stage recycle bin), is this normal or is this a potential problem also?</p>
  
  <p>Actually, there was also another web application using the same database server with 100GB content db and it's always fast. But the one with 30GB is slow. Both are having the same setup, only different data.</p>
  
  <p>What should I check next?</p>
  
  <hr>
  
  <p>So today I had the chance to check the environment with my clients. But site creation was so fast though they said they didn't change any configuration in the server.</p>
  
  <p>I also used that chance to examine the database. The disk fragmentation was quite high at 49% so I suggested them to run defrag. And I also asked the database file growth to be increased to 100MB, up from the default 1MB.</p>
  
  <p>So my suspicion is that some processes were running heavily on the server previously, that's why it took that much of time.</p>
  
  <p>Thanks for the inputs everyone, I really appreciate.</p>
  
  <hr>
  
  <p>Yesterday my client reported that the site creation was slow again so I went to check it. When I checked the db, I found that instead of the reported <strong>100GB</strong>, the content db size is only around <strong>30GB</strong>. So it's still far below the recommended size.</p>
  
  <p>One thing that got my attention is, the site collection recycle bin was holding almost <strong>5 millions items</strong>. And whenever I tried to browse the site collection recycle bin, it would take a lot of time to open and the whole site collection is inaccessible.</p>
  
  <p>Since the web application setting is set to the default (30 days before cleaning up, and 50% size for the second stage recycle bin), is this normal or is this a potential problem also?</p>
  
  <p>Actually, there was also another web application using the same database server with 100GB content db and it's always fast. But the one with 30GB is slow. Both are having the same setup, only different data.</p>
  
  <p>Any idea what should I check next? Thanks a lot.</p>