Perl and a Ramdisk

[Bill H]

I am working on a chat program and am thinking of using a ramdisk to
hold the chat data. Is there anything special I should know about
accessing ramdisk from perl or is it just another disk to perl? On my
development machine I don't have a ramdisk, so I will be using the HD
for storing while debuging, but on the machine it will run on there is
one, and it would be nice if I could just have a variable holding the
destination and only have to change that instead of changing any
routines that did any file i/o.

Bill H

 

[smallpond]

I am working on a chat program and am thinking of using a ramdisk to
hold the chat data. Is there anything special I should know about
accessing ramdisk from perl or is it just another disk to perl? On my
development machine I don't have a ramdisk, so I will be using the HD
for storing while debuging, but on the machine it will run on there is
one, and it would be nice if I could just have a variable holding the
destination and only have to change that instead of changing any
routines that did any file i/o.

Bill H

"Premature optimization is the root of all evil."
-- C. A. R. Hoare

Your plan is good right up to the part where you actually
switch over to using the ramdisk. Every modern OS already
has excellent code to do secure and reliable caching of disk
data. I would see if the disk access is actually a problem
before changing, which should be just the filename that you
open or a symbolic link.

If you do create a ramdisk, you will need to create a
filesystem in it, unless you plan on using the raw disk.
You will also have to preload it and worry about saving
it on shutdown if it will contain any permanent data.
--S

 

[Bill H]

"Premature optimization is the root of all evil."
-- C. A. R. Hoare

Your plan is good right up to the part where you actually
switch over to using the ramdisk. Every modern OS already
has excellent code to do secure and reliable caching of disk
data. I would see if the disk access is actually a problem
before changing, which should be just the filename that you
open or a symbolic link.

If you do create a ramdisk, you will need to create a
filesystem in it, unless you plan on using the raw disk.
You will also have to preload it and worry about saving
it on shutdown if it will contain any permanent data.
--S

I am not concerned about loosing the data with shutdown, since it is
chat the data is transient, only need what someone types for a few
seconds to echo it to the other chatters. I am more concerned with
speed and less disk accesses. I figure it will be a whole lot faster
open a file, reading, writing, closing files in a ramdisk than in on a
HD.

Bill H

 

[Ben Morrow]

I agree, before using a RAMDISK, why not see if using a files on a disk is a
problem? You have created a solution in search of a problem and definitely
putting the cart before the horse. Creating, opening, reading and writing
small files on a RAMDISK is not going to be that much faster than using a
real disk because the amount of data you are reading and writing is small.
Any modern OS is going to cache the data anyway, so in effect you are
already reading and writing to a RAMDISK.

Since we are talking about files that change often, every byte written
will have to get flushed to disk at some point. If there is a real disk
involved that means lots of IO, however clever the kernel caching is.

If your program does run slow, using a RAMDISK will not increase
performance dramatically because every process will need to open, read
and then close the file. A better solution would be to use shared
memory, which is very efficient, and much faster than using files to
store temporary data needed by multiple processes. There are several
CPAN modules that implement shared memory.

At least Linux implements both SysV and POSIX shared memory as mmaped
files from a ramdisk. (The ramdisk used for SysV shm is private to the
kernel and doesn't need mounting in userspace, but it is effectively a
mount of tmpfs.)

Ben

 

[Martijn Lievaart]

Since we are talking about files that change often, every byte written
will have to get flushed to disk at some point. If there is a real disk
involved that means lots of IO, however clever the kernel caching is.

Try it. Yes, a ramdisk may be faster, but by how much? Modern OSses are
so intelligent in handling disk I/O I doubt you'll see any difference in
practice.

And yes, I'm talking experience here. Under MSDOS, yes, a well placed
ramdisk made all the difference. Switching to NT and Linux anything I
assigned to a ramdisk became unavailable to the system for diskcaching,
making overall performance a lot worse. But given enough memory disk
caching is so efficient a ramdisk is not noticeably more efficient than a
temporary file on disk.

Also, I've seen a lot of big iron. I've managed a web server and ftp
server that on a certain day every year are the most visited Internet
servers in the Netherlands. Not the same use case but we managed a lot of
servers there. Not one used a ramdisk, just because there was no
performance to be gained. Just let the OS sort it out, monitor it, and
when it runs out of memory, add more memory.

By all means try it. I'll be very surprised if a ramdisk gives you any
real performance benefits.

HTH,
M4