Re: some ideas for open discussion

Hi Wez!

If we change /error/index.php -> /error.php and re-evaluate the way we use include, we can eliminate a whole bunch of stat() syscalls (see Ilia's recent commit, and also Rasmus' commits).

For the stat() stuff, I would have a better idea. As we are in a web server environment, and we are exclusively using Apache, we can rely on being $HTTP_SERVER_VARS['DOCUMENT_ROOT'] set up. We also know the exact place of what we are going to include at every part of the pages. So we can build up an absolute path using $HTTP_SERVER_VARS['DOCUMENT_ROOT'] without having any stat() calls at all. Note, that we still have a few mirror sites who have not upgraded their servers, so we are unable to just use $_SERVER['DOCUMENT_ROOT'], which would be nicer. There is some code in prepend.inc to overcome this, and so after that file is included $_SERVER can also be used. Sites using PHP < 4.1.0: br2.php.net [4.0.5], de2.php.net [4.0.6], it2.php.net [4.0.4], lt.php.net [4.0.6], php.unam.mx [4.0.6]. As this is a very small number compared to the full number of mirrors [100], I would suggest to disable the listing of these mirrors and notify them that they need to update the PHP on their severs or otherwise we will remove them. This would enable us to use $_SERVER without any magic: include $_SERVER['DOCUMENT_ROOT'] . '/include/prepend.inc'; Having no stat calls ;) I need some agreement on this though, before calling on those mirror maintainers.

This also solves the relative links problem that you mentioned.

It does not solve it. The problem I was talking about is that we have URL shortcuts, eg. http://php.net/echo. If we include the manual page here, instead of redirect, then the relative links will be relative to this position (and not to /manual/en/function.echo.php which is the real path to the manpage). So every TOC element and link in the content of the page will point to a bad place. But I know now how we can do the <base> stuff with nice true values. We can use the configuration arrays and values. The sendmanualheaders() call includes the language, the page is in and the manualheader() call includes the filename. So we just need to glues these together to print out the <base> tag: <base href="$MYSITE/manual/$lang/$filename"> where $lang is remembered from the sendmanualheaders() call, and $filename is a parameter of manualheader(), so it is right there available. That would enable us to include the manual pages when using shortcuts, and the relative links will still point to the right location (thanks to the properly set <base> tag :).

If we have a well maintained search "center", and it is capable of handling the load (a *LOT* of requests are made to search.php), then I'm all for using it.

ACK.

Adopting the country detection code on ch.php.net and having it link to an appropriate mirror will help (essentially making ch.php.net into a dedicated search engine, rather than serving pages).

Good idea.

Having at least one mirror per country with search facilities will avoid killing ch.php.net. Having a second search mirror in the USA will help a great deal also.

Sadly it is not easy to convince mirror maintainers to have local search support.

revising /search.php so that it doesn't redirect to /manual-lookup.php (instead, handle the lookup itself), will save a redirect.

Hm, that probably would not be too hard. Is there any problem with include()ing that right away instead of redirecting? I don't think that search.php needs much revision here, simply including manual-lookup.php will work right now. The redirection simply passes on the $pattern and $lang vars, with the same names in the URL. manual-lookup.php and search.php and quickref.php [included from manual-lookup.php] all use include_once to include prepend.inc so multiple includes will not be a problem either. IMHO a simple replace of the header() call with an include will work. Any problem you see but I don't?

I've got nothing against your ideas; please stop insinuating that I've taken over the phpweb; all I have done is to prevent a machine-killing load, so that we can now discuss a nicer long term solution at leisure.

I am happy that you see that the time is right for discussions. What I was upset with is that it seems to me from your letters that the php-mirrors guys are the dilettant bad boys, who add inefficient code, and the systems guys are those who fix those ugly things and make the server work. This may not have been the intention, but I absolutely felt this. To provide you a better perspective on the same issue, I would like to assure you that I would be happy to help at any time, or to donate much more time on performance issues, if I would know that the server is in danger of going down. The main problem here was the lack of communication I think. The guys who are not at systems@ were not aware that there is any serious performance danger at www.php.net. There were some flying rumors, but no critical statement from anybody. I would also contributed my additions with that in mind, if I would know. So to make a long story short, you can make your own life easier by telling what not to do, and what to take in account to those who can screw up [or add code to bog down] the server. Just push more information for us, and let us participate, and you need to spend less time on fixing things later on. That would also make us more happier feeling that we are truly members of some community. Goba