Assuming that there is little that can practically be done to speed up the engine to the site, is there anything practical that could be done in other areas?

Given the large number of members (even if only the 'active' ones are considered), I for one would be more than happy to contribute a one-off $10 to a dedicated hardware fund if this would cut my waiting time for pages. If a (preferably dedicated) fund for faster hardware was established, it might be easily fulfilled.

• Would the ISP agree to allow the new hardware to be used?
• Would moving the existing codebase and database to new hardware be a reasonably simple transition?
• Would a straight 1-4-1 replacement do any good? I don't know what the current hardware is, but if it was already a dual-2MHz set-up, it would require more than just a simple/ cheap hardware replacement.
• Would it be possible, given the current software setup, to gain by adding a another box, rather than replacing one?
• If adding boxes is possible and beneficial, what are the limits? There are probably more than a few Monks that have 'old boxes' lying around that they would be willing to donate to the cause if this was a viable solution.
• Given the site already violates the taboo of frames (the <IFRAME> used by the advert), would it not be a reasonably simple process to modify the Chatterbox nodelet to sit in an <IFRAME> of its own, and have the whole CB laid off to a separate, dedicated box?

  Given that it is only transient data, it wouldn't have to access the DB (I think?) so could be a pretty much stand alone entity, and (so long as people use the talk button for refresh), would probably go a long way to relieving the CB related loads on the main server(s)?

• Maybe there is some mileage in have a second database box. It could be a fall-over backup for the main DB server, and could be used to handle such things as the titlebar search box and super search pages. It could be trickled updates/ new content from the main server by a low priority process on the main DB.

  I realise that this means that these searches would possible miss on the very latest content. Would this be a disaster? If the current backup (to whatever medium) from the main DB were done as replicates to the backup server, the backup server could takeover the backup to tape/CD whatever.

I also realise that I know nothing of the Everything engine nor the current hardware set-up, and that if these types of optimisations are to be considered, the first step would be to do the analysis to see what and where the bottlenecks in the system are.

I currently have both the time and enthusiasm to take on some of this work if it was deemed desirable. Whilst I don't have the requisite skills in the Everything engine (nor probably Perl) to be let loose on the servers, if (for example) the logs were zipped up and made available to me, I do have the skills and the time to perform analysis of them. I could then return the results to tye or whomever for verification and further action.

If there is any other way (beyond the obvious cash contributions) that would help in this particular regard, I'm all ears.