jPOS Runs Your Peaks

July 3rd brought another surge in pre-holiday buying at our flagship OLS.Switch client location.  We hit 1,087,254 transactions, supporting US residents from coast to coast in efforts to stock up on goods for their Independence Day BBQ.  Granted, these US festivities pale in comparison to the Uruguayan BBQ, the world’s league table leader.  But we get by.  And OLS.Switch is there to serve, fueled by the underpinnings of the super-efficient jPOS payment processing framework.  I think this was the 2nd highest day.  December 24, 2007 still holds the trophy, and probably will until the same day later this year. 

Some guy asked us the other day about our “scaling strategy.”  My straight answer was: 

First, two moderate sized servers (one application, one DB) will easily support millions of transaction a day, or > 300 TPS in our tests. [NOTE: These results may vary depending upon speed and capacity of external authorizers.] However, in our configuration we use additional machines for achieving high availability levels. We use also load balancer technology to allow us to replicate and extend application server capacity; on the database side, we use clustering. We also have the ability to split processing and provide multiple instances of the environment.

My flip answer is that we do more than a million transactions a day on $28,000 worth of core server technology…purchased over two years ago, mind you, so less than $14,000 for the same firepower today.  We never average more than 25% CPU on the application servers, and less than 5% on the primary DB (in the virtual cluster) machine.  This is one of the country’s biggest retailers.  So, for the majority of acquirers out there, scalability concerns are simply not on the table.    Find other things to worry about.  My blog shows there’s plenty else to weigh on your mind.

My one caveat is the Good Switch, Bad Switch warning:  You do have it in your power as a manager to assemble a crappy, ill-suited team.   In which case, jPOS is no magic elixir.  We know of software vendors who implemented solutions where the client found out later – much to their shock – that it was incapable of doing more than one transaction at a time.  We know because we took the panicky phone call from the manager looking for a bailout.