Re: unexplained micro-bench results

Virginie,



GigaSpaces provide several options that match different requirements when
dealing with low latency and high throughput. Most of them based on our NIO
based communication protocol.



All the following can be found as part of our EE 5.0 beta site:

http://www.gigaspaces.com/downloads_beta.html



- NoWriteLease=true URL option - Does not return the lease object after
write option - improves performance in 20%-30%.



- -Dcom.gs.onewaywrite=true - enable fast network communication with the
space. Does not support transactions.



- Fast notifications using fast network communication.



- Embedded space - this does not involves any remote communication between
the client and the space. Allows running the space within the same memory
address as the application. This together with fast synchronous replication
to another application running an embedded space provide fast P2P
communication channel. We use special replication technique called receiver
acknowledge mode that provide very fast data transfer. You may use also
asynchronous replication in such case to utilize the network bandwidth. In
this case you will have some latency.



The IExternalizableEntry - This provides very fast performance (up to 70K TP
for 1K write into remote space). This allows you to control the
serialization. Does not support transactions.

http://www.gigaspaces.com/5.0_EE_BETA/GigaSpacesEE5.0/docs/JavaDoc/com/j_spa
ces/worker/marshaling/IExternalizableEntry.html



- update , and batch options.



- Different serialization modes:




Serialization Mode

Description


No Serialization (0)

Entry of non native attributes (user defined attributes) including arrays,
except for java.lang.* objects are transferred to and stored at the space
"as is" (not as a java.rmi.MarshalledObject object). When using no
serialization mode, the engine relies on the implementation of hashCode()
and equals() methods when performing matching. You should make sure these
are implemented correctly. In this mode the space JVM needs to have the
Entry's user defined attribute classes as part of its CLASSPATH or the
java.rmi.server.codebase. This mode is optimized for when accessing the
space in embedded mode.



When running in embedded mode entry attributes are passed by reference to
the space. Extra caution should be taken with non native none mutable fields
such as collections (HashTable, Vector). Changes made to those fields
outside the context of the space will impact the value of those fields in
the space and may result in unexpected behavior. For example index lists
would not be maintained since the space is unaware for the modified field
values. For those fields it is recommended to pass a cloned value rather
then the reference itself. Passing a cloned value is important when several
threads access the entry fields - for example application threads and
replication threads.




Light (1)

Entry non native attributes including arrays, except for java.lang.* objects
are transferred to and stored at the space as marshaled objects
com.j_spaces.kernel.lrmi.MarshObject. With this mode there is no need to
implement hashCode() and equals() when performing matching on non native
attributes. In this mode the space JVM does not need to have the Entry's
user defined attribute classes as part of its CLASSPATH. This mode is
optimized for when accessing the space in remote mode.


Full Serialization (2)

Entry non native attributes including arrays, except for java.lang.* objects
are transferred to and stored at the space as marshaled objects (see
java.rmi.MarshalledObject, described in
http://java.sun.com/j2se/1.4.2/docs/api/java/rmi/MarshalledObject.html).
This mode impacts the performance and should be used only when other
serialization modes are not viable.




Compressed (3)

Compressing the entry non native attributes including arrays, except for
java.lang.* objects when before transferred into the space and store the
entry at the space in compressed mode. This option is useful when the entry
includes attributes with a relatively large amount of data such as XML data
(DOM objects). This mode speeds up the access to remote space and reduces
the space memory footprint when dealing with large entries. Compressed
algorithm using the java.util.zip
<http://java.sun.com/j2se/1.3/docs/api/java/util/zip/package-summary.html>
package.





- We provide also open source benchmark code that got the following options:


option

Description


 -clean

 Clean space before benchmark starts


 -url [url]

 Connection url; If none provided the one defined as

 part of the script file will be used




 Operations


option

Description


 -write

 perform first operation as write/put


 -read

 perform second operation as read/get




 -take

 perform second/third operation as take/remove


 -all

 perform all operations - first, second and then third


 -f [FileName]



 dump results into file. Works with -showrate option.

 Default File name is BenchMarkResult<Date>_<Time>.


 -only [first/second]

 enables execution of only first or second operation.




Options


option

Description


 -pause

 pauses once connection with space is established


 -i <number of iterations>

 number of iterations; default is 1000


 -lease [time in ms]

 lease timeout in milliseconds of the write/put operation


 -t [time in ms]



 timeout in milleseconds of the read/take/get/remove

 operations


 -s [size in bytes]

 set byte size of the entry object


 -content

 changes the content value each iteration


 -tr [number of threads]

 number of threads performing each operation


 -rangefirst [from-to]

 will perform first operation with ids/keys between range


 -rangesecond [from-to]

 will perform second operation with ids/keys between

 range


 -wt [repeats]

 repeat times of first operation


 -rt [repeats]

 repeat times of second operation


 -m [batch size]

 specifies the batch size when performing batch

 operations


 -uid

 Uid mode will perform operations by uid of the entry


 -rand <number of iterations>

 will randomize second operation ids/keys in a range;

 default is by -i


 -tx [nth-iteration]

 tx will be committed every nth-iteration; if zero, as

 specified by -i


 -delaywrite [t ms]

 delays first operation every t milliseconds


 -delayreadtake [t ms]

 delays second & third operation every t milliseconds


 -writerate [Max Rate msg/sec]

 will limit the first operation rate (msg in 1 second) for

 all threads


 -notify

 registers for notifications on all events








Topologies


option

Description


-cache

Turn on distributed cache mode


-map



Map API - first/second/third operations as: put, get, remove. can be used
with -cache


-target [space name]



cluster configuration space name to perform second operations on


-parallel



parallel execution of the operations




Statistics


option

Description


-showrate <iteration cycle>



global throughput will be displayed every iteration cycle; default is 1000


-showthreadrate

 <iteration cycle>

thread throughput will be displayed every iteration cycle; default is 100


-stress [repeat times]

runs the entire benchmark as many as 'repeat times' as stated




Examples


option

Description


-url

-url rmi://localhost/container/space protocol://<host>:<port>/<container
name>/<space name>


-only

-only first will perform only write/put operations


-only

-only second will perform only read operations


-only

-only second -take will perform only take operations


-lease

-i 1000 -lease 20000 -only first perform 1st operation with entry lease of 2
sec


-t

-i 1000 -t 20000 -only second perform 2nd operation with timeout of 2 sec


-s



-s 1000 define 1K size entries each


-content

-i 1000 -content -s 1000 defines an entry with a changing content of 1K


-tr

-i 1000 -tr 4 will perform 1000 iterations by each of the 4 threads


-rangefirst

-rangefirst 1000-2000 will write/put ids/keys from 1000 to 2000


-rangesecond

-rangesecond 1000-2000 will read/take/get/remove ids/keys from 1000 to 2000


-wt

 -i 1000 -wt 10 will write/put 10 times 1000 entries


-rt

-i 1000 -rt 10 will read/get or take/remove 10 times 1000 entries


-m

-m 100 -i 1000 will use 10 batches of 100 to perform operations on 1000
entries.


-rand



-i 1000 -rand will randomize second operation ids/keys from 0 to 1000


-rand

 -i 10000 -rand 40000 will randomize between ids/keys in the range of
0-40000


-rand

-rangesecond 10000-25000 -rand will randomize between 10000-25000


-writerate

-i 100000 -writerate 50000 -tr 4

 4 threads will write 100000 entries each with a maximum TP rate of 50000
msg/sec


-notify

 -notify -i 1000 -tr 5 will start 5 threads that will write and notify 1000
entries


-map

 -map -cache -i 1000 -rt 4 will put 1000 entries to local cache, get them
back to the client 4 times using distributed caching mode


-parallel



-parallel -i 1000 -tr 5 will start 5 parallel threads, each performing 1000
operations


-showrate



-showrate 10000 will show TP every 10000 iterations


-showthreadrate



 -showthreadrate 10000 will show each thread-TP every 10000 iterations


-stress

-map -all -stress 10 will run 10 cycles of map api put/get/remove



More Examples:

run -read -i 1000 -s 1000

This will write 1000 entries  into the space, 1K each size, and read them
back into the client.

run -take -i 1000 -s 1000

This will write 1000 entries into the space, 1K each size, and take them
from the space. A remote space will be accessed.

run -read -i 1000 -s 1000 -rt 3



This will write 1000 entries into the space , 1K each size, and read them
back into the client three times.

run -all -i 1000000 -showrate 100000

This will write 1,000,000 entries into the space, take them back and remove
them from the space.

Throughput will be displayed every 100,000 operations.

To view all benchmark options type: run -h.







Best Regards,

        Shay

----------------------------------------------------

Shay Hassidim

Product Manager, GigaSpaces Technologies

Email: [email protected]

Website: www.gigaspaces.com <http://www.gigaspaces.com/>







-----Original Message-----
From: Virginie Galtier [mailto:[email protected]]
Sent: Monday, February 06, 2006 9:53 AM
To: [email protected]
Subject: unexplained micro-bench results



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?



Question 2:

I've run an experiment where I write x entries to a local javaspace,

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?



I've put more details (code, figures, graphs.) at:

http://www.metz.supelec.fr/metz/personnel/galtier/PagesPerso/Recherche/JavaS
paces/MicroBench/index.html



Any hint/help appreciated.



V. Galtier



===========================================================================

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


===========================================================================
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