Re: [PHP] A no brainer...

# edlazor@xxxxxxxxx / 2006-10-15 16:54:29 -0700:

On Oct 15, 2006, at 3:27 PM, Tony Di Croce wrote:

Wow... well, I was certainly not speaking from direct experience,
only from what seemed to make sense to me. This tells me that their
is some serious room for improvement in PHP de-serialization code...

Well, kinda. Hard disks are a lot slower than ram and that gives
file storage a disadvantage. You can setup disk caching to help, but
the OS still starts to lag when you have a lot of files in one
directory, which is what happens with session data files.

Modern filesystems cope well with large directories (plus it's quite
trivial to derive a directory hierarchy from the filenames).
Looking at the numbers produced by timing various operations in
a directory with exactly 100,000 files on sw RAID 1 (2 SATA disks)
in my desktop i'd say this concern is completely baseless.

MySQL tries to cache data in memory as much as possible.

It cannot (MUST NOT) cache writes.

It still uses files, but hopefully you don't hit them very often,
especially when you're dealing with the same table records.

A RDBMS is basically required to hit the disk with the data on
commit. One of the defining features of a RDBMS, Durability, says
that once you commit, the data is there no matter what. The host OS
may crash right after the commit has been acked, the data must stay.

You can turn on query caching in MySQL, but this will give you
*nothing* for purposes of session storage.

Also, having raw data is always faster than having to process it
before you can use it.

I don't know what that means. Bytes in files on disk are as raw
as it gets, you get one roundtrip process -> kernel -> process;
compare the communication protocol MySQL (or just any other DB) uses
where data is marshalled by the client, and unmarshalled by the
server, overhead of the database process(es) taking part in the
write...

So no, it makes no sense for a database to be faster than
filesystem.

--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
.

Relevant Pages

  • Re: Pysqlite tables in RAM
    ... able to reload the tables into the RAM whenever I have a lot of disk ... accesses and commit the changes back to the database. ...
    (comp.lang.python)
  • Re: EWF - force write
    ... > We are talking here about RAM EWF not DISK overlay, ... > Live commit option is not possible to implement on running OS partition. ... I don't think this would be hard to avoid such problems since read/write disk operations are redirected to one code - EWF. ... > Live RAM EWF commit would be possible only on non OS partitions if you can unmount safely file system. ...
    (microsoft.public.windowsxp.embedded)
  • [PATCH] improve jbd fsync batching
    ... There is a flaw with the way jbd handles fsync batching. ... sleep for 1 jiffie in order to wait for new writers to join into the transaction ... before forcing the commit. ... storage the time it takes to commit a transaction to disk is way ...
    (Linux-Kernel)
  • Re: EvfMgr C: -commit followed by Power Down gives lost changes
    ... directly after commit. ... someone turning power off). ... > EWF is between disk driver and filesystem driver. ...
    (microsoft.public.windowsxp.embedded)
  • Re: Pysqlite tables in RAM
    ... able to reload the tables into the RAM whenever I have a lot of disk ... accesses and commit the changes back to the database. ...
    (comp.lang.python)