On Wed, 1999-09-22 16:22:54 -0400, James Manning wrote:
> [ Wednesday, September 22, 1999 ] Martin Ramsch wrote:
> > On Tue, 1999-09-21 21:16:55 +0200, Jimmy Posius wrote:
> > > 1) each merchant gets his own (mysql) database. Thisway 500-2500 (or
> > > more) databases will be created on a Linux system,
> > >
> > > 2) create ONE big database and tabelnames get a prefix
> > > This way there's 1 database with a lot of small tables (> 1000-5000).
> > Speed.
> > Having that many tables (5000) in case 2 could be slow because the
> > operating system might become slow when scanning the database
> > directory with so many files (5000 x 3 = 15000).
> > In this respect, solution 1 is much better.
> I don't quite get this paragraph... in both 1 and 2, there's going
> to be thousands of files... in 2 they're all in the same dir, in 1
> they're scatter among dirs...
If there are 3 tables per merchant only, it's
5000 directory entries each holding 9 files (in case 1)
45000 files (in case 2) in only one directory.
The more tables per merchant there are the more interesting this
difference will become.
> I'd like #2 since we're infinitely more likely to keep the dcache of
> the kernel well-populated, and our worst-case appears to the open()
> on a infrequently-accessed table. #1 would appear to force
> often-cold dcache entries to be accessed, adding delay to table
> access... could be lost in the noise... check it out with
> benchmark() :)
I have to admit, that I haven't done test cases with so many files ...
How much is the speed penalty for scanning directories with 45000
entries and more versus the caching issue? I don't know.
Martin Ramsch <m.ramsch@stripped> <URL: http://home.pages.de/~ramsch/ >
PGP KeyID=0xE8EF4F75 FiPr=52 44 5E F3 B0 B1 38 26 E4 EC 80 58 7B 31 3A D7