Performance Tuning JCAPS

We're getting close to (finally) deploying our JCAPS rewrite to production. Our final task is to load test and "tune" the application - making sure it will handle the expected production transaction load.

Prior to executing the load test, we added logging statements to report on the amount of processing time spent in each JCD (or processing unit for those non-JCAPpers out there). Using this info, we can determine the slow running processes and optimize them. For this optimization we could follow a traditional approach and profile the code, or we could take an easier route and configure JCAPS to throw more resources at the bottlenecks. This second option is done in the JCAPS connectivity map by increasing the maximum number of threads allocated to run the process. Clicking the input line to the JCD to open the properties, you can set the "Server session pool size" in the Advanced tab (NOTE: this setting is only for JCDs listening to JMS queues or topics).

I'm not sure how I feel about this really. On one hand, it's pretty cool to have this level of control. On the other hand, I'm wondering why I even have to deal with this. I mean, I don't ever need to set the maximum number of requests a web service can handle. The server automatically scales to the number of requests it receives until it runs out of resources.

I'm wondering why JCAPS JMS services cannot follow a similar approach as load becomes heavy? Maybe something similar to a database connection pool that could grow and reuse JMS listeners would provide an extensible solution?

Another question I have is why the architect of this application chose JMS over HTTP for the SOA medium between these services? We have no requirement for guaranteed delivery. This is a real time system, so there's no need to queue up messages if a certain component cannot respond for a while (those transactions will simply timeout). To me, JMS does not seem like the right fit for this application.

I'd be interested to hear other thoughts on this architecture choice. Is it possible I'm missing something? The people who made these decisions are no longer around to ask...

Comments

Unknown said…
So is it true that JCAPS uses SOAP over JMS for communication between bussiness processes? We are just using eGate so I don't know. How do you check that? I wonder what's more efficient anyway.
Have you measured this?

In IS, even thought this is not neccessary for the web cointaner, you must configure a pool size for EJBs and MDBs. So I think that JCAPS just allows you to configure a different value for each component. It is true, though, that they could have a value of 0 meaning "use the default configuration for this logicalhost".
October 30, 2008 at 1:06 PM
Vinnie said…
You can send anything over the JMS wire (it doesn't have to be a SOAP envelope). We currently send an XML string in most instances, but sometimes we send just a simple string.

Also know that you don't have to use JMS. You can use TCP, HTTP, MQ or just about any other messaging medium to tie your processes together.

My question was really the use of JMS over a lighter weight protocol (and no I haven't measured any of this).

I also asked this question on StackOverflow and got varying responses.
October 30, 2008 at 1:56 PM
eingfoan said…
i would just say it will give you a lot of functionality when your soloution is growing and maybeb gets fitted to more globally requirements and other usecases
November 3, 2008 at 6:20 PM
Post a Comment

Popular posts from this blog

I Believe...

A recent reorg at my company left me with a new manager - and a different approach to software development than my team had been previously following.  Our new approach is one that I don’t necessarily agree with, but it led me to think about - and reevaluate -  those tenets of software development that I think are important and that I believe lead to increased quality and productivity. This post will consist of fairly high level discussions about how to organize code, teams, and projects - but contain very little actual code. Many of these ideas will not be my own.  They are mostly ideas I’ve learned from others and their willingness to share their experiences with me.  They are, however, ideas that I’ve practiced and hardened as I’ve worked to build my own ideal environment for delivering value through software . Many of these ideas I now take for granted as commonplace (even though they aren’t).  I felt a need to document them anyway - so people can understand what to expect (a
Read more

FRail :include

I really like developing with Rails, but I've been frustrated the last few days by some things Rails should do quite easily, yet doesn't. I've already written here and here about some of my struggles with Rails :include clause. Here's one more... Let's say you have a has-and-belongs-to-many relationship. If you :include this relationship in a find query, Rails will automatically create the join clause including the lookup table! That's cool. Unfortunately, it looks as if only the :include clause provides this piece of functionality. Why isn't the same functionality provided via the :join clause or through a general purpose module? This doesn't make any sense to me! I'm working on a database application where I don't need to display a lot of data, but the data displayed is heavily filtered by it's connections to other information in the database. I need to join a lot of tables to perform the filtering operation and using :include
Read more

Performance Tuning JCAPS - Part 2

It's been close to 2 months since my first Performance Tuning JCAPS post. Since then, we've noticed our servers running out of TCP connections under heavy load. Researching this problem, we learned that the JCAPS' JMS server makes heavy use of TCP in implementing Request/Reply queues . We approached Sun for guidance and they assured us that they've had success implementing high throughput applications using the JMS request reply solution... but how? It appears a multi-step solution is needed. First, running out of TCP connections in a scenario like ours is a JCAPS bug addressed in an ESR (110348) and rolled into JCAPS 5.1.3 Update Release 3 . We installed this update and noticed a marked improvement. Running my simple 75 user simulated test, transactions took 2521 ms to round trip (compared to the previous time of 20128ms). While this is great improvement, an average of 2.5 seconds is still really slow for this simple transaction. We reported our findings to Su
Read more