There are some people (such as newrisedesigns), who turn off all of the server-intense nodelets and maybe not use Newest Nodes and Super Search. Okay, so some people are trying to be 'environment-friendly' here. My question to such people is this: are you turning off those features because you don't use them or because you're trying to help the server out a little?

The answer to this question could raise some more questions about this topic: if you're disabling these features because you honestly never use them, then good for you! You're not putting any more stress on the server than what you want to use. If it's just because you're trying to speed up the server however, that's just the wrong answer. You cannot just say "turn off all of the good features of the site and then things will run faster". The correct solution we need to come up with is not that of "remove some features", but that of "improve the mechanics of these features so that they cause less trouble".

Upon a minute or two of reflection, here's a couple of questions I have come up with:

• Nodelet caching: there are some nodelets that don't need up-to-the-minute, real-time display. Take Daily Best and Weekly Best as examples. Each time I load a page, is this list researched and populated from the database or is it quickly retrieved from a cache that is updated every 15-20 minutes or so?
• Database held in RAM. I am curious to know whether the database itself is held in memory or if it is continuosly read freom disk. When I request a page, does the hard drive spin around and around to locate certain sectgions of the database, or is the database held in memory in such a way that the hard drive is only accessed for writes to disk? One point I do not know is how big the database is at the moment. Is it so big that it would be too much to ask to add some more RAM to the system to hold any/more/all of the database in memory? I got this question from reading (one of?) Philip Greenspun's book(s) in which he had a site that was managing many requests per second, while only using about 10% of the server's resources and hardly hitting the disk. Sounds like fantasy world to me :)
• Static pages: I was thinking about this one for a bit until I realized the worst part of wanting to turn some nodes into static pages: the nodelets. I already knew it would take a lot of time and effort to turn posts into static pages instead of needing hits to the db, but I thought I would mention it. Then I realized that the whole right-hand menu would not update at all, and I thought "oh, dumb idea then". Then I thought of maybe using a CGI include for that, then I thought "no, still stupid". It has been mentioned before about using the existing static backups of the site, but how many people really use these?
• Caching, caching, caching. I think a lot of the improvements that could be made would rely on caching things. From nodelets to nodes, maybe even search results, to who knows what else, I think there are probably many areas where information doesn't have to be updated as often as it is. Perhaps I am wrong, but I'll just hope that I'm right :)

Summary: I don't know the ultimate solution to speeding up the site, but it neither involves rewriting the entire engine, nor disabling popular, usefull features.

      C:\>shutdown -s
      >> Could not shut down computer:
      >> Microsoft is logged in remotely.