is slow



Infrastructure & Operations
WebOps: Other
5 years ago
4 years ago


(Reporter: BenB, Assigned: phrawzty)





5 years ago
1. Enter 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

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.

Comment 1

5 years ago
> The first query is might be slow DNS.

It's not, because I have the same effect when I query e.g., which I haven't queried before. Takes about 8 seconds.
Assignee: server-ops → server-ops-webops
Component: Server Operations → Server Operations: Web Operations
QA Contact: shyam → nmaul
Is this still an issue? I haven't been able to reproduce these results. However, I'll keep looking.

Comment 3

5 years ago

So, I did a quick test of the URL via Pingdom (, which ran the test out of Texas, USA, which produced a 480ms load time.

I did some more testing at WebPageTest (, 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.

Comment 4

5 years ago
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 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?

Comment 6

5 years ago
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 (and bugzilla) - this includes initial load. 

[cturra@admin1a.private.par1 ~]$ date; curl -I ;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?,, etc?
Flags: needinfo?(ben.bucksch)

Comment 8

5 years ago
Sorry, please ignore my mention of bugzilla. That's a different issue.

> am seeing 1 sec response time to

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.
Flags: needinfo?(ben.bucksch)

Comment 9

5 years ago
(We're making several successive calls, so it does make a notable difference.)

Comment 10

4 years ago
(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.


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 !
Assignee: server-ops-webops → dmaher
Severity: enhancement → trivial
Last Resolved: 4 years ago
Priority: -- → P5
Resolution: --- → FIXED
Component: Server Operations: Web Operations → WebOps: Other
Product: → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.