We are running a TPC-C benchmark against a PostgreSQL 9.2 server using JdbcRunner-1.2 implementation. During first few tests we were not getting a smooth (that is, without sudden spikes down to almost 0 from 300 that we got at times) TPS graph even in supposedly steady state. During these tests we had not specified the sleeptimes for transactions (there are different sleep times recommended for different transaction types). So, by default all agents (for example, 100) continuously ran a mix of five transaction types without any sleeps in between. Later, we found out that we could in fact specify the sleep times; and when we did we could see a smoother graph without much variations.

So, the question is, if not specifying the sleep could be the real reason behind the bad results in first few tests?

  • Can you post a link to the TPC-C benchmark tool?
    – user1822
    Apr 22, 2013 at 11:45

2 Answers 2


Apologies for the late response to this, but there is a key reason as to why you are not observing an expected smooth behavior: You have a client-server model violation when you eliminate think time.

The client server model is built upon a foundation that not all user are using system resources at the same time. This is different than the mainframe model with terminals where all users are being serviced at the same time by the core host. With client-server distributed processing exists and there is a delay between requests during which the resources are free'd to service the needs of other inbound users. Normally when you place a host under load with think time these free internals tend to become smaller and smaller and as load increases you eventually reach a tipping point of no free resources to service requests.

By eliminating the think time you eliminate the free resource window to service additional requests and your tests become invalid as a predictor in real world performance. If you ever hear a performance tester tell you that they have eliminated think time and every one user is equal to n real world users, fire them on the spot.


yes. As jdbcrunner creates thread for each client and throws query on database for execution. Thread can gives many heavy queries at a time so to have some duration after each query get execute we need to specify sleep time for performance test.

  • This doesn't explain why the sleeps are there like @JamesPulley's answer does. Jun 7, 2014 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.