[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [GNUnet-developers] Databases benchmark and problem

From: eric haumant
Subject: RE: [GNUnet-developers] Databases benchmark and problem
Date: Wed, 16 Apr 2003 16:01:57 +0200

I've looked at the BDB documentation pages. 

The space used is due to the type of database (here HASH). In fact, BDB
allocates the power-of-two-higher number of entries to support other
database types. That's probably why BDB uses so much space. I can't find any
function that can disable this or any function that could be interresting to
retrieve space.

About the performance functions. We can specified a page fill factor
(because all entry uses the same space). We can also add a better hash
function (I don't think this can be helpfull). We can also specified the
size of the database (we know that with the DISKQUOTA).

I'll try to hack the bdb code to see the difference asap.


-----Message d'origine-----
De : Kevin Atkinson [mailto:address@hidden
Envoye : mercredi 16 avril 2003 14:37
A : eric haumant
Cc : 'address@hidden'
Objet : Re: [GNUnet-developers] Databases benchmark and problem

On Tue, 15 Apr 2003, eric haumant wrote:

> Hello,
> I've just made some tests with the five database types of GNUnet. This
> results have been made with a 100Mo file (with random content) that have
> been inserted in the database. Here is the results :
> - MySQL : 
>    Upload Speed : 400 ko/s
>    Download Speed : 300 ko/s
>    Space used : 113 Mo.
> - GDBM : 
>    Upload Speed : 500 ko/s
>    Download Speed : 400 ko/s
>    Space used : 148 Mo.
> - TDB : 
>    Upload Speed : 27 ko/s
>    Download Speed : 12 ko/s
>    Space used : 118 Mo.
> - BDB : 
>    Upload Speed : 340 ko/s
>    Download Speed : 260 ko/s
>    Space used : 435 Mo (DISKQUOTA=300 !!).

BDB has a lot of tunable parameters.  You might get better performance and
space usage by reading over the performance parts of and perhaps adjusting some of
them.  I don't see any reason why BDB should be far worse than GDBM once 
tuned properly.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]