Performance and scalability: HACL and Threads
I've been using HACL from IBM Host On-Demand v.6.0, but found a serious problem while using threads. My objective was to create a "Transaction Server" that could responds to several simultaneous operations on the mainframe using HACL. I developed an application that permitted to program transactions and its publication as Web Services. All went
well until I started load testing the server, when I noticed than only around 20-30 demands were satisfied by minute maximum. After one week of testing and debugging I finally concluded that the problem was HACL.
A very simple test proves this: if I send 40 threads creating a session and doing the login, the first thread ends in 15s, the second one in 16s, the third in 17s... until the last one in around 80s... I can only conclude that my code is wrong (I followed the IBM
documentation) or the HACL has some synchronized code that does not permit simultaneous execution. This problem occurs for login, but I imagine that normal operations have the same limitation.
This is a very serious problem for me, because after 6 month of work I realize the application can not do what it was intended for.
Anyone has experience with HACL with threads? Is this a real problem?
Thank you very much,
Araxes Tharsis (araxestharsis at mail dot telepac dot pt)
While I don't know anything about HACL...an easy way to see if their is a synchronization issue is this: ctrl-break'ing or kill -3 the HACL and analyzing the callstacks on the thread dumps.
-do your thing with 5 clients ....kill -3 ...save your output
-do your thing with 40+ clients....kill -3....save your outputs
If their are synchronization issues...you will see threads in a "wait" state and not in a "runnable" state. The call stack should show you the synchronization issue and the object the threads are waiting on. Of course you could do this more elegantly with JProbe...but this is a quick approach.
Just a thought though...in your scenario where the threads take longer and longer to complete..is the CPU or some other resource maxed out? A db connection pool?
Hope this helps,
Forgive me for my ignorance, but I don't know exactly what you mean when you say "analyzing the callstacks on the thread dumps" and "save your output".
On the other hand, during my tests the 2 CPUs of the machine don't go over 5% activity..., and my test is using only the basic code and HACL with no database access.
Thank you very much for your hel.
... I don't know exactly what you mean when you say "analyzing the callstacks on the thread dumps" and "save your output".On the other hand, during my tests the 2 CPUs of the machine don't go over 5% activity..., and my test is using only the basic code and HACL with no database access...When you send a signal number 3 (SIGQUIT) to a JVM process, you get a detailed view of what is happening inside the threads of the JVM. So, if you send several signals to a JVM (for example, five signals in an interval of ten seconds) you are going to get an idea of why your application is not performing as you want, althougt you have got plenty of CPU avaliable.
You may find interesting to read this article in order to understand how to read a 'thread dump'. At the begining is a little confusing, but after several minutes, you start feeling confortable with the information:
Hope this help.
Jose Ramon Huerga