Skip to content
GigaSpaces Logo GigaSpaces Logo
  • Products
    • InsightEdge Portfolio
      • Smart Cache
      • Smart ODS
      • Smart Augmented Transactions
    • GigaSpaces Cloud
  • Roles
    • Architects
    • CXOs
    • Product Teams
  • Solutions
    • Industry Solutions
      • Financial Services
      • Insurance
      • Retail and eCommerce
      • Telecommunications
      • Transportations
    • Technical Solutions
      • Operational BI
      • Mainframe & AS/400 Modernization
      • In Memory Data Grid
      • Transactional and Analytical Processing (HTAP)
      • Hybrid Cloud Data Fabric
      • Multi-Tiered Storage
      • Kubernetes Deployment
      • Streaming Analytics for Stateful Apps
  • Customers
  • Company
    • About GigaSpaces
    • Customers
    • Partners
    • Support & Services
      • University
      • Services
      • Support
    • News
    • Contact Us
    • Careers
  • Resources
    • Webinars
    • Blog
    • Demos
    • Solution Briefs & Whitepapers
    • Case Studies
    • Benchmarks
    • ROI Calculators
    • Analyst Reports
    • eBooks
    • Technical Documentation
  • Contact Us
  • Try Free

Write Latency Benchmark

Subscribe to our blog!

Subscribe for Updates
Close
Back

Write Latency Benchmark

Shay Hassidim September 26, 2008
3 minutes read

This post will focus on the Write latency benchmark.

This benchmark is relevant mostly for trading applications that are required to submit a request into the backend system as fast as they can. The goal of this benchmark is to understand how much time it takes for a single write operation done by a single remote client to be completed over a fast LAN. This measurement does not necessarily mean how many write operations per second a client may perform (throughput). In fact these are 2 different measurements.

When building such a benchmark you need to take into account the accuracy of the CPU clock measurements, the JVM warm-up time (client and space JVM), the client proxy warm-up time and the space engine warm-up time.
The above means you have to perform some dummy space operations until the client and space JVM reach a “steady state” with their response time before you actually start measuring the response time.

The benchmark was built to measure the write latency with different write speeds (throughput rates). A client was pushing objects into a remote space where a sleep been called after X amount of write operations. This process was simulating throttling and made sure the client will have sustained correct write rate.

Each write operation time was measured by taking the time (in nanosecond unites) before and after the operation, where the best 80% of the results were used to calculate the average time of the write operation.
Here are the results of the benchmark:

The graph below includes results for 2 types of Space domain Classes:
– A Class with 8 fields where 3 of them are indexed (4 String Fields , 2 Long fields, 2 Integer fields). The class did not implemented Externalizable and did not had any special truing or optimization to deuce its footprint or speedup the serialization.
– A Class implements the Externalizable interface with non-implemented writeExternal and readExternal methods – i.e. empty object (acting as a control dummy). Since this is the fastest manner to push data into a remote space, it will allow us to measure the overhead of the object serialization and marshaling when converted from a POJO into a space object.
– The results illustrate 0.29ms latency for a remote write call operation to be completed for a non-replicated space.
– As a comparison – empty object write latency is 0.27ms for non replicated space.
– When the space is sync replicated it adds an overhead of 130%. The 8 fields object write latency is 0.69ms and the empty object write latency is 0.63ms.

The benchmark has been conducted over 1G network with 0.208ms round trip ping latency for 1K object. This means that GigaSpaces overhead on top of the network latency is about 0.1ms. Very impressive!

System Environment:
OS: Sun Solaris 10 x86-64
Architecture: 4 x AMD Opteron Dual-core 8220 2.8Ghz
RAM Size:16GB
Machine Type:Sun Fire X4600
JVM: Sun java version “1.5.0_07”
Interconnect: Gigabit Ethernet
Shay

CATEGORIES

  • Benchmarks
  • GigaSpaces
Shay Hassidim

All Posts (40)

YOU MAY ALSO LIKE

January 9, 2009

Getting ready for the cloud
2 minutes read

October 7, 2008

Closing the gap between multi-core…
2 minutes read

May 25, 2011

GigaSpaces Citrix integration on top…
3 minutes read
  • Copied to clipboard

PRODUCTS, SOLUTIONS & ROLES

  • Products
  • InsightEdge Portfolio
    • Smart Cache
    • Smart ODS
    • Smart Augmented Transactions
    • Compare InsightEdge Products
  • GigaSpaces Cloud
  • Roles
  • Architects
  • CXOs
  • Product Teams
  • Solutions
  • Industry
    • Financial Services
    • Insurance
    • Retail and eCommerce
    • Telecommunications
    • Transportation
  • Technical
    • Operational BI
    • Mainframe & AS/400 Modernization
    • In Memory Data Grid
    • HTAP
    • Hybrid Cloud Data Fabric
    • Multi-Tiered Storage
    • Kubernetes Deployment
    • Streaming Analytics for Stateful Apps

RESOURCES

  • Resource Hub
  • Webinars
  • Blogs
  • Demos
  • Solution Briefs & Whitepapers
  • Case Studies
  • Benchmarks
  • ROI Calculators
  • Analyst Reports
  • eBooks
  • Technical Documentation
  • Featured Case Studies
  • Mainframe Offload with Groupe PSA
  • Digital Transformation with Avanza Bank
  • High Peak Handling with PriceRunner
  • Optimizing Business Communications with Avaya

COMPANY

  • About
  • Customers
  • Management
  • Board Members
  • Investors
  • News
  • Events
  • Careers
  • Contact Us
  • Book A Demo
  • Try GigaSpaces For Free
  • Partners
  • OEM Partners
  • System Integrators
  • Value Added Resellers
  • Technology Partners
  • Support & Services
  • University
  • Services
  • Support
Copyright © GigaSpaces 2021 All rights reserved | Privacy Policy
LinkedInTwitterFacebookYouTube

Contact Us