locked
Performance <-> Permission Issue RRS feed

  • Question

  • Hey out there,

    we are facing a situation with slow sharepoint (pages)

    The Pageload does use unti 10 sec

    For testig purpose we deactiavted all kind of target audiencing and get a clear benefit, so we proceeded to start inn the permission area.

    In Dashborad we got these values

    proc_SecListScopeGroups 107.70 ms 
    proc_SecGetUserPermissionOnGroup 3.46 ms 

    But we do not have any values to compare. Is this fast, slow, acceptable?

    Any help would be great!

    many thanks

    Chris

    Friday, February 24, 2012 8:47 AM

Answers

  • we dived with MS Support Team into the instalaltion and found the Count of ACL to be the Source.

    Unfortunatly it was far from the official Limits (under).

    We got a script to remove some of them and cleaned up. Now we have to work around that Issue and create another Security Concept.

    P.s. cleaning ACL reduces Backup Size from 500 MB to 195 MB.....

    Best Regards

    Chris

    Sunday, April 29, 2012 9:01 AM

All replies

  • Hi,

    100ms is fairly slow i would say. What is the structure of your security. is it this slow on all pages?


    Regards, Chris

    Friday, February 24, 2012 8:57 AM
  • I concur with Chris that 100 ms seems a bit slow, but obviously that doesn't account for a page load of 10 secs. You should start to do a number of things:

    - Do some capacity planning and check if you're crossing any lines (i.e. maybe your creating too much security groups). Check out: http://sharepointdragons.com/2011/12/05/sharepoint-capacity-planning/

    - I always propose to check a number of perf counters to get a feel for how you're servers are doing: http://gallery.technet.microsoft.com/PowerShell-script-for-59cf3f70

    - Last but not least, the IIS logs are an excellent way to get to know your SharePoint web apps. Which pages are slow, are they always slow, are there lots of failed requests and so on. I've created a community tool that allows you to determine such matters easily (or you can also revert to a commercial product if you have one): http://gallery.technet.microsoft.com/The-SharePoint-Flavored-5b03f323

    At this point, there's no telling if you're servers are indeed slow or why, but there certainly is a distinct smell that you need to act.


    Kind regards,
    Margriet Bruggeman

    Lois & Clark IT Services
    web site: http://www.loisandclark.eu
    blog: http://www.sharepointdragons.com

    Friday, February 24, 2012 9:08 AM
  • Hey together,

    thank you for the fast responses. I guess there is no capacity issue. I missed to give you information regarding the farm:

    Sharepoint Farm P and Q face the same Issue, both use the same SQL and Active Directory environment.

    We do have two mirrored SQL Servers, each with 32 GB of RAM, 2 Eight Core CPU and a Fiberchannel SAN Storage.

    in P we do have 2 physical frontend Web Servers with 32 GB of Ram and 1 Eight Core CPU.

    In front of them is a F5 Network Load Balancer attached to 1 GB Internet

    in Q we do have a Vmware Machine with 8 GB of Ram.

    The Q System holds one App with 3 Site Collections, each holds one site (about 15 pages per site)

    So the Servers run fine :-)

    the issue hit all pages and get more extreme as more security is in site.

    I guess more interesting than proc_SecListScopeGroups 107.70 ms   (just one occurence in pageload) is the second one proc_SecGetUserPermissionOnGroup 3.46 ms   which occurs many times (i gues one time for each item qith unique permissions)

    best regards

    Chris

    p.s. we did also analyze the system by spdiag tools....
    • Edited by c_loki Friday, February 24, 2012 11:44 AM
    Friday, February 24, 2012 9:18 AM
  • Hi,

    100ms is fairly slow i would say. What is the structure of your security. is it this slow on all pages?


    Regards, Chris

    Hi,

    it is slow on all pages with security trimming, and gets slower if mor Views , mor items, audiences, .... added.

    We do have the sharepoint server in a Ressource Forest, and the Users in different Users Forests, which are connected by Forest Trust.

    Each "Main" Forest has minimum one Domain-Controller on the Sharepoint (datacenter) Site...

    best regards

    Chris


    • Edited by c_loki Friday, February 24, 2012 10:29 AM
    Friday, February 24, 2012 10:12 AM
  • Could this issue caused by the SQL Server?

    How to check if the SQL Servicer is the problem in this case?

    Are any profiling tools available out there?

    Saturday, February 25, 2012 1:02 PM
  • Could this issue caused by the SQL Server?

    How to check if the SQL Servicer is the problem in this case?

    Are any profiling tools available out there?

    Hi,

    we do have VS Profiling onsite in direct access and SQL Profiling needs to be requested in datacenter, but ist available.

    Saturday, February 25, 2012 4:35 PM
  • Hi,

    There is lots of reason which will impect the performace like the hardware, the content load, the topology and so on.

    1. Please analyze and esticate your topology and planning of the performance and capabilities based on following sources:

    http://blogs.msdn.com/b/sanjaynarang/archive/2010/04/20/sharepoint-2010-performance-stress-load-testing.aspx

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

    2. You can also use the third party monitor tools to trace your farm to find where the point is which impect the performance.

    http://blogs.msdn.com/b/markarend/archive/2010/05/27/health-monitoring-for-sharepoint-2010.aspx

    http://programming4.us/database/2922.aspx

    http://www.manageengine.com/free-sharepoint-monitor/free-sharepoint-health-monitor-index.html

    http://www.idera.com/Free-Tools/sharepoint-perf-monitor/

    Regards,

    Seven

    • Marked as answer by Rock Wang– MSFT Friday, March 2, 2012 3:52 AM
    • Unmarked as answer by c_loki Friday, March 2, 2012 9:47 AM
    Thursday, March 1, 2012 8:28 AM
  • Helllo Seven, and others :-)

    thank you for the different links for benchmarks, load testing, etc.

    But this was not the question.

    We had dived into the sSystem and found these parameters:

    proc_SecListScopeGroups 107.70 ms 
    proc_SecGetUserPermissionOnGroup 3.46 ms 

    The Question was (and is):

    Are these values okay, or not? More new values without information regarding the "wothy" would not help us....

    best regards

    Chris

    p.s. we tryed tools like idera, etc, but we do not have the option to create a new database.... so no option...

    Friday, March 2, 2012 9:51 AM
  • we dived with MS Support Team into the instalaltion and found the Count of ACL to be the Source.

    Unfortunatly it was far from the official Limits (under).

    We got a script to remove some of them and cleaned up. Now we have to work around that Issue and create another Security Concept.

    P.s. cleaning ACL reduces Backup Size from 500 MB to 195 MB.....

    Best Regards

    Chris

    Sunday, April 29, 2012 9:01 AM