was [performance (again)] -> concurrent access?

[Eugeny N Dzhurinsky <eu...@jdevelop.com>]

On Fri, Oct 14, 2005 at 02:49:09PM +0200, Stefan Guggisberg wrote:
> > > because i am using a windows box i modified repository.xml to
> > > use CQFileSystem instead of LocalFileSystem for the default
> > > workspace.
> > > here's the results when i ran it on my machine (with -Xmx128):
> > > Build 19530 in 796453 ms
> > > Traverse 19530 in 36219 ms
> > > node  found in 0 ms
> > > i.e.
> > > - 19'530 nodes
> > > - 410'130 properties with 195'300 being BINARY!
> > > - 429'660 items on total
> > > - 1.8ms per item
> > > - 40ms per node
> > > i guess that's not too bad.

my results are:
build  19350 nodes in 519220 ms
random access : 453 ms
search by property: 453 ms

Now the question is how several users can have concurrent access to repository
for reading and writing operations?

-- 
Eugene N Dzhurinsky

Re: was [performance (again)] -> concurrent access?

[Marcel Reutegger <ma...@gmx.net>]

David Nuescheler wrote:
> 
>>random access : 453 ms
>>search by property: 453 ms
> 
> can you describe what you mean by "random access"? is that accessing
> a node by path or by uuid? or something different.
> is it just coincidence that search by property takes exactly the same
> amount of time as the "random" access?
> if you say "search by property" how many entries do you have in
> your search result?
> 
> i would say that 453 ms would be too slow for a search with few results
> and is certainly way too slow for a single access of an item by
> path or uuid.

the first query may be slower because caches have to be populated, 
subsequent queries will be much faster. If I remember correctly the test 
only executes one single query.

regards
  marcel

Re: was [performance (again)] -> concurrent access?

[Eugeny N Dzhurinsky <eu...@jdevelop.com>]

On Wed, Oct 19, 2005 at 11:53:34AM +0200, David Nuescheler wrote:
> > random access : 453 ms
> > search by property: 453 ms
> can you describe what you mean by "random access"? is that accessing
> a node by path or by uuid? or something different.

it's just access to node by path.

> is it just coincidence that search by property takes exactly the same
> amount of time as the "random" access?

I tried several times, it seems that equal times in results I posted is just
coincidence, right. Uusually it differs in ~100 ms

> if you say "search by property" how many entries do you have in
> your search result?

20 or so, can't recall right now.

> > Now the question is how several users can have concurrent access to
> > repository for reading and writing operations?
> every user operates on their own session, is their any further
> information that you need? maybe i misunderstand your question, it
> seems pretty obvious to me...

Okay, in another words, if several users will work with the same repository
and userA will edit siblingA in nodeA, but user B at the same time will edit
siblingB in the same node (nodeA) - will this situation be handled properly if
they will try to save results at the same time?

-- 
Eugene N Dzhurinsky

Re: was [performance (again)] -> concurrent access?

[David Nuescheler <da...@gmail.com>]

hi eugene,

> random access : 453 ms
> search by property: 453 ms
can you describe what you mean by "random access"? is that accessing
a node by path or by uuid? or something different.
is it just coincidence that search by property takes exactly the same
amount of time as the "random" access?
if you say "search by property" how many entries do you have in
your search result?

i would say that 453 ms would be too slow for a search with few results
and is certainly way too slow for a single access of an item by
path or uuid.

> Now the question is how several users can have concurrent access to
> repository for reading and writing operations?
every user operates on their own session, is their any further
information that you need? maybe i misunderstand your question, it
seems pretty obvious to me...

regards,
david