Reproduction: 1. Enter https://autoconfig.thunderbird.net/v1.1/web.de in your browser 2. Reload Actual result: 1. I had to wait 15-20 seconds (!) for the result 2. I have to wait about 1.5-2 seconds for the result Expected result: I have to wait about 0.2 seconds (200 ms) for the result Explanation: This service is designed to be very fast and low overhead, by having a stupid server that only delivers static files. It should be able to respond in 100ms, 200ms at the most. This should be true even over the Atlantic, as most TB users are in Europe. (The Atlantic adds about 80ms ping time.) The first query is might be slow DNS. But it's extremely, unusually slow. No idea why, but definitely something to look into.
> The first query is might be slow DNS. It's not, because I have the same effect when I query e.g. gmx.at, which I haven't queried before. Takes about 8 seconds.
Is this still an issue? I haven't been able to reproduce these results. However, I'll keep looking.
Hrm. So, I did a quick test of the URL via Pingdom (http://tools.pingdom.com/fpt/), which ran the test out of Texas, USA, which produced a 480ms load time. I did some more testing at WebPageTest (http://www.webpagetest.org/), which showed some odd results: Amsterdam, NL First View: 1.208s; Repeat View: 0.354s Boardman, Oregon USA First View: 0.968s; Repeat View: 0.344s Frankfurt, DE First View: 10.566s; Repeat View: 0.261s Moscow, Russia First View: 1.490s; Repeat View: 0.194s Paris, FR First View: 0.955s; Repeat View: 1.055s The Frankfurt site showed a *really* high initial load time. I'm not aware of any connectivity issues in Germany at the moment.
FWIW, the numbers above are from Germany. I also test from France. Yes, the issue still exists, it takes about 5s load time from Germany at the moment. Why is a repeat view faster? This shouldn't be the case, as these are static files. There's something wrong with the setup, e.g. a reverse proxy that shouldn't be there and that's slow.
there aren't any proxies at play here. all requests for autoconfig.thunderbird.net route through our static web cluster, which is served by 4 dedicated web servers. it's possible that the initial delay you were seeing was from pingdom's tools? lets see if we can do more testing from another source in germany?
I'm testing directly in my browser (with my personal proxy server), so the 10s first call delay is not any tool. It was slow inside Thunderbird, too - this is how I noticed the bug. If there are no proxies, why is there such a dramatic difference between first call and reload? Something's definitely odd with the setup. --- Bugzilla is slow, too, BTW. This bugzilla page takes between 5 and 32s (!) to load.
thnx for the additional clarification Ben. i just did some testing from our Paris office (i can't track anything down in Germany) and am seeing 1 sec response time to autoconfig.thunderbird.net (and bugzilla) - this includes initial load. [firstname.lastname@example.org ~]$ date; curl -I https://autoconfig.thunderbird.net/v1.1/web.de ;date Thu Jun 27 21:12:39 UTC 2013 HTTP/1.1 200 OK Server: Apache X-Backend-Server: pp-web01 Cache-Control: max-age=3600 Content-Type: text/xml Date: Thu, 27 Jun 2013 21:12:29 GMT Expires: Thu, 27 Jun 2013 22:12:29 GMT Content-Language: de Accept-Ranges: bytes Last-Modified: Wed, 01 May 2013 15:56:17 GMT Content-Length: 2017 Connection: Keep-Alive X-Cache-Info: cached Thu Jun 27 21:12:40 UTC 2013 this definitely does not go through any proxy. your request comes into a load balancer and is answered by one of our four static cluster web servers. bugzilla is hosted in a completely different location on its own cluster. are you seeing similar slow response times to all mozilla assets? blog.mozilla.org, www.mozilla.org, etc?
Sorry, please ignore my mention of bugzilla. That's a different issue. > am seeing 1 sec response time to autoconfig.thunderbird.net Yes, that's the bug. The response time should be 50-200ms (depending on location), given that it's static files. The service is designed to respond very fast, 1 second is 10x too slow.
(We're making several successive calls, so it does make a notable difference.)
(In reply to Ben Bucksch (:BenB) from comment #6) > If there are no proxies, why is there such a dramatic difference between > first call and reload? Something's definitely odd with the setup. Hello, The "first call" needs to set up an SSL handshake - that is why it takes longer. This is perfectly normal. Once the connection has been established, further requests are pipelined, so the time to completion is necessarily much lower. If there's anything else we can help you with, don't hesitate to let us know. Thanks, and have a great day !