It does look like that mirror has a bit of a slow response time (3.3 seconds for 
me). However, you can set the default mirror to use yourself.

Simply go to http://php.net/my.php and scroll down to "Mirror site redirection" 
and from there you can select at2.php.net as your default mirror. It sets a 
cookie that helps you stick to your preferred mirror.

Cheers :)

Incidentally, for several years we've had minor, temporary issues with 
at.php.net, but nothing significant enough for removal.  Oddly enough, for me, 
any time I check from here in the US - including just now - it works just fine.

There are no plans to remove the mirror at this time, and yours is the first 
slow-loading report I've heard at least in recent memory.  It sounds to me like 
it's a routing issue.  Nonetheless, as suggested, you can set your preferred 
mirror and be automatically directed to your mirror of choice each time you 
access php.net.

Meanwhile, I'll see if I can reproduce the slow-loading issue from some Austrian 
proxies.

Thank you for your report, and please feel free to add any additional 
information you believe may be helpful in resolving the issue permanently.

I sure will as good as I can.

Okay, I might have overrated the time of 10-20 seconds, as it is more like 2-4 seconds, yet it feels like 10. See below.

I experience this issue over and over again from home (Vienna, ISP "UPC Telekabel"), home (Vienna, ISP "A1"), in styria (do not know the ISP, though) and some other places as well.

No offense to googleguy@php.net, but in those msec-times that we live in, 3.3 sec make me quite curious. So I digged myself in a little bit more. I wrote a little benchmark, which file_get_contents's three pages of php.net (/, /docs.php and /manual/de/features.http-auth.php in particular) and measures the time it takes to do so. This is then added up over 10 runs and divided by the total number of site loads (3*10=30). To have a good all-around-comparison I used at, at2 (Austria), de (Germany), and br (Brazil). Here the results:

At home, Vienna, "UPC Telekabel"
at:  total: 65.14 sec,   2.171 sec each
at2: total: 9.266 sec,   0.309 sec each
de:  total: 16.545 sec,  0.551 sec each
br:  total: 53.671 sec,  1.789 sec each

Might be a routing problem, so: a traceroute includes my gateway, *.aorta.net, *.aco.net and *.tuwien.ac.at

On a hosted server, Germany, "Hetzner.de"
at:  total: 73.905 sec,  2.463 sec each
at2: total: 5.154 sec,   0.172 sec each
de:  total: 5.058 sec,   0.169 sec each
br:  total: 47.068 sec,  1.569 sec each

Might still be a routing problem: a traceroute includes *.hetzner.de, *.init7.net, *.aco.net, *.tuwien.ac.at
So it could be .aco.net.

But now comes my favourite part:
At my Workplace, Vienna, Vienna UT internal
at:  total: 42.302 sec,  1.41 sec each
at2: total: 2.13 sec,    0.071 sec each
de:  total: 5.847 sec,   0.195 sec each
br:  total: 111.226 sec, 3.708 sec each

Yaaay, at least internally we are faster than Brazil to reach at.php.net. ;-)
A traceroute shows, that internal packages don't even leave .tuwien.ac.at (as supposed).

However, at.php.net is still MUCH slower than others (at2 was minimum 7 times faster in this mini-benchmark). If it were +/- 100% okay, blame it on uncertainity. But I personally find +703% to +1986% a little much. It's closer to my date of birth than to a reasonable percentage. ;-)

That's all information that I can provide you with. Frankly I work in another department at Vienna UT so I have no influence on that server system at all. As said above, okaaaay, 2.5 sec, it's not that much but still very annoying and I believe that I am not the only one with the problem. I just finally mentioned it because it kept annoying me for years now. ;-)

So could anyone please confirm such effects from somewhere else in the world, comparing at.php.net to, for example at2.php.net? I would then seek to contact the guys from the GDS of the ZID at Vienna UT and ask for their opinion.

Thanks again
Philipp

Between improvements and the round-robin features added, as well as a lack of 
further complaints, I'm marking this issue as resolved.