I have a couple of pure assembly routines that are called by users through forms in HTML documents, one receives 32 bytes (through HTTP) and the other receives 96 bytes (through HTTPS) of useful info that will have to be written (appended) to disk.
These routines are written for speed. The computer that will receive the data has yet to be built probably using SATA drives in a RAID environment using a dual cpu machine and ADSL2 at the beginning and DEBIAN or GENTOO as the OS.

Questions
========
1) Has anyone any idea how fast the buffers on drives currently available can receive data? This is ignoring the actual "commit" which, of course, is slow.
2) Is there an advantage in selecting drives with the largest buffer? (The last I read was buffers of 2M or 8M)
3) How would MMAP (syscall 90) fit and help in my scenario?
4) Should I use a combination of the above options?
5) Any other considerations?

Thank you very much for any help or hint that you can provide.

32 and 96 bytes is really small, do you really expect enough of those requests to tax a modern drive?

Thanks to noth.
Probably not. It's just that I don't like to proceed in the dark and I like to have a complete picture.

I understand but I think you're over engineering the problem =) Hell, IMO using assembly, especially from a web page, is a huge amount of overkill. Generally C will form just as well and be a lot easier to maintain and is considerably more portable.

But in addition to the drive cache there's also the Linux page cache, so with 8M of per-disk cache and a page cache that will dynamically resize to fit inside almost all of the free memory on the box I doubt you'll have any disk I/O problems.

And the performance of the PCI bus and memory will come into play, it's hard to gauge those without just testing the hardware though.

And the RAID level will affect speed. RAID 5 is going to cost you some performance because every write will have parity calculated and written. RAID 1 shouldn't cost you any noticable performance since there's no calculations to be done. RAID 0 is generally regarded as the fastest, but since you're concerned with write performance and not read, I wouldn't even consider using this in a 0+1 or 1+0 setup.

And I doubt mmap will be of any use to you, since you're processing requests from a web form each write will be issued from a new process. And doing a new mmap, pointer calculations, etc would be a decent amount of extra complexity compared to open, seek, write, close and I would be surprised if there was any performance gain from it.

You might also want to consider ditching the asm routines and using something like php or mod_perl, they might actually be faster because they're compiled when the web server starts and they stay resident in memory, your asm routines are most likely being called from some CGI which requires a new process be forked on each invocation.

Thanks to noth.
I tried C and PHP (which I had to learn), stalled after 6 months and when I found I couldn't keep going like this, I caught up with assembly in a few weeks. Portability is something we do not want, this is for a NFP organization.

I was planning to use RAID 1.
As a Debian user, would you have any consideration of which I should be aware?
Your information is very enlightening.

I would think a non-profit organization (assuming that's what NFP stands for) would care about portability because then you can use it on whatever hardware you can get your hands on.

I can't think of anything special about RAID1, I think you can even use it for the root filesystem with LILO without any issues. I have a RAID1 array here setup between partitions on two disks using XFS on sparc64 and haven't had a single problem, mine's only for /var though.

Thank you Noth. It is a non-profit but we have to restrict portability.

You could use ramdisk. It is by far faster than any hard drive or RAID array. The data throughput of RAM is in gigabytes instead of a few tens of megabytes. Also the accessing time of RAM is a few nanoseconds instead of tens of milliseconds. The downside of using RAM is data is cleared after a reboot or powered down. You can look into E-disk or solidstate disks. Flash should not be used because it has limited writes. FRAM can be used because it has unlimited writes and instantous but it will cost a lot and consume a lot of power to reach sufficient storage.

The cache on the hard drive will be used when it is stand alone. If the hard drive is connected in the RAID array, the cache on the hard drive becomes useless. The cache on the RAID controller will be used instead. Cache is used when reading. Sometimes it is used when writing. If you use XFS, it will use its own cache.

Make sure you put cooling devices on each hard drive or else the hard drives will fail sooner than you think.

Thank you Electro. Your info is most welcome. I am going to use XFS, an Escalade raid controller for raid 1 and probably ramdisk to store the routines. The computer is going to have a lot of memory (16G), so your comments are very timely.

A lot of IDE disks ignore the commands to disable their onboard cache (it's a cheap trick to get better performance numbers), so even if the RAID controller attempts to disable it in favor of it's own cache both will be in use. The reason this is important is that if the power fails and there is data in the drive's cache it'll be lost even though the OS and RAID controller thought it was on disk. And since a lot of SATA disks are just normal ATA disks with a serial adapter on them, it's something you should think about.

But if you're going to spend the money on 16G of memory, I'm sure you can afford a $100 UPS.

I agree that there is simply no reason to use assembly, or even complicated techniques of any kind. Why? Because the data is coming in from HTTP! And it's going to disk! In other words, this operation is strictly "I/O bound," dependent upon the speed of I/O operations not the CPU. The programming can be positively wasteful and it will still work just as well.

As soon as your routine does its disk-write, the data is going to be assembled into a buffer and written to disk. Your process need not, and should not, be delayed while this is happening: as soon as it has posted the request, the actual completion of the physical write will be asynchronous. Furthermore, if several successive writes occur in very quick succession (as they probably will), Linux will automatically lump all of them into just one physical disk-write. All of this is happening automagically.

So make it easy on yourself. Your efforts to "make it faster" are misguided in this case.

I am very grateful for all your advices which make plenty of sense to me. I have to stick to assembly because, as explained above, it's the only language I can use without wasting time in learning. I realize that the time I spent "optimizing" these routines is wasted but this is nothing compared to the time I spent learning other languages and failing in their use.

Thank you all.