Skip to main content

jPOS Performance

· 3 min read
Alejandro Revilla
Alejandro Revilla
jPOS project founder

First Data NOC When companies -- specially start-ups -- ask us regarding jPOS performance, they usually tell us they need to support a massive load in the 1000+ TPS range. In order to give some perspective to these requirements, we always exchange some industry information with jPOS power developer Andy whose company manage some jPOS systems reaching 200M transactions per month, and today Andy sent me a very nice link (via OLS' Ron Barker) about one of the largest acquirers in the world, during a really busy day, requiring 988 TPS, the important part: "The record day on Nov. 26 translated to about 988 payment authorizations per second." So I thought it would be nice to start having some stable performance tests here and there in jPOS, so we can have something to measure where we are now, and even if it's really fast for most applications, attempt to improve it. Because many developers use jPOS just to pack and unpack ISO-8583 messages, I thought it would be nice to start by measuring where we are now in the pack/unpack department. I believe there's plenty of room for optimization, but I hope you'll agree that we are in pretty good shape. I've just added a performance test to PackagerTestCase.java to try:

  • 100000 pack operations
  • 100000 unpack operations
  • 100000 pack/unpack operations
  • 100000 update, pack, and unpack operations

and here are the results:

PACK tps=31531, peak=31531, avg=25156.00 [3779.2/3779.2] UNPACK tps=32371, peak=37026, avg=29081.00 [3047.9/6827.2] PACK/UNPACK tps=16605, peak=16634, avg=16144.25 [6254.2/13081.5] UPDATE/PACK/UNPACK tps=10862, peak=10862, avg=10815.16 [10430.9/23512.5] end [23512.6/23512.6]

We are operating with a pretty heavy message, way bigger than a real-life ISO-8583 message:

The last test is the more realistic one, because we tweak the message by changing some fields (i.e. 7,11,12,13), then pack and unpack. In most jPOS applications, we receive a message, change a few fields, and send it back, for instance, a typical server will reply by just changing a few fields (i.e. 39, 38) and eventually resetting a few others. I think there's tremendous room for optimization by caching the binary image of the packed message at the field level, avoiding a re-pack unless the field has changed. Now that we know where we are, I hope to start testing some optimizations soon. You're encourage to do so too. BTW, these figures were taken on an MBP, it would be nice to have some feedback from runs on larger servers.