Skip to Content

I have just finished performing a controlled analysis of general performance differences for ASE 15.7 running process and threaded kernel mode on various platforms and hosts (RHEL running on Dell Xeon chips, Solaris running on SPARC M, SPARC T  and x64).  Although there are quite a few differences, the following image tells the story of the throughput variance one may expect when switching between different kernel modes:

PSS_VS_THR_THROUGHPUT

Top to bottom:  the top graph shows response time for the same query run by multiple concurrent client connections (each bar representing an absolute number of query executions a client connection has performed in a period of time – 5 minutes).  Bottom left – an average “throughput” for the client connections running vis-a-vis ASE configured in process kernel mode.  Bottom right – an average “throughput” for the client connections running vis-a-vis ASE configured in threaded kernel mode.   The bottom table(s) describes the type of configuration applied to ASE/JDBC.

The image is a bit bulky, but it is pretty eloquent and consistent – across all the platforms tested.  Even though sometimes it looks like ASE running the process kernel mode out-performs ASE running the threaded kernel mode, if you compare throughput more accurately it becomes clear that threaded kernel mode yields very stable, predictable response time, while the process kernel mode exhibits a bursty, unpredictable response time, with some client sessions outperforming others by as much as 100%.  Performing less controlled tests may create a false impression that the process kernel mode runs faster, which in fact is not really true.

It is nothing new, however.  Predictable response time has been named as one of the aspects the threaded kernel has brought into an ASE.  In the tests I run, both java client sessions and ASE itself were located on the same host, competing for OS resources.  Although there is very little I/O involved in the tests, still there is a telling difference in response time across the kernel modes.

I will not comment on the type of tests run in details here.  The only thing I will say is that you should definitely test your JDBC/ODBC client application with different JDBC/ODBC + ASE settings.  As it may be seen from the throughput variance, configuring ASE/JDBC/ODBC properly does make a difference (although it is not always possible to configure both for the best performance in real-life situation).

Stay curious and check yourself as much as possible…

ATM.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Doug Johnson

    Great research, process, and write-up!  I would love to know:

    1.  Did the test system have dedicated disks as a control?

    2.  How much of the data was believed to be cache?

    3.  How much write activity was performed? 

    Was throughput i/o constrained at any point?  

    Thanks!  Doug

    (0) 

Leave a Reply