Re: Waiting for forums.adobe.com...

Noel,

In this case, it seems to be very wide-spread, affecting the UK, Europe, Africa, the Middle-East, and now Canada and the US, as of today.

Thanks,

Hunt

I think there are multiple things happening here...

• Momentary server burps or restarts that cause outages (which may be perceived by users as very long delays because of retries at the various protocol levels).
• Short term traffic surges or things running on the server that cause momentary slowdowns.
• Longer term traffic issues that may be overwhelming the servers.
• Variations in how long it takes for an individual cliient system to execute the software, which is not trivial.
• Differences in what different people think is acceptable performance.  For me, if something happens after I click in less than 2 seconds, I find it acceptable.

I believe I sense, in various folks' comments, that the percentage of time this forum provides acceptable performance for any one person varies pretty widely. 

For example, the great majority of the time I'm here I find it to work fine, with only rare cases where clicking on something yields a noticeable delay or failure.  If I had to quantify, I'd say it is acceptable 98% of the time for me.

Perhaps it would be helpful if you folks would try to quantify the amount of time you feel it performs acceptably well for you.

-Noel

Noel, you are losing the forest for the trees.

The roundtrip times are not relevant to the problem -- they are in the tens of millseconds, and the delays that users are seeing are measured in seconds (100 times longer than 10ms). That means that the network is not the bottleneck, and is perfectly fine.

Given the round-trip times, measured by ping, the delays shown by traceroute are even less relevant (perhaps that's why you edited out your quip about 1/3 time in Denver). Routers do not respond with ICMP TIME EXCEDED replies (used by traceroute) with the same priority as regular raffic. So you may see cases where the times reported by traceroute are greater than the end-to-end times reported by ping. This is a case of the diagnostic tool giving you misleading (and irrelevant) information. If the round-trip times with ping are satisfactory, as they are, there is no need to look deeper into the network (such as with traceroute), and doing so is just going to confuse and mislead.

But since you ask, for me right now, from Cambridge,MA at MIT to Jive via Sprintlink:

PING adobe.hosted.jivesoftware.com (216.245.178.32): 56 data bytes
...
--- adobe.hosted.jivesoftware.com ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 49.355/49.754/50.358/0.324 ms

Much more useful information is the time to retrieve a page. It's hard to instrument that as easily, because a brower has to retreive multiple HTTP URLs from different servers to render the page, including the page itself, the css, cookies, Adobe ID crap, images, etc. But if we look at just the base page, it gives you a sense of the time. Unfortunately I don't have a good tool to do that reporting, since curl (to my surprise!) doesn't seem to give the total elapsed stat. But we can fake it well enough with 'time':

$ time curl -O 'http://forums.adobe.com/message/3932147' 
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 42390    0 42390    0     0   112k      0 --:--:-- --:--:-- --:--:--  132k
real    0m0.392s
user    0m0.005s
sys     0m0.021s

That is, it took 392ms of wall-clock time to transfer the this current thread.  Much much greater than the round-trip time, so we can safely discount the round-trip time as being relevant.

I don’t have the exact figures available, but we are seeing 4x as many bot/crawler page views in forums as user page views per month.