Re: unexplained micro-bench results

Virginie Galtier wrote:
> Hi
>
> I’m trying to evaluate JavaSpaces performances running some micro-bench.
>
> Question 1:
> I’ve read messages about people complaining the JavaSpace could not hold
> all of their entries even though the entries were small because the
> overhead introduced by JavaSpace/Jini/RMI is important. What is the
> amount of this overhead exactly? If the Entry I write to a space has
> only an empty non arg constructor and a unique attribute which is an
> array of d doubles, what is the size of the object written to the space?
>

Interesting, I've been involved with this technology since it's initial
release and I've never seen these kinds of messages.  Could you give me
some pointers please?

Having written several JavaSpaces implementations I can assure you that
transport cost and size of entry are directly related but that has
nothing to do with specific overheads of Jini/RMI or JavaSpaces.  One of
the overheads is _Java_ related and it's serialization but there are
ways around this........

The number and size of Entry any given JavaSpace may hold is related to
it's storage implementation.  Some keep everything in memory, some can
swap back and forth to disk.  Thus it's a function of how much memory
and disk you have just as it is for databases.  And if the JavaSpace
does swap back and forth to disk it can in theory hold as many Entry's
as will fit on the disk subject to any index structures it may maintain etc.

Lastly, the size of the object written to the space is dependent upon
many factors including how the JavaSpace is implemented.  Some have a
tool to help with such calculations but IMHO it's pretty irrelevant.
Basically, the amount of disk space/memory taken up storing this
serialized object in a JavaSpace won't be too dis-similar to storing the
serialized form on a disk.  Assuming that you include the necessary
codebase annotations.

> Question 2:
> I’ve run an experiment where I write x entries to a local javaspace,

Is that local as in running remotely on the same machine or do you mean
you're running an embedded space?

> next I read the x entries, and after that I take the x entries. I
> measure the time taken by each of the 3 steps and compute the cost (in
> second) per data-byte (of "useful" information in the entry). I run this
> experiment with different values for x and I don’t understand why the
> bigger x, the smaller the cost per byte. It also looks like the first
> write operation on a "fresh" javaspace takes longer than the other
> operations (I only measure the time taken by the write, not the time
> taken by the lookup). I’m not using snapshot or bulk functionalities, is
> there some kind of caching mechanism which could explain the results I’m
> observing?
>

IMHO, unlikely, I think it's far more likely you are encountering one of
more of the following:

(1)     Hotspot compilation - the first write is going to be un-optimized,
from my own analysis, it takes at least 3 executions of a method before
hotspot has done a reasonable job of compiling the associated call tree.
  Even after that one still sees increment improvements.

(2)     If you are accessing a remote space, the first write likely incurs
the socket connection/setup overhead which is a significant cost.

> I’ve put more details (code, figures, graphs…) at:
> http://www.metz.supelec.fr/metz/personnel/galtier/PagesPerso/Recherche/JavaSpaces/MicroBench/index.html
>

If you haven't read this already, I'd recommend you check out:

http://www.dancres.org/blitzblog/?p=10

http://jroller.com/page/dancres?entry=javaspaces_scaling_and_load_balancing

http://jroller.com/page/dancres?entry=javaspaces_fallacies

http://jroller.com/page/dancres?entry=are_you_leaking_memory

Hope that helps,

Dan.

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html