michi bloggt!

-> http://www.zookoda.com
-> http://www.basicthinking.de/...fuer-weblogs-zookodacom/

an interesting part I of a series of 4 articles on scaling eins.de, which is powered by RubyOnRails:
-> the adventures of scaling

1. The old codebase roughly consisted of around 50.000 lines of PHP code (plus a closed-source CMS that’s not included in this calculation). We’ve rewritten most of it (some features were left out on purpose) in about 5.000 lines of Rails code.

2. eins.de serves about 1.2 million dynamic page impressions on a good day.

3. The (4) application servers are dual Xeon 3.06GHz, 2GB RAM, SCSI U320 HDDs RAID-1. The (2) database servers are dual Xeon 3.06GHz, 4GB RAM, SCSI U320 HDDs RAID-1. The proxy server is a single P4 3.0GHz, 2GB RAM, SCSI U320 HDDs RAID-1.

4. At peak times about 20Mbit/s leave the proxy server’s ethernet interface.

I'm seriously impressed by these traffic-numbers, and also by the refactoring. Congrats to eins.de!

---

In order to make a comparison with Helma's performance I will provide the according numbers for twoday.net:

1. The codebase consists of 18.000 lines of JS-code (ongoing refactoring brought it currently down to 12.000 lines; hopefully this number will decline some more).

2. On a "good" day twoday.net serves about 400.000 (true) PIs, together with 150.000 RSS-requests and the (also dynamicly served) css- and js-files we have 1.6 million dynamic requests per day, which are handled by Helma.

3. 1 application server, that is a dual Xeon 2.8GHz, 2GB RAM, and 1 database server, a dual Xeon 3.06GHz, 2GB RAM. Additionally there is now a third server for serving the static content.

4. Since twoday.net consists mostly of textual content, our throughput never exceeds 1 5 MBit/s.

Currently we haven't reached our limit with this hardware setup. (As a side-note: The troubles we experienced over the last two months were related to some nightly cronjob-activities, like logfile splitting and generating statistics.) The maximum system-load of the web-server is 5, and of the db-server 6 (and for the static-server 0.2 :-)).

I know that each web-application has its own characteristics, and that it is simplistic to compare these numbers without taking a closer look at the applications themselves. Still i wanted to make a clear statement that Helma's performance is absolutely amazing! We here at knallgrau can concentrate on the implementation of new functionality, without having to worry about performance/caching at all [as long as we follow my five golden rules :-)]. It makes the development so much more fun, and saves us lots of time.

My five golden rules for Helma developers

• Cover each and every collection with a database index.
• Stay away from large JavaScript arrays (use Java-Sets or -Hashtables for such purposes)
• Stay away from massive string concatenations, esp. '+=' seems to perform poorly
• Stay away from looping through collections, just to apply some filtering or sorting. Try to use distinct collections instead.
• Keep the read/write ratio for sql-operations high. I.e. writing sthg to the database for each request, is a very bad idea. If really necessary, then try to do the update/inserts in bulk (like in twoday).

So, and that is actually my version of my 4-series article on performance tuning a Helma application :-)