Tag: java

Max Throughput = # CPUs + 1

Playing around with a simple benchmarking workload.    Its a highly simplified generic order processing workload.   We read a random customer from the customer table then pick between 1 to 10 products for them to order, reading each product from the product table.   Finally we create records in the orders and orders_detail tables.   The workload is generated by a custom java multi threaded app that I wrote.

For this test we have a small number of customers (1000) and products (800) which means our reads are 100% cached in ram.   If they are not in the postgres buffers they will be in the filesystem buffer on this sytem.  Disk is almost never accessed except when postgres needs to flush stuff out to disk.  We have a quad core with 16 GB ram.

IO is not the limiting factor here.  CPU workload is split between the java stuff and the postgres processes.

What we see above is that our max throughput per thread is hit when the number of threads equals the number of processor cores.  However the max system throughput is hit when we have one more java thread/database connection than processors.

I repeated the process cycle a second time to see if the results held.  Overall a slight increase in throughput across the boards but the peaks at # of processors for max per thread, and # of processors plus one for total throughput still held.

One item of note is the consistent large jump when going from 3 to 4 threads.   Its very non linear and as of right now I cannot explain it.


JDBC : getShort returns 0 on NULL

When using JDBC and the integerish data types of short, integer, long etc. be very very careful if you have nullable columns.   A very similar code segment to the following was found yesterday to be replacing nulls with 0’s in the target database.   This is part of a code segment that is reading from one database and inserting into another.

insArchiveOutput.setShort (15, rsOutput.getShort("some_column_name"));

The problem is that the machine numerics seem to consistently return 0 instead of null, requiring you to invoke rs.wasNull() to see if you really were supposed to have a null instead of a 0.   Its works out to be far less elegant than the above line of code, but it doesn’t mangle the data.

I would think this would be better known but this code snipped had slipped past multiple java programmers in a walkthrough and no one raised the possibility.

Switching Java

Finally at long last with Java 1.7 the switch statement will support strings.  This allows such wonderful code blocks as :

  case "DB2": 
   case "POSTGRES":
   default :

Which to me is a truly wonderful thing.

Happy Coding !