Pete, you can pick any other mirror to work with. Only php.net redirects you to mirror sites, and only because it would probably be slower under the high load then your local mirror.

We are working to get a better search engine [mnogosearch based] to mirror sites. We were not satisfied with htdig, and know the limitations of google. No mirror so far offered to handle a "central search server" load which would be high because the search is not going to be set up on php.net.

Please be a bit patient. Until then I'll try to contact the maintainer of es.php.net

I think it would be better to deactivate this mirror for the time being.

I definitely agree with the deactivate the mirror comment.  Anyone who encountered that kind of speed on their first attempt to use php.net would probably give up and not try in the future.  It's like making the door of your church hard to open, don't want to turn away the converts.

Perhaps mirrors should be able to satisfy minimum load requirements before they go live?

Don't worry I'm patient, I just wanted to be helpful.

I can perfectly understand your reasoning Pete, but we have no method to measure mirror speeds from a central administration machine. We are able to check if it is up, if it is updated, and check several other parameters it provides about itself. But that it is slow if accessed by our bot does not mean that it is slow when accessed from a local machine. There are several ISPs, who have very weak international connections but a strong local connection. We can only act on user reports. At least I don't know of a solution...

BTW the ee2.php.net is now free, as the Korean mirror which was there is removed now. So if some ISP comes with an offer to set up a mirror in Estonia, we won't turn it down.

Ups, disregard my last paragraph, that is not in connection with this bug report. But the first para is correct. BTW is the speed of es2.php.net OK?

After consulting the maintainer, he sent me this message:

| We're sorry to hear that! 
| We have some congestion with our outgoing traffic,
| but we are working on it.
|
| We're planning to move to another physical location
| before July 6th. In this new place, we will have
| much more bandwidth, and this problem will be
| solved.

I am going to disable the mirror with agreement with the
maintainer until they can get better bandwidth.

BTW the question of measuring mirror speeds is still up, in case someone has an idea. :)

es2.php.net is definitely acceptable, and much faster than es.php.net.  However I compared a few function searches on es2.php.net to us2.php.net and us2 (just by my own counting) appears to be at least 3 to 4 times faster (I am in barcelona, high speed access).

Perhaps mirrors should be responsible for measuring it themselves when they apply for certification?  Whoever the maintainer at the mirror is just goes home at the end of the day or to the local internet cafe and runs apachebench or something similar with predefined parameters.  If it can't carry a certain load it's a no go. Or based on the apachebench numbers the redirects could be weighted.  es2.php.net gets 5 to es.php.net's 1.

We cannot do automatical apachebences from one place as said before, it would not be accurate data. We suppose the those who offer mirror hosting has the bandwidth (this is also emphasized on /mirroring.php)

I wasn't suggesting that automic apachebenches be done from a central location.  I was suggesting that the potential mirror site do it themselves from a computer in the community they would serve giving them and you a better idea of whether or not they can meet the estimated 150mb per day load.

Given the current situation it appears that, es.php.net is either receiving more traffic than they anticipated or they underestimated their ability to handle an extra 150mb a day on whatever machine they're using.  Perhaps the 150mb a day expectation should be upped for 2003 or if the later is true they could use a load tool to get a better idea of whether or not they can handle the estimated traffic.

I hope that is clearer.

Es.php.net was moved to a different server location, so its up to the requirements now.