Deprecated - Performance and scalability

We have developed a patch that is likely to be accepted into Drupal 4.7, http://drupal.org/node/45414. The static file caching patch reduces load on the server in four ways.

1) Database load: Anonymous users are served static pages directly with out contacting the database for session management or other database queries, reducing the anonymous load to 0 and allowing the query cache to be used more effectively for authenticated users.

2) Disk IO load: Pages being served by Apache or a web server will take advantage of the operating systems internal page caching mechanism meaning most popular pages will be served directly from memory and not from disk reducing disk IO latency.

3) PHP CPU load: If the static caching patch is configured much of the Drupal PHP that needs to be interpreted or even loaded load from an Op cache will not be done as Drupal is largely bypassed in serving pages.

4) Apache thread load: Drupal's PHP apache threads are at least 16MB each. Static pages in a directory can be re-directed and served from a separate web server that will use 1M threads for anonymous pages meaning that expensive threads for Drupal can be reserved just for expensive operations.

These results have been validated with a similar file caching patch for Wordpress.com. Please test this patch and help us get this patch into Drupal core. If you are interested in funding this kind of development please contact me.

I'm running into odd behavior with drupal when I enable APC.

Specifically the $ _SERVER autoglobal is empty inside of bootstrap . inc

It seems like $ _REQUEST is also empty in other pages which causes some form to have ? for their action attribute.

I had set APC to 'cache_by_default'. Should I turn that option 'Off' and have a specific 'filters' setting? are there certain drupal pages that should not be cached?

Thanks.

Drupal 4.6.5: There is a problem with performance while translation is being used. The database query (for instance):

SELECT s.lid, t.translation FROM locales_source s INNER JOIN locales_target t ON s.lid = t.lid WHERE s.source = 'this is purely fictious English text example' AND t.locale = 'pl'

takes (for instance) 100 time units to execute. The problem is: there is no index on 'source' field. After:

ALTER TABLE `locales_source` ADD INDEX `source` ( `source` ( 15 ) );

I remember reading a while ago that taxonomy access had severe scaling issues...
Mainly that a certain MYSQL table would grow too large for any real application..

was this ever resolved?
is taxonomy access still not a viable solution?

thanks
ryan grace
thefractal.org

After editing (making a change and clicking Submit) x-number of times and clicking the Submit button again, I am taken to a white page. It can't be refreshed. I can only go back to the edit-view of the page. I then have to delete some of the revisions for the new edit to go through. How to you eliminate this restriction?

After editing a book module page (the HTML for in the body window) for more than 10 minutes and clicking the submit button, I get a "This page cannot be displayed error." If I click the refresh button on the browser, I get the page in editing mode back but all my edits are lost. Does anyone have an idea of what is behind this and how to fix it?