locked
Slow initial access to sharepoint site from client RRS feed

  • Question

  •  

    Hello Everyone,

     

    We have MOSS 2007 setup in a small 2 server farm, 1 SharePoint 2007 server (X64) and a database server.  We have setup an intranet site for all the employees to access and it is working well and running smoothly.  The issue we are having is that when a client initially accesses the Intranet site the initial load times is quite long, upwards of 30+ seconds. It will display some of the site but it looks very bare, in the status I can see it says (18 items to load) which slowly counts down then the page shows up.  Once the page is loaded accessing any part of the site is very quick, but if you press F5 to refresh the browser screen for any reason it does it again.  So basically, as long as you don't refresh the screen the site will run very quick even if you close your browser and start a new session.  I understand there are warm up scripts that you can put on the server to help speed things up after an IIS reset or reboot of the server, but this doesn't seem to be the same issue.  If I log onto the server directly and load up the intranet site up locally it is always quick regardless of what user I log in with.

     

    Any thoughts would be appreciated.

     

    Thanks!

    Rob.

    Monday, July 9, 2007 4:33 PM

Answers

  • Allthough Bardapony's solution seems to work I did some more investigation:

    - we are all running HP systems

    - if you setup SSL you will have noticed that the SSL version did not stall

     

    As I suspected the NIC driver I disabled TCP offloading and now it flies ..

     

    Procedure (might be slightly different if you don't have a NIC team setup):

    - Double click on the green HP icon in your systray

    - Select you network team and click properties

    - go to settings tab

    - In advanced listbox select TCP Offload Engine

    - remove the Enable check

    - Report to HP (or Microsoft ?)

     

     

     

     

     

    • Proposed as answer by MJLongman Wednesday, April 27, 2011 3:00 PM
    • Marked as answer by Mike Walsh FIN Wednesday, April 27, 2011 4:08 PM
    Sunday, July 15, 2007 8:28 PM

All replies

  • Sounds like a switch issue.  We had the same issue ourselves with our ASP.NET 2.0 site, and found out the switch was the culprit.  If you have a spare switch to replace your current configuration, replace it, and verify it speeds up your transactions.  Keep in mind it can be any of the switches, hubs, or routers between your server and the clients you are using.
    Tuesday, July 10, 2007 12:03 AM
  • I'm having exactly the same problem. Please let us know if replacing switches solves your problem.

     

    Regards,

    Marcel

    Tuesday, July 10, 2007 11:50 PM
  •  

    Replacing the switch is not going to be an easy task, it's going to be one of those disputes on who's problem it is since everything else seems to be working without issue across our network of applications.  i'll get with the senior network engineer and see if we can do some diagnostics, perhaps we'll be able to see something that is causing this if it is a switch issue.  Thanks for the reply.

    Wednesday, July 11, 2007 8:26 PM
  • I reinstalled my pre-production machine. This time I used a fqdn for the database server e.g. dataserver.example.local instead of dataserver. Now it is a lot faster. I don't know if the network people at my site changed anything; it's a big place.

    Regards,
    Marcel


    Wednesday, July 11, 2007 8:34 PM
  • marnar,

    If I remember correctly, DNS queries are resolved before NETBIOS queries, so it is quite possible that would speed you up.

     

    Rob,

    Is there another computer /server that is residing on the same switch?  You can view the website from that same server, and see if you are still having the problem or not, and then slowly work your way through your network topology to see where the bottleneck is.  That may be a good way to convince your network guys of the problem at hand, if indeed the switch is the problem.

    Wednesday, July 11, 2007 11:55 PM
  • Well,

     

    There a few steps or simple workaroun you can perform to find the problem.

    1. Do you have gigabit ethernet?

    2. Can you copy data quickly from one server to other?

    3. Make a share in both servers and try to write or copy data from them from clients. (use the machines of your employees, and try to use the slowest).
      4. Connect a machine and the servers (if they are placed on the same room at least)  to a simple hub or switch, and try to access your sharepoint server. (make sure they stay connected to a dchp or dns servers.

    5. See the Event Viewer of both servers.

    6. Make sure your http://site isconfigured as local intranet zone in Internet Explorer security.

    7. It might be silly, but you can try to access your site with another browser and see what happens.

     

    Let us know... 

     

    Trying to help!

     

    Evaldo Santos

     

    Thursday, July 12, 2007 9:51 AM
  • Funny, we are seeing the exact same problem.  64 bit env, 1 gigbit network.

     

    When trying to upload a file from the server via HTTP it is extremely slow also, so hard to say it is just SharePoint.  We have been looking into this problem the entire week, reinstalled SharePoint and same result. 

     

    Our VM environments which use the same build process are working without problem on the ESX servers.

     

    Any suggestions would be greatly appreciated or if you figure this one out let us know.  We also opened a support call with MS so hopefully they will come back with something also.

     

     

    Friday, July 13, 2007 2:09 AM
  • Rob, what is your Platform?  What kind of servers are you using?  OS?  Enterprise edition?

     

    We are on HP BL25p G2 running Windows 2003 R2 STD for MOSS with MOSS Enterprise Edition.

    Friday, July 13, 2007 1:04 PM
  • I turned off Enable HTTP Keep Alives in IIS on the Sharepoint website and the stall problem disappeared

     

    Can someone verify this ?

     

    Friday, July 13, 2007 1:07 PM
  • marmar,

     

    Where did you disable the keep alives?

     

    Are you using any load balacing?

     

    We are using CSS for load balancing. 

     

    I disabled HTTP Keep alives on my environment and can not access any of the moss sites.  I believe our CSS also has keep alives enabled.

     

    I wonder if this would make a difference?

     

    Friday, July 13, 2007 1:38 PM
  • I did disable the Keep Alives in IIS. It solves the problem voor anonymous sites. But authentication stops working. So it is not a solution. One thing I did notice: the same site running over ssl does not have the problem.

     

    Not running load balancing. Running sharepoint 2007 enterprise on a HP blade on Windows 2003 Enterprise R2 SP 2
    Friday, July 13, 2007 2:03 PM
  • Can you give me more detail on the Server?  We are wondering if is hardware related or not.

     

    That's interesting about the anonymous access and the SSL access working but not the intergrated access.

     

    You want to set up a chat on MSN MSGer?  Maybe we can bounce ideas back and fourth?

     

    Friday, July 13, 2007 2:10 PM
  • feel free to add me to your contacts .. email is in my profile
    Friday, July 13, 2007 2:26 PM
  • This is what we did to solve the issue:

     

    • run cscript.exe adsutil.vbs find DoStaticCompression
    • then locate your process ID with the Web Appl your're having problems with.
    • then do a cscript.exe adsutil.vbs find DoDynamicCompression
    • located the IIS ID for the app you're having problems with.
    • then do cscript.exe adsutil.vbs set w3svc/IISID/root/DoStaticcompression "False"
    • then cscript.exe adsutil.vbs set W3SVC/IISID/root/DoDynamicCompression "FALSE"
    • then validate the settings
    • and do an IIS reset

    It should work.

     

    Not sure if this is the best solution considering that compression works just fine in our VM environments.....

     

    Friday, July 13, 2007 3:25 PM
  • Allthough Bardapony's solution seems to work I did some more investigation:

    - we are all running HP systems

    - if you setup SSL you will have noticed that the SSL version did not stall

     

    As I suspected the NIC driver I disabled TCP offloading and now it flies ..

     

    Procedure (might be slightly different if you don't have a NIC team setup):

    - Double click on the green HP icon in your systray

    - Select you network team and click properties

    - go to settings tab

    - In advanced listbox select TCP Offload Engine

    - remove the Enable check

    - Report to HP (or Microsoft ?)

     

     

     

     

     

    • Proposed as answer by MJLongman Wednesday, April 27, 2011 3:00 PM
    • Marked as answer by Mike Walsh FIN Wednesday, April 27, 2011 4:08 PM
    Sunday, July 15, 2007 8:28 PM
  • Great find Marmar!

     

    I applied this to our environment and it appears to have resolved our issue as well!

     

     

    Sunday, July 15, 2007 9:43 PM
  • We're having this problem as well, although it's not an HP system. I think it's intrinsic to SharePoint - I'm noticing a lot of other people having problems with the initial spin-up. I'll post if I figure out the solution to our specific problem.
    Wednesday, July 25, 2007 5:03 PM
  • The first time anybody visits the SharePoint site, it will take a while for it to load.  This is the nature of .NET-based web applications.  They have to cache DLLs locally, and so forth after an application pool reset.  By default, the standard Application Pool configuration recycles the application pool every night.  Verify that isn't your problem.
    Wednesday, July 25, 2007 5:24 PM
  • We were doing a CTRL F5 to refresh the page.  The problem would occur on every system. 

     

    once we disabled the TCP Off loading then it worked just fine.  I'm wondering if the NIC driver was having an issue sending information to the 64 bit OS/Server

    Wednesday, July 25, 2007 6:59 PM
  • First, before I post any details, I'll note that disabling HTTP compression fixed the problem for us (we tried disabling TCP offloading first, so it may be a combination of both steps).

     

    I have a suspicion that this problem is caused by a proxy server, but I haven't confirmed whether or not our connections are running through a proxy, so I'll leave that as suspicion for now.

     

    First, I'll point to a KB article about the TCP offloading issue, in case you want to look into this further: 

    http://support.microsoft.com/kb/936594

     

    Second, I'll note that you can quickly disable HTTP compression on the client side, before attempting to do so on the server side. The steps are:

     

    1. Open IE, go to Tools->Internet Options->Advanced->HTTP 1.1 settings

    2. uncheck both HTTP 1.1 checkboxes (e.g. uncheck "Use HTTP 1.1")

    3. CLOSE ALL IE WINDOWS. ALL of them.

    4. Re-open IE.

    5. Test.

     

    Third, I'll clarify the earlier post about how to disable HTTP compression on the SharePoint farm. I created a batch file that looks like:

     

    --

    c:
    cd \inetpub\adminscripts

    cscript adsutil.vbs set w3svc/1111111111/Root/DoDynamicCompression false
    cscript adsutil.vbs set w3svc/1111111111/Root/DoStaticCompression false

    cscript adsutil.vbs set w3svc/222222222/Root/DoDynamicCompression false
    cscript adsutil.vbs set w3svc/222222222/Root/DoStaticCompression false

    cscript adsutil.vbs set w3svc/3333333333/Root/DoDynamicCompression false
    cscript adsutil.vbs set w3svc/3333333333/Root/DoStaticCompression false

    cscript adsutil.vbs set w3svc/444444444/Root/DoDynamicCompression false
    cscript adsutil.vbs set w3svc/444444444/Root/DoStaticCompression false

    cscript adsutil.vbs set w3svc/555555555/Root/DoDynamicCompression false
    cscript adsutil.vbs set w3svc/555555555/Root/DoStaticCompression false

     

    --

     

    Let me briefly explain how you need to customize this batch file:

    1. Open up IIS. Expand so you see the "Web Sites" folder.

    2. Click on the Web Sites folder itself. This will display a "details view" of all your IIS sites.

    3. Write down the "Identifier" column for each of your SharePoint sites (I had 4).

    4. Repeat steps #1-3 for all of the servers in your SharePoint farm.

    5. Customize the script above, replacing "1111111111" with your first web site identifier, "22222222" with your second identifier, and so on. Note that your servers may not have identical setups, so check every server.

    6. Back up the IIS metabase.

    7. Run this batch file (I pasted directly into the command prompt) on each server in your farm. Run iisreset on each server afterwards.

    8. Test.

    Monday, August 13, 2007 9:34 PM
  • Curtis: As it turned out, we had a switch issue recently and the switch in our data center was replaced, but the issue still exists. I also found out that all the servers that are on the same VLAN as the SharePoint server do not have this issue, they can access at full speed all the time.

     

    Bardapony: Our platform is Dell PE2950 running Windows Server 2003 R2 SP2, MOSS 2007 Enterprise Edition.

     

    Marnar: My Dell has Broadcoms, I don't see a setting for TCP Offloading, I do have CheckSum Offload and Large Send Offload but neither helped the issue if disabled.

     

    pseale: Unchecking both HTTP1.1 options in IE on the client works, with both disabled SharePoint flies on the client. I'm going to try the script you mention in your post on the server side.

     

     

     

     

    Thursday, August 30, 2007 2:49 PM
  • We have a Staging server and a Production server with SharePoint 2007 installed. The slow initial load issue happens on the Production server, but not on the Staging server. As far as I can tell, the two servers are configured the same (both hardware and software).

    Disabling HTTP Compression fixed the issue on the production server. The Staging server has HTTP Compression enabled and works fine.

     

    Anyone could help explain this? And why "Disabling HTTP Compression" fixed the issue? We do not have proxy servers.

     

    Thanks!

    Tuesday, September 11, 2007 4:46 PM
  • I believe this is a Microsoft related issue as last I heard the environment I was working on was having the slow page loads even with the TCP Off load disabled. 

     

    I'm willing to bet that this will have to get resolved via a patch from MS.

     

    Wednesday, September 12, 2007 2:08 PM
  • Very likely that you have a problem with alternate access mappings... I would add an alternate mapping with just the IP address of the server and test it like that. Also, verify your alternate access settings with your networking people.

     

    The initial the delay ( and the delay when you hit F5) is most likely due to reloading the css and js files. After the first request they would be cached on the browser. I would also check the HTML source of tha page and see the source urls for css and js files. If you have alternate access mappings not set properly, the page might be requesting those files from a different root URL.

    Friday, September 14, 2007 9:54 AM
  •  

    My Sharepoint Project server 2007 site seems to run slow when a user first accesses it in the morning too. I had the same problem when it was installed on another server, but other custom web applications ran fine by responding quickly. I think Curtis Ruppe is correct in saying that the issue is caused by the need to cache DLL's after the application pool reset.

    I had a look at my site's application pool and there was a default setting which says "Recycle the worker processes at the following times" and "01:15" is set - this would seems to tie in with the fact that our sharepoint/Project Web Access site runs slow each morning on any initial access attempt. I ran a quick test and scheduled this to happen  whilst I was accessing the site, as soon as the scheduled time came around, sure enough, the site had a slow response after the first access attempt on various pages.

    As a possilbe solution, perhaps the worker processes could be recycled less frequently to reduce the impact of this problem or perhaps a scheduled task could be created to automatically access the site on the server after the worker process has been recycled.

     

    Hope this helps others,

     

    -Si.

    Thursday, September 20, 2007 9:06 AM
  • Hi, thanks very much for your fine help. I just followed all the steps thah you suggested without success. First: Disabled the TOE on my server. Second: Disable the HTTP compression in my client. And lastly, I apply the script to all my sites. It looks like was successfully applied but when I run the cscrip adsutil.vbs find DoDynamicCompression and  cscrip adsutil.vbs find DoStaticCompression the sites still appear as enabled for compression. Event after IISRESET. What is wrong?  The access still slow.

     

    This is a sample of my script:

    c:
    cd \Inetpub\AdminScripts

    cscript.exe adsutil.vbs set W3SVC/1042909730/Root/DoDynamicCompression "FALSE"
    cscript.exe adsutil.vbs set W3SVC/1042909730/Root/DoStaticCompression "FALSE"

     

    My enviorement,

    MOSS 2007: PowerEdge 6950, 32GB RAM, NIC Broadcom with TOE (now disabled), Windows 2003 Server x64 SP2, MOSS Enterprise spanish.

    SQL: PowerEdge 6950, 32GB RAM, NIC Broadcom with TOE, Windows 2003 Server x64 SP2, SQL 2005.

     

    Monday, December 17, 2007 4:12 AM
  • Very interesting thread! Can I just ask, what's an acceptable access speed for a MOSS front-end? Today on out 2003 platform it takes me 2.5 seconds to load the front page. On our MOSS (which is currently not put in production) it takes 12 seconds (!)


    What are your response times?

     

    Regards

    Victor

    Monday, March 17, 2008 9:35 AM
  • We have the same problem and it causes up to a 40 second delay on our public facing production (2 load balanced) servers.  Our staging server is fine (no load balancer).  We have disabled http compression and I believe we updated the nic cards as mentioned in a previous post.  This only happens on the initial load of the page. 

     

    We have traced it to the webresource.axd file.  If I clear my temp internet files, load the page it will pause the first time.  Once loaded it is fine unless I delete (only) the webresoucre.axd files from the temp files.  Then I can reproduce the problem each time.  So that seems to be the culprit (combined with HP servers and a Cisco load balancer) in our case.  The problem is how to solve it. 

     

    Moss 3.0 (2007) should already exclude the "managed path" unlike 2.0 which I have found some articles about.  It seems like it may be hanging when calling the axd file so maybe it's a .Net permission issue, domain issue, or domain controller issue (our site is public facing and allows anonymous users)?? 

     

    We have gone as far as taking one server offline to test the load balancer with no success.  We also have the same problem on the internal IP just calling one server directly and bypassing the balancer.  Any suggestions would be appreciated.

     

    Thanks,

    Steve

    Saturday, June 14, 2008 12:18 AM
  • I'm surprised to hear this is still going on.  I know the TCP off Load helped the issue and that we were having a while back but I'm not certain of another solution.  We did bring this to the attention of MS who said they were going to resolve it.  I did not see this issue on my last MOSS project.

     

    I would suggest contacting MS and talking to them and posting their solution b/c this shoudl be fixed. 

     

    Are you using SP1? 

     

    Be careful with deploying SP1 though, it will remove security permissions to some of the shares acress the farm.  Won't happen on a single instance.

     

    Sunday, June 15, 2008 3:34 AM
  • This was awesome!!!   Marnar's fix with HP NIC card setting did the trick.

     

    I've been troubleshooting this problem since I installed Sharepoint, withou much success. 

     

    Also fixed a strange problem with integrated Reporting Services too.  With a multipage report being server up from Sharepoint the 1st page responded fine but when you moved to the next page it would hang and the progress meter would slowly increase until finally the next page would be displayed.

     

    Thanks.

    Thursday, June 19, 2008 5:25 PM
  • Well, I was out of the SharePoint picture for a bit there but now that I'm back I found this slowness to be unbearable.  I installed some Password Management WebParts and they REALLY slowed to a crawl when being used.  Everything was VERY fast once you turn off HTTP 1.1 on the client, so I just went ahead and followed Bardapony's advice and made the change to DoDynamicCompression to FALSE and now everything is running fast as it should.

     

    Thanks Bardapony!

    Friday, June 20, 2008 3:57 AM
  • Steve,

    Did you ever find asoluton for the 40 second delay issue on sharepoint?  I'm noticing the same problem on our sharepoint server and I traced it to webresource.axd.

    Thanks.

    Andrew

    Monday, June 30, 2008 7:22 PM
  • Andrew,

     

    When I first encountered this problem we also traced it to the Webresource.axd file.  THere are two suggestions in this thread on how to fix the issue.  I would suggest trying that then also ontacting MS.  This is a bug in SharePoint and I know we brought it to their attention last year along with HP.  We were thinking that it was a driver issue with the NIC on the HP server. 

     

    Have you tried to install SP1 for MOSS/WSS?  I'd be curious to know if that fixed the issue.  Also, please post your hardware specs on the server, I'm curious to know if it is HP (which I'm betting on) and if your on a VM or physical environment. 

    Tuesday, July 1, 2008 1:34 AM
  •  It's HP proliant with two dual-core processors  (3GHZ) and 4 GB RAM.  It is not a CPU or memory issue per perf mon.  

    Disabling compression is not a good option for us since we have dial up users.  MOSS SP1 is already  installed.  We will open a case with MS. Thanks.

    Tuesday, July 1, 2008 6:20 PM
  • Please post the results you get from MS.  I and I'm sure others, would be interested on the fix.

     

     

    Tuesday, July 1, 2008 7:07 PM
  • Try checking the performance settings in the application pools themselves.
    Tuesday, July 1, 2008 8:53 PM
  • Hello. 
    I have got the same problem and it seems not to be an intranet sharepoint sharing problem. I am using Moss over internet and some clients are complaining about this issue. In some computers the access to sharepoint takes over a minute to deploy the web page. Curious the login window opens immediatly, but the page takes to long to deploy.

    Trying, to solve this problem, to post solution.

    ps: Sharepoint 2007 w/ SP1 
    Thursday, September 25, 2008 5:43 PM
  • Hi all,

    check out this link .. i think it has a solution and the problem discription makes very much sence ..
    i haven't tried it yet but would like to know if it will work with you or not...

    http://jritmeijer.spaces.live.com/blog/cns!8A48A27460FB898A!965.entry

    P.S. i can't belive Microsoft is too damn lazy to address this issue properly throught patches or even KB articels...
    • Proposed as answer by HanyR Thursday, October 2, 2008 9:53 AM
    • Unproposed as answer by Mike Walsh FIN Sunday, April 26, 2009 11:41 AM
    Thursday, October 2, 2008 2:57 AM
  • Hello

    Use SPwakeup, it will solve the problem of first access to the sharepoint site.

     

    Follow link to more information: http://spwakeup.codeplex.com/

     

    Raphael Carvalho

     

    Thursday, May 6, 2010 7:05 PM
  • I checked your post. It was a network issue. I did not have to change any network settings or run any scripts. I have two nework cards. I had one of my network cards unplugged. DNS had a host mapping for the unplugged network card IP address. Once it saw that the site was not on that IP it looked otherwise to find the next mapping and found the site. This was what was slowing my site down.

    Under the SharePoint Web Sites properties I had the IP address unassigned. :p

    Plugged in the network card. Boom ... done !! Issues resolved.

    Monday, January 24, 2011 6:50 PM