Re: Apache::AutoIndex - Perl replacment for mod_autoindex



smallpond <smallpond@xxxxxxxx> wrote:
On Apr 24, 8:48 pm, Petyr David <phyn...@xxxxxxxxx> wrote:
On Apr 24, 5:15 pm, "J. Gleixner" <glex_no-s...@xxxxxxxxxxxxxxxxxxxxx>
wrote:

Petyr David wrote:
anyone have an experience using this?

The real question:

does using this speed the creation of a directory index in Apache
significantly? We have directories with thousands of small files.

It's more likely that it'll be slower because mod_autoindex is
written in C and compiled into the Apache daemon, you're not
going to get much faster than that.

Possibly you could list 500 at a time, or something, which
would be faster, however having thousands of files in a directory
isn't typically a good design.

agreed, but the nature of the data forces us to store the files in
this fashion so there's some sense of meaningfulness: every file is
named and then has a sequential number appended to it - there 64K
potential numbers. we might have to start something like breaking it
into 1000 files/directory.

either way - thanks for your opinion

Why not use a real database instead of making one out of a
filesystem?

Why not use a file system rather than making one out of a database?
Admitted, appending a sequential number to the file name is rather strange,
but that still doesn't mean that he really wants a database rather than a
file system.

Directory searches are slow, sequential string
compares.

Not if you already know the exact name of the file. At least, not on any
reasonable file system. They use trees or hashes or something to find the
file quickly.

Database lookups use fast hash techniques.

Same as reasonable file systems, given an exact name. Of course, if you
are doing globs, or just extracting all entries, then neither file systems
nor databases will use fast hash techniques.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
.



Relevant Pages

  • Re: Treads in the new 6 core CPU from Intel
    ... Why do you think six cores are "fighting" for resources? ... implications of an asymmetric I/O bus structure on file system I/O? ... Why do you think the file I/O is not taking advantage of the File System Cache? ... What, in fact, do you mean by the phrase "database ...
    (microsoft.public.vc.mfc)
  • Re: Question regarding to store file system metadata in database
    ... database based file system will be useful for archiving. ... but 300 metadata iops is not that fast. ... feature needed by file system is really a small part of database ...
    (Linux-Kernel)
  • Re: If you were inventing CoBOL...
    ... >> The underlying file system is irrelevant. ... The database would work exactly the same. ... tree nodes lived in a table. ... >Well bang goes the only advantage of lists and trees, ...
    (comp.lang.cobol)
  • Re: Question regarding to store file system metadata in database
    ... database can reside on a raw block device. ... but 300 metadata iops is not that fast. ... database based file system could be a secondary file system but ... feature needed by file system is really a small part of database ...
    (Linux-Kernel)
  • Re: Question regarding to store file system metadata in database
    ... I agree that people always want to access metadata faster. ... Anybody know how fast a file system can do pathname-to-inode ... am just proposing to store pathanem-to-inode number in database. ... For example, one can setup a database to store file pathname, its ...
    (Linux-Kernel)