php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23953 es.php.net is so slow it is unusable
Submitted: 2003-06-02 07:07 UTC Modified: 2003-08-07 13:09 UTC
From: pete at foxcreekleather dot com Assigned:
Status: Closed Package: Website problem
PHP Version: 4.3.2 OS: NA
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: pete at foxcreekleather dot com
New email:
PHP Version: OS:

 

 [2003-06-02 07:07 UTC] pete at foxcreekleather dot com
Since www.php.net has begun dynamically redirecting based on IP address the site has become so slow as to be unusable.  I will type in a function I want to search for and often have to wait more than a minute for es.php.net to load.  Unfortunataly this makes the site almost unusable for me.  I am working from Barcelona over a high speed connection.

The search documentation function is also useless to me now.  I have never found what I was searching for since you switched over to pointing at google instead of using htdig.

I realise these are not so much bugs as usability issues, but these two points have definitely impacted how helpful this site is to me as a learning tool.

That said the only reason I know php is because this site is so good.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-06-02 11:57 UTC] goba@php.net
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
 [2003-06-03 07:20 UTC] jrpozo at conclase dot net
I think it would be better to deactivate this mirror for the time being.
 [2003-06-03 07:27 UTC] pete at foxcreekleather dot com
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.
 [2003-06-03 07:57 UTC] goba@php.net
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.
 [2003-06-03 08:24 UTC] goba@php.net
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?
 [2003-06-03 08:30 UTC] goba@php.net
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. :)
 [2003-06-03 08:51 UTC] pete at foxcreekleather dot com
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.
 [2003-06-03 09:05 UTC] goba@php.net
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)
 [2003-06-03 09:29 UTC] pete at foxcreekleather dot com
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.
 [2003-08-07 13:09 UTC] goba@php.net
Es.php.net was moved to a different server location, so its up to the requirements now.
 
PHP Copyright © 2001-2026 The PHP Group
All rights reserved.
Last updated: Wed Jun 17 15:00:02 2026 UTC