RSS .92| RSS 2.0| ATOM 0.3
  • Home
  • About
  •  

    GigaSpaces Distributed Transaction Performance

    I’ve done some quick performance testing of GigaSpaces’ distributed transactions using their mahalo implementation.  These are GigaSpaces-only transactions as opposed to transactions involving GigaSpaces and some other persistent store, in which case JTA/XA would be required.

    As a reminder, GigaSpaces considers a transaction to be distributed if it involves more than one primary space partition.  So a transaction that operates on two or more partitions of a partitioned space would be distributed, as would a transaction that operates on two or more different spaces.  A transaction that operates on only one partition of one space is not distributed even if that space is replicated.

    I set my test up as follows:

    • A non-pu client acquires a proxy to a (remote of course) clustered space and writes pojos to that clustered space.
    • The writes are single-threaded, one-at-a-time, and synchronous. (GigaSpaces offers other choices that would undoubtedly be faster).
    • The pojos are routed, so the writes end up going to more than one partition.

    I ran two GSCs on two virtual hosts.  When I ran without backups each GSC managed one partition.  When I ran with backups each GSC managed two partitions.  The primary for each partition ran on adifferent host than the backup when backups were used.

    The client ran on the physical host.

    Ping times on my network run at about .19 ms.

    Each test consists of 10,000 operations of two writes (to primaries) each.  When I ran without backups and without transactions, I got 2,000 operations per second.  Using transactions that dropped to 322 operations per second.

    Working with backups and without transactions,  I got 714 operations per second.  Using transactions that dropped to 208 operations per second.

    These performance figures have little to do with fully optimized GigaSpaces performance.  As I mentioned above, there are faster ways to do these writes than the simple approach I used for these tests.  What the results do indicate, however, is that you can expect to pay a 3x – 6x performance cost for using distributed transactions over independent writes.

    Of course transactions have different characteristics than do independent writes, and those characteristics may justify the performance cost.  As a rule, though, it is clear that distributed transactions should be avoided because of their performance implications unless you have a compelling need for transactional behaviour.

    One Response to “GigaSpaces Distributed Transaction Performance”

    1. Nati Shalom says:

      Note that if you your transaction is scoped for the entire execution then transaction may yeild performance boost as it will batch all updates that are done on the primary and synch them to the backup only when the commit is called.
      This enables you to gain implicit batching.

    Leave a Reply