In a previous life circa 1996, I did some real intensive filesystem performance studies including various commercial Unices (not linux). I know quite a bit about how to do this (I authored the reasonably popular "Bonnie" filesystem benchmark).
Back then, for a mixture of directory traversal / file open / file read operations, NT was a lot faster (on reasonably equivalent hardware) than any commercial Unix we looked at.
In that case, we went and bought the unix boxes anyhow because other factors were more important; I think this would be the case in most web-server apps.
But if you look at the netcraft benchmarks, you see a *lot* of ordinary file opening and reading - in this context it doesn't surprise me that NT does well.
On the other hand, it wold be nice if Linux did better.
... back when we were doing the initial work on wiring XML into perl. I managed to get hysterical storms of laughter out of the audience by flashing up 5 or 6 well-known *nix config files in increasingly ugly and baroque syntax. I forget the details now, but there was inetd.conf and fstab and httpd.conf and so on; all of which have multiple chunks of data encoded in text with a totally arcane ad-hoc set of syntax rules for fishing them out.
XML probably wouldn't actually be as easy to read as inetd.conf or fstab for someone who's used to inetd.conf or fstab, but there are those times when you pull up a conf file that's new to you and wonder what the author was smoking. Lesson - great programmers often design hideous config syntaxes.
The one that totally brought the perl conference house down was fvwm95rc.whatever.m4, I forget the exact name, which has an absolutely hair-raising melange of positional, functional, and from-another-planet syntaxes (and then had to be run through m4 fergosshakes. (why does m4 still exist?)
Anyhow, I think history has shown that a set of textual config files is a better way to run an OS than a set of dialogue boxes or a hierarchical binary 'registry', so it would be kinda nice if there was some common syntax out there. But even speaking as a certified XML bigot, it's hard to see how to get there from here. If I can help, let me know.
You can buy a commodity off-the-shelf intel box with a couple G of RAM for amazingly little. Now, a lot of applications can't fit their data in 2G. But for those that can, in-memory databases produce astounding performance for anyone who's struggled with conventional databases. If you can't fit in 2G, go buy an Alpha or an AIX box or whatever and 8 or 10 G of RAM. If your data doesn't fit in that... read the other threads in this talk.
Note that the optimal data structures for in-memory DBs are really different from those on-disk.
I just finished buying a big hefty server from Dell to run Linux on. They are willing to sell an OS-less box, but they won't preconfigure linux on a single-box order. Sigh.
Slashdot Mirror
In a previous life circa 1996, I did some real intensive filesystem performance studies including various commercial Unices (not linux). I know quite a bit about how to do this (I authored the reasonably popular "Bonnie" filesystem benchmark).
Back then, for a mixture of directory traversal / file open / file read operations, NT was a lot faster (on reasonably equivalent hardware) than any commercial Unix we looked at.
In that case, we went and bought the unix boxes anyhow because other factors were more important; I think this would be the case in most web-server apps.
But if you look at the netcraft benchmarks, you see a *lot* of ordinary file opening and reading - in this context it doesn't surprise me that NT does well.
On the other hand, it wold be nice if Linux did better.
-Tim... back when we were doing the initial work on wiring XML into perl. I managed to get hysterical storms of laughter out of the audience by flashing up 5 or 6 well-known *nix config files in increasingly ugly and baroque syntax. I forget the details now, but there was inetd.conf and fstab and httpd.conf and so on; all of which have multiple chunks of data encoded in text with a totally arcane ad-hoc set of syntax rules for fishing them out.
XML probably wouldn't actually be as easy to read as inetd.conf or fstab for someone who's used to inetd.conf or fstab, but there are those times when you pull up a conf file that's new to you and wonder what the author was smoking. Lesson - great programmers often design hideous config syntaxes.
The one that totally brought the perl conference house down was fvwm95rc.whatever.m4, I forget the exact name, which has an absolutely hair-raising melange of positional, functional, and from-another-planet syntaxes (and then had to be run through m4 fergosshakes. (why does m4 still exist?)
Anyhow, I think history has shown that a set of textual config files is a better way to run an OS than a set of dialogue boxes or a hierarchical binary 'registry', so it would be kinda nice if there was some common syntax out there. But even speaking as a certified XML bigot, it's hard to see how to get there from here. If I can help, let me know.
Cheers, Tim Bray (tbray@textuality.com)You can buy a commodity off-the-shelf intel box with a couple G of RAM for amazingly little. Now, a lot of applications can't fit their data in 2G. But for those that can, in-memory databases produce astounding performance for anyone who's struggled with conventional databases. If you can't fit in 2G, go buy an Alpha or an AIX box or whatever and 8 or 10 G of RAM. If your data doesn't fit in that... read the other threads in this talk.
Note that the optimal data structures for in-memory DBs are really different from those on-disk.
-T.I just finished buying a big hefty server from
Dell to run Linux on. They are willing to sell
an OS-less box, but they won't preconfigure
linux on a single-box order. Sigh.