Thought people would be interested in this. It provides some proof that
a RAM disk isn't as great a benefit as some might have thought. It
certainly isn't as clear-cut as the Amiga days when the only other
storage was a 800K floppy disk.
PS. did I forget to say we're hiring? Apache/PHP/web stuff!
-------- Original Message --------
Subject: Re: [Mod_gzip] How to use a Linux RAMDISK for temp files
Date: Fri, 2 Mar 2001 19:13:46 -0600
From: "Kevin Kiley" <Kiley at RemoteCommunications.com>
Reply-To: mod_gzip at lists.over.net
To: <mod_gzip at lists.over.net>
I will bet you are right. Linux is optimized for file I/O, anyway,
so going to disk really isn't that big of a deal. If it was... then
people wouldn't be using Linux for Web Servers.
I also take back what I said about HUGE speed improvement
if compression is happening completely in memory.
If Linux is so optimized that accessing files in RAM is the
equivalent of accessing them on disk then maybe ( under Linux )
there's no need to ever have an 'in memory' compression option.
Perhaps it really won't show that big of an improvement under Linux.
It certainly does for Win32.
I hope this doesn't come as a shock to you but mod_gzip was
developed completely under Win32 and all preliminary testing
was done on that platform. It was only ported to UNIX when it
was already kicking ass under Windows.
mod_gzip actually might be the first Apache module that can
make that claim.
( Born/grew up under Windows and only later moved to UNIX ).
From: David Rees <drees at ebetinc.com>
To: mod_gzip at lists.over.net <mod_gzip at lists.over.net>
Date: Friday, March 02, 2001 4:30 PM
Subject: RE: [Mod_gzip] How to use a Linux RAMDISK for temp files
>> Kevin here...
>>>> When using the Win32 version with a RAMDISK the speed
>> is bascially equivalent to same speed seen when the 'in-memory'
>> option is used and everything is happening in memory.
>>>> Win32 machines can truly access files in RAMDISKS as if
>> they were pure memory buffers. I think the low-level IO routines
>> switch into pure pointer copies when it knows it's in memory
>> just the way mod_gzip LZ77 + Huffman compression code can.
>>>> I am with you on Linux RAMDISK. I have no idea why/how using
>> a RAMDISK for file I/O could ever NOT be faster than hitting
>> the disk. Do the Linux SWAP options have anything to do with
>> this? Is the ramdisk data itself getting swapped off to disk so
>> that despite all the setup it's never really in memory anyway?
>>My suspicion is that the Linux kernel IO buffering code is so efficient
>it actually prevents all these small write/read/deletes that mod_gzip
>performs from even seeing the disk! The kernel does write buffering, to
>improve speed, so this must be the case. This was on Linux kernel 2.4.1,
>maybe 2.2.x kernels will show a different as the IO layer in the kernel was
>revamped quite a bit between 2.2.x and 2.4.x.
>mod_gzip mailing list
>mod_gzip at lists.over.net>http://lists.over.net/mailman/listinfo/mod_gzip
mod_gzip mailing list
mod_gzip at lists.over.nethttp://lists.over.net/mailman/listinfo/mod_gzip
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!