2009/6/14 Olaf Schmidt <s...@online.de>:
> Interesting approach - (such a mem-vfs offers some nice
> options at the serverside, once it is done).
>
> Did you already tested, how the whole approach behaves
> in concurrency-scenarios with e.g. only 4-8 concurrent clients?
> Using your schema, especially the concurrent writes should get
> a nice boost.
>
> I imagine a simple script, which is executed by each client-
> process and could fill-up a fresh DB to a certain amount of
> records in a single table maybe (to keep the test-scenario simple).
>
> Each client could do (with a 1:10 relation of writes and reads)
>
> Loop 1000 times
> With LoopCounter Modulo 7 (case-switch)
> case 0: Insert one single record
> case 1: Insert 10 records
> case 2: Insert 100 records
> case 3: Update one single Record
> case 4: Update 10 affected Records
> case 5: Update 100 affected Record
> case 6: Delete one single Record
> End of WritePart
>
> Followed by 10 different Read-Jobs,
> each requesting a completely delivered
> resultset, based on different where-clauses, etc.
> reporting only the recordcount to the console or
> into a file, together with the current timing
>
> (maybe fill up two different tables - and also include
> some Joins for the read-direction-jobs)
> End loop
>
Did you mean to do this test for one user?
The request info:
{
"method" : "execute",
"params" : [
{
"dbfile" : 0,
"user" : "foobar",
"dbname" : "addrbook",
"sql" : [
"insert into addrbook values ( 1,
\"f...@bar.com\" )",
"select * from addrbook"
]
}
],
"id" : "foobar"
}
The server will lock the user ( foobar ) while processing this request.
If the server receives two requests for one user at the same time,
it will process this two requests serial.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
