/by apr/
We have a couple of new modules in jPOS-EE that integrates Q2 with the excellent Java Service Wrapper.
-
Archives
- July 2010
- June 2010
- March 2010
- December 2009
- November 2009
- October 2009
- August 2009
- July 2009
- June 2009
- March 2009
- January 2009
- November 2008
- October 2008
- June 2008
- May 2008
- March 2008
- February 2008
- December 2007
- November 2007
- October 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- January 2007
- December 2006
- September 2006
- August 2006
- July 2006
- June 2006
- April 2006
- March 2006
- February 2006
- January 2006
- October 2005
- September 2005
- August 2005
- June 2005
- May 2005
- April 2005
- March 2005
-
Meta
We are running a jPOS-EE Windows implementation that crossed the 300 TPS threshold last week in some throughput testing conducted by our client. The application is deployed on two quad-processor 2.7 GHz Xeon servers (manufacturer: IBM) each with 2 GB of memory and running Windows Advanced Server 2003.
On one server, jPOS-EE is running smoothly as a Windows service. It listens to our client’s 3,500 stores via a TCP/IP connection. On the other server, we are running a copy of MS SQL Server (our client’s enterprise DB of choice). jPOS-EE makes calls to SQL Server through the jTDS driver.
The transaction mix in the throughput test was all internal (i.e., nothing switched out for faux-authorization) because these are the most resource consumptive varieties. For each transaction, our application validates store, terminal, card and cardholder on respective SQL Server tables and updates a tran log with a result. Througput the test, the new jPOS-EE Web interface was available to get real-time feedback on the test’s progress (this impressed our client a great deal).
We suspect throughput would be higher if the transaction mix consisted of switched-out transactions like goods purchases initiated with a Debit card.
By the way, some comments on the jTDS driver – we ran some traces on SQL Server and from that perspective it’s impressive to watch the way jTDS optimizes performance – it sets up a number of temporary procedures and then makes use of them resulting in very little CPU expenditure. HOWEVER, its critical that when using jTDS in conjunction with SQL Server, you take heed of the following variable:
sendStringParametersAsUnicode (default – true)
Determines whether string parameters are sent to the SQL Server database in Unicode or in the default character encoding of the database. This seriously affects SQL Server 2000 performance since it does not automatically cast the types (as 7.0 does), meaning that if a index column is Unicode and the string is submitted using the default character encoding (or the other way around) SQLServer will perform an index scan instead of an index seek.
See – http://jtds.sourceforge.net/faq.html
You MUST have this variable set to FALSE. Without it, SQL Server performance goes to Absolute Hell. On our quad-processor box, we moved CPU needles straight to 100% for the duration of the test and performance was 10-fold worse than our ultimate results (this is the reason we had the SQL Server traces on to begin with).