none
Collocating Sharepoint with an ASP website

    Pertanyaan

  • Here's our scenario: We're a medium size company which benefits from a Sharepoint site, which we installed on a box along with a separate website which also runs of ASP and SQL server - same instance, separate databases.  Now, they seem to play together just fine, they sit on separate IPs, have separate A records, etc.  But we're trying to troubleshoot why our ASP site seems to be lagging.  Is it the Sharepoint site monopolizing the SQL server or is it the ASP site?

    We ran SQL Profiler, and tried a trace, and Sharepoint seems to be querying SQL server every second.  However, running the graphical performance analyzer shows it humming at 10% of processor power, with occasional peaks at 30-40%.  So I'm trying to figure out a couple things.  A) is there a way to temporarily (and easily) disable Sharepoint so we can see if this speeds up our ASP site? B) If it turns out that Sharepoint is causing these lags, is there a way to turn off the constant queries?  We really don't need the search/index function.  But I don't see a way to toggle that.

    I'm really hoping this doesn't require migrating Sharepoint off this server, and especially onto a separate SQL server instance.  I'm assuming the whole point of SQL server is many processes can be efficiently using it at once, allowing for centralization.


    ----------- Ron E Biggs Network Administrator Entertainment Studios

    29 Februari 2012 1:06

Jawaban

  • Hi Ron,

    SharePoint does indeed add some load to the SQL database server. When a request is made by a user for SharePoint information, uncustomized information (such as the page structure) is rendered from the file system of the Web server itself (which, in your case, adds disk I/O utilization into the mix). The rest of the information is retrieved from SQL tables within Content Databases.

    There is a good chance that your ASP is not hitting the SQL box as hard as SharePoint does. You did not specify your configuration, but odds are, with all three of these running on the same box, you may be overcommitted from a RAM perspective. If your RAM is indeed overcommitted, you will be able to see the disk queue length go up during these times, indicating that you are hitting the disk I/O pretty hard (and resulting in a much slower system - RAM is always faster than disk).

    Additionally, you may want to look at your SQL configuration to see if you have tuned it a bit for better performance by offloading disk I/O onto separate disk spindles (particularly for more intense loads such as TempDB). Search (SharePoint Standard and Enterprise) can also be offloaded onto its own spindles/volume to increase performance.

    One last thing - as you mentioned, search can and does consume reasonably high amounts of I/O. You were not specific as to which version of SharePoint you are using. If it is SharePoint Foundation 4.0, then you are running frequent, smaller searches which can be tuned to have longer time intervals between searches. If you are using SharePoint Server 2010 Standard or Enterprise, then you can configure the box to perform its indexing in the evening/overnight - the searches will then work against a catalog which is stored on the local file system.

    Hope this helps


    Troy Lanphier -- MCT/MCSE/MCITP SharePoint Server 2010 Administration -- Author: Microsoft SharePoint Foundation 2010 Inside Out -- http://blog.sharepointcookbook.com

    29 Februari 2012 3:10

Semua Balasan

  • Hi Ron,

    SharePoint does indeed add some load to the SQL database server. When a request is made by a user for SharePoint information, uncustomized information (such as the page structure) is rendered from the file system of the Web server itself (which, in your case, adds disk I/O utilization into the mix). The rest of the information is retrieved from SQL tables within Content Databases.

    There is a good chance that your ASP is not hitting the SQL box as hard as SharePoint does. You did not specify your configuration, but odds are, with all three of these running on the same box, you may be overcommitted from a RAM perspective. If your RAM is indeed overcommitted, you will be able to see the disk queue length go up during these times, indicating that you are hitting the disk I/O pretty hard (and resulting in a much slower system - RAM is always faster than disk).

    Additionally, you may want to look at your SQL configuration to see if you have tuned it a bit for better performance by offloading disk I/O onto separate disk spindles (particularly for more intense loads such as TempDB). Search (SharePoint Standard and Enterprise) can also be offloaded onto its own spindles/volume to increase performance.

    One last thing - as you mentioned, search can and does consume reasonably high amounts of I/O. You were not specific as to which version of SharePoint you are using. If it is SharePoint Foundation 4.0, then you are running frequent, smaller searches which can be tuned to have longer time intervals between searches. If you are using SharePoint Server 2010 Standard or Enterprise, then you can configure the box to perform its indexing in the evening/overnight - the searches will then work against a catalog which is stored on the local file system.

    Hope this helps


    Troy Lanphier -- MCT/MCSE/MCITP SharePoint Server 2010 Administration -- Author: Microsoft SharePoint Foundation 2010 Inside Out -- http://blog.sharepointcookbook.com

    29 Februari 2012 3:10
  • " If you are using SharePoint Server 2010 Standard or Enterprise, then you can configure the box to perform its indexing in the evening/overnight - the searches will then work against a catalog which is stored on the local file system."

    This is the version we're using.  Can you send me a link that shows where I can toggle this?  This is what I've been trying to figure out with no success.

    Honestly, there isn't even enough on this site to warrant a search function. 


    ----------- Ron E Biggs Network Administrator Entertainment Studios

    29 Februari 2012 21:32
  • This may be a good site for you to start with:

    http://technet.microsoft.com/en-us/library/ee792876.aspx

    In particular, it links to a video that explains the crawl (indexing) process and how it can be configured. But if you still have any questions or concerns after review the information, let us know.


    Regards,

    Jerad Plesuk
    Technical Support | SharePoint Technologies | Microsoft Corporation
    -----------------------------------------------------------------------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights


    02 Maret 2012 20:05