I recently read this article about tuning Ext3 file system for better performance. I was doing a fresh Ubuntu 7.10 install on my laptop, so I decided to see how much this would affect to my every day Plone development.

On Linux, every time a file is read, its access time attribute is rewritten. This causes a lot of unnecessary writes to file system. Since there are only few rare application needing this feature, turning of the feature can give a nice performance boost on systems dealing with large amount of files.

Plone 3.0 has 10000 files. A lot of them are read during the start-up. Maybe I am getting somewhere here…

When you are doing Plone development, you need to restart Plone often. I used this highly scientific method to measure Plone start-up time from issuing zopectl fg to getting the front page load completed in Firefox. I warmed the file system cache beforehand by doing two dry runs.

I also did some simple front page bombing with ab tool.

System setup

• HP nx9420 laptop (5400 RPM hard disk)
• Plone 3.0.2/Zope 2.10.4
• Intel Core 2 Duo, 2 Ghz
• Ubuntu 7.10
• Applied following Ext3 options: noatime, data=writeback

Out-of-the-box filesystem

Lap 1: 23s

Lap 2: 22s

Lap 3: 22s

ab stats:

Concurrency Level: 10
Time taken for tests: 11.805239 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 2058700 bytes
HTML transferred: 2030600 bytes
Requests per second: 8.47 [#/sec] (mean)

Tuned file system

Lap 1: 21s

Lap 2: 22s

Lap 3: Didn’t bother to do it…

ab stats:

Concurrency Level: 10
Time taken for tests: 12.102054 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 2058700 bytes
HTML transferred: 2030600 bytes
Requests per second: 8.26 [#/sec] (mean)

Conclusion

“Hooray.”

Though Plone/Zope crawls through of thousands of files during the start up (and thus touches their access times), the slow start-up process seem to be CPU bound. Magic file system tricks won’t make your everyday Plone development more effective.