Hyperion Reactor The Middle Child of History

When the browser makes a request for a static image and sends cookies together with the request, the server doesn't have any use for those cookies. So they only create network traffic for no good reason. You should make sure static components are requested with cookie-free requests. Create a subdomain and host all your static components there.

Drupal tries to cater to 80% of the market by taking most decisions for you. Generally this is a good idea. But if you fall in the remaining 20% then you need to get your hands dirty and start hacking around. Drupal by default stores all sessions in the database. This is a good idea if your site does not get a lot of load. But as your site starts growing, this will soon become a major bottleneck. Storing sessions in memcache works best in such situations. Not only is memcache easy to maintain, install and work with, but also provides in depth stats about itself.

I have been playing a lot with Drupal lately. I must say it does feel weird getting back to PHP after so much Ruby; but it is a refreshing change. One of the the things I noticed is that Drupal 6 adds a LOWER() to the column names when it does a select. Not that this is bad but then it confuses MySQL, and instead of using the "name" index it runs through the entire database. This is not a issue if your site has a few hundred users. But now consider a site that has about 5 million users (which is what I am dealing with)

I just finished hacking up this patch, that prevents it from adding the LOWER() to the column names. This boosted something as simple as the login process from 5 seconds to milliseconds. 5 seconds may not sound a lot to you; but then I use a Dell 1950 as my development box. Not that it is the best box in the world, but it is pretty powerful.

Last week David Axmark the co-founder and author of MySQL visited my office. Thanks to Sun for making this meeting happen. We spent some time discussing about MySQL and development of applications in general. These are some of the key "take-away" points from that meeting. A lot of these points may seem obvious, but a lot of companies decide not to implement them for various reasons.

Everyone knows how good Ruby on Rails is from the point of view of developing, maintaining and deploying applications easily and quickly. But the one question that every one seems to be asking “Is Ruby on Rails scalable?”. This is mainly because, not many people have heard of Ruby before. This normally creates the FUD around the language and framework.