none
Forum performance RRS feed

  • Question

  • This is not really a questing but a note.

    Today for the first time in almost two years the performance of the forums is excellent.  The response time even on very long threads is almost instantaneous.

    The posts also happen much more quickly.  I used to have to wait for 30 seconds to as much as 2 minutes for a 'submit' to be completed. Now it is almost instantaneous.  In the past about one in ten posts would fail and the page would become locked or have to be refreshed and the post recreated.  I hope this fixes that issue to.

    Keep up the fixes and thanks for finding this one as it has been aggravating nearly everyone.


    ¯\_(ツ)_/


    • Edited by jrv Sunday, May 27, 2012 7:47 PM
    Sunday, May 27, 2012 7:33 PM

Answers

  • Thanks for the compliment! It's certainly tough, because there are a lot of elements involved. I hope the good performance continues!

    Thanks again!


    Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)

    Thursday, May 31, 2012 8:25 PM

All replies

  • Thanks for the compliment! It's certainly tough, because there are a lot of elements involved. I hope the good performance continues!

    Thanks again!


    Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)

    Thursday, May 31, 2012 8:25 PM
  • What I found today, that while everything seems to load quickly, when I try to access threads from another user's profile, it is taking a considerable amount of time (about 30+ seconds).

    For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Thursday, May 31, 2012 8:55 PM
  • Ed - today we hung for about 30 minutes but now it is back and still very fast.  In fact the site seems much faster after the hangup cleared.  It was taking forever to save a post and now it is instantaneous again.  I did some network probing to see if it was the network. It seemed to be only the site. I didn't run an analyzer so it could still be a bad link somewhere.

    ¯\_(ツ)_/¯

    Thursday, May 31, 2012 8:55 PM
  • I got a couple of slow loading today. Almost all operations are fast, but some (need to pay attention which ones) are slow.

    For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Thursday, May 31, 2012 9:07 PM
  • I got a couple of slow loading today. Almost all operations are fast, but some (need to pay attention which ones) are slow.

    For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Hi Naomi.  Since teh big slowdownearlier all things seem to have come back even faster.  |Either there was a network issue or the servers got reset.

    Since everyone gets in on a diffrent path it has to be hard to analyze the issues.  I also suspect that many transactions can take more time if there are many users posting at teh same time.  I have noticed that 'Submits' take longer during the afternoon.  Thngs like moving a thread might get hit harder by transaction load and by network turn around issues. 

    It is getting better so it is clear that someone is working on this.  They should set up remote analyzers in all MIcrosft Sales offices so all MS web sites could submit workflows to analyze performance from remote locations. (or are they already doing this?)


    ¯\_(ツ)_/¯

    Thursday, May 31, 2012 9:20 PM
  • From My Forums -> Transact - SQL forum -> clicked on Unread and it took about 20+ seconds to show the unread threads list.

    For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Friday, June 1, 2012 1:10 AM
  • I was reading this thread http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/334ec7b9-5c5c-4860-9418-2b75c0489f01 and then clicked on 'My Threads'. I counted to 65 in Russian before My Threads got loaded.

    So, there are still areas where the performance is still need to be fixed.


    For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Friday, June 1, 2012 4:00 PM
  • Naomi - less than three seconds repeatedly.

    I suspect that, if you count in Russian, the page has to get sent to Russia first.  That may take some time.

    Seriously.  ping your server then post the IP.  I willalso ping it and try to force a connection to the same server.  It may tell use something.

    If   I ping from my location I get:
    ping social.msdn.microsoft.com

    Pinging lb.social.ms.akadns.net [65.52.103.78] with 32 bytes of data:

    Differnt geographical location might be routesd to different distribution servers closer to the location.

    If I fo a GeoLocator on that IP it shows as Geneva Switzerland.

    http://www.geobytes.com/IpLocator.htm?GetLocation&IpAddress=65.52.103.78

    On the West coast it migh go somewhere else.  Also some cable providers have very bad overseas connections.

    Also this address can be resolved locally via HTTP as ping only does a raw IP access.  The page may actually be served from a local server.


    ¯\_(ツ)_/¯

    Friday, June 1, 2012 4:44 PM
  • Naomi - less than three seconds repeatedly.

    I suspect that, if you count in Russian, the page has to get sent to Russia first.  That may take some time.


    :) I'll play later, also, this behavior is sporadic - sometimes it loads in 3 seconds, but I still get these slow responses once in a while.

    I know that the person counts in his mother tongue, that's why I usually count in Russian :)


    For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Friday, June 1, 2012 4:48 PM
  • Sounds like the techs still have some work to do.   

    This is beginning to look like a routing problem now.  When we save an edit I suspect the save is redirected to a server closer to the database. 

    I wonder if there are multiple databases replicated in the cloud.  Maybe we are part of a big MS experiment to see how well a busy portal behaves in the cloud.

    It is still much faster for me than it has been for years.


    ¯\_(ツ)_/¯


    Save time on last edit was less than 3 seconds.
    • Edited by jrv Friday, June 1, 2012 4:50 PM
    Friday, June 1, 2012 4:49 PM
  • Another unrelated observation - if I use Quote, I had to go to HTML in order to type normally - I can not visually go out of the quote in the editor. I am using Google Chrome.

    For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Friday, June 1, 2012 4:50 PM
  • Are you using the lastest version of Chrome?  DO you get teh same issue with IE 8 or 9?


    ¯\_(ツ)_/¯

    Friday, June 1, 2012 5:41 PM
  • I wonder if there are multiple databases replicated in the cloud.

    That's how Answers works.   Apparently there are several clusters implementing it.   They had to add a diagnostic to the HTML to try to get more information about a similar problem symptom from its users so now we get to see the originating server ID in the source, e.g. by using F12 in IE.   FWIW this way I have come to know that I am always going to a cluster called  BL0n  and have seen numbers as high as  BL08.   There is still a problem with it that the submitter's profile gets updated with confirmation of the post long before the post itself gets propagated.   Have you looked at your symptom from that point of view, e.g. in a second tab?   FWIW that's my procedure now for checking if I need to take any extra backup precautions after Submit:  clone the tab with Ctrl-k, then check my All Threads list, if it has been updated at all, I can assume that my post has been received and eventually will be seen everywhere.


    FYI

    Robert
    ---

    Friday, June 1, 2012 6:08 PM
  • Are you using the lastest version of Chrome?  DO you get teh same issue with IE 8 or 9?


    ¯\_(ツ)_/¯

    Good point. I've updated Google Chrome and that problem seems to be fixed.

    For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Friday, June 1, 2012 6:16 PM
  • It is necessary t update Chrome frequently.  Everyone is fast setting up HTML 5.  I ssuspect MS sites are using HTML 5 on Chrome but CHrome may not be completely in sync with the satndards.  It takes a while to bootstrap a new standard and vendors on both ends will be tweeking things comstantly until the standards imlpementation is stabilized.

    ¯\_(ツ)_/¯

    Friday, June 1, 2012 6:31 PM
  • BTW, right now I got two slow moments again - first to check this forum and then back to this thread to report the slowness. I didn't count this time, but it was ~25 seconds for both cases.

    For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Friday, June 1, 2012 6:42 PM
  • BTW, right now I got two slow moments again - first to check this forum and then back to this thread to report the slowness. I didn't count this time, but it was ~25 seconds for both cases.

    For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Naomi - where are you comming from - general geographic location.  If you ping the web site what address are you being conencted to.  Finally, can you run a tracert to see if you hav inordanant delays before you timeout crossing the Microsoft network.

    THe follwoiing is always the backend of my route.

     5    15 ms    12 ms    13 ms  pos-3-10-0-0-cr01.newyork.ny.ibone.comcast.net [68.86.92.217]
     6    11 ms    12 ms    11 ms  pos-1-3-0-0-pe01.111eighthave.ny.ibone.comcast.net [68.86.86.190]
     7    11 ms    11 ms    12 ms  as8075-1.111eighthave.ny.ibone.comcast.net [75.149.230.34]
     8    12 ms    11 ms    11 ms  ge-1-0-0-59.nyc-64cb-1b.ntwk.msn.net [207.46.46.74]
     9    11 ms    11 ms    12 ms  ge-7-0-0-0.nyc-64cb-1a.ntwk.msn.net [207.46.47.20]
    10    84 ms    83 ms    84 ms  ge-7-0-0-0.co1-64c-1b.ntwk.msn.net [207.46.40.90]
    11    87 ms    81 ms   102 ms  xe-0-1-0-0.co1-96c-1b.ntwk.msn.net [207.46.33.183]
    12   102 ms    85 ms    82 ms  10.22.8.14

    The times are 82 - 102 on the upper end but since I cannot ping across the MSN network I can only surmise that there are no delays before hitting MSN.

    This is now while the performance is very good.  I ahven't done this when things are slow.  If the hops before MNS are fast but the system is slow then the issus is in MSN-land.  If the hops are slow before MSN then the problem in in the public network.

    Of course this is only one level of verification.  It only checks that teh transport is repsonsive to a degree.  It cannot show us packet issues. 

    In my case I started by noting that Comcast had many issues.  It has taken years to get thm to fix this but nowm for the last 4 months, the Comcast netork has bee acceptable at leat across the COmcast portion.  The gateways and DNS servers are now working better. All along I assumed the isses with techne were Comcast issues until I wsa able to get into other technet sites with no problem.  Now that the techs have found some of the problems with this portal my performance is very good. 

    I am surprised that your performance isn't good.  It is either routing/network or you may be connecting to a different set of servers. 

    Try using another tool speedtest.net and choose a server that is geographically loacated near where you connect to technet.  It might tell you something.


    ¯\_(ツ)_/¯

    Saturday, June 2, 2012 7:08 PM
  • This is what I got

    I am in WI, USA.


    For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Sunday, June 3, 2012 4:31 AM
  • Naomi - its 'tracert' not 'ping'

    You are connected to the same server in Switzerland' that everone else is in.  I wonder where the update servers are.  Are they on the same site?

    It is not a pingable site.  MSN is not pingable.  It is also not discoverable.

    The purpose of the tracertrt is to see how much latency is in your local network.  I suspect the delays are local to you; If so then you can likely get your Inet provider to address the issue.


    ¯\_(ツ)_/¯

    Sunday, June 3, 2012 9:02 AM

  • For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Sunday, June 3, 2012 4:19 PM
  • That is a good reading.  It shows that you ISP is not likely to be the issue. 

    I have good performance and my tracert time are pretty much identical.  75ms to the MSN gateway is about what you can expect.

    I get a slightly different route into MSN so it could be an internal MSN issue with the gateway you are using but it could also just be a difference in behavior because of the browser you are using or the timing.  I may not be hitting the same conditions as the problem seems to be sporadic.

    Only an analyzer can tell us where you are seeing the issues and if it is caused by the IIS servers or the network or both. 

    Router configurations along the path can aggravate issues with web page delivery.  ISPs switching network loads can also cause issues.  Only an analyzer can detect this.  That is why I recommend that TechNet place analyzers at Microsoft sales offices. These can be used to run periodic traces to be sure that the page access is not being disrupted. 

    Performance issues can also be caused by server application errors being aggravated by network conditions. If the application doesn't cache properly or the application does not respond to rerouted packets correctly it may aggravate network and browser issues.


    ¯\_(ツ)_/¯

    Sunday, June 3, 2012 6:02 PM