Dirk Meyer wrote: > Hi > > I did some testing with a vfs based on a sqlite db and kaa.ipc. The > first one is ok, the second one makes trouble.
And a second test.
> To test if the overhead is more or less constant, I did some
> testings on a larger directory with 700 files.
[...]
> The result is _very_ bad. It takes 2 seconds (!!!) to send the data.
Similar results I can't explain. Most of the time, the whole operation
takes 0.19 seconds, but sometimes it takes 2 seconds. I can't explain
this. And, 0.19 seconds is also too much. The db query itself took
0.08 seconds, this is an overhead of 100ms.
Now to the other idea: read in a thread and use a thread for reading
and writng in the server. Use ipc only to add a query to be
monitored. And back to my smaller directory. Here the old mail:
> The old mediadb code needs 0.09 seconds for the whole
> operation. This includes reading the pickle file, checking the
> directory and the overlay directory for updates and checking all
> files for updates. One the same dir with an up-to-date db the db
> query took 0.05 seconds, the query + checking for new files took
> 0.008 seconds. Checking the files for updates is now a background
> task and overlay directory is not supported yet, but I guess the new
> code isn't much slower than the old one.
Reading in a thread in the client and adding the query to the server
(without waiting for a response) takes 0.045 seconds. So it is more or
less only the db time we need to consider which looks great.
Now we have a new problem: the server doesn't 'commit' all the time,
it is slow to do so after each add_object. And the server can read
between add_object and commit. But the client can't (db locked). So I
guess we need some sort of internal buffer to store the commits we
want to make.
Dischi
--
panic("CPU too expensive - making holiday in the ANDES!");
2.2.16 /usr/src/linux/arch/mips/kernel/traps.c
pgpnAIH4KJ8zN.pgp
Description: PGP signature
