The first thing to do before describing what these properties do, is to discuss the term ‘pool’. The ‘pool’ is a theoretical concept for a container or area of memory that holds a number of beans that have been instantiated, are in a ‘ready’ state, but not being used.
The idea here is that creating and destroying EJBs is a costly and time consuming process, which you don’t want to do every time a client calls an EJB's business method, so you need a few beans hanging around ready for use in order to improve the performance of your server.
initial-beans-in-free-pool is used to define the number of beans that the Weblogic server loads into memory (or the pool) when it starts up. The default value for this property is zero.
max-beans-in-free-pool is used to determine the maximum number of stateless EJB instances allowed in the pool. The default value for this property is 1000.
Setting these values is, to me, more of a black art than a science. Consider the following scenario: you’re deploying an EJB, you set the initial-beans-in-free-pool to 10 and the max-beans-in-free-pool to 50. So, on startup, the server creates 10 beans. Now, your EJB(s) start processing business calls and the system is busy and receives for example 100 calls at virtually the same time. The first 10 of these calls are processed quickly without any problems using the beans stored in the pool. At the next 40 of these calls are somewhat slower as the Weblogic server has to start instantiating new beans, which we’ve already said is a costly process. The last 50 of these calls are forced to wait in a queue until an EJB becomes free and is returned to the pool.
Obviously, you may decide that you want to improve your server’s performance, so you’ll need to start fiddling with these values and you decide to set initial-beans-in-free-pool to 100 and the max-beans-in-free-pool to 10000. In the above scenario, everything is hunky-dory and your 100 calls are processed without any problems.
Next, suppose that the system hits peak loading, and the number of business method calls rises to about the maximum value. The server will make as many EJB instances as it can to cover all the requests. However, you may have more than one type of EJB on your server and it too may be busy and creating more and more EJBs to try to meet all the business method calls. I guess that you can see what’s going to happen, at some point, you’ll run out of memory and get an exception. In order to counter this, you’ll start juggling the figures, trading memory for performance, to try to find out what the best values are to give the fastest throughput, whilst not crashing. As you can see, there’s no easy way to figure this out as you’re never certain how much memory an EJB will use in order to service a particular request, and you’re never too sure how, or when the garbage collector will kick in.
I’ve only talked about Weblogic Server tuning from the point of view of the number of beans in the free pool and there seem to be lots of other things to consider, for example tuning worker threads and setting JDBC pool sizes, and not to mention what happens when you get into a clustered environment, which is why I say that it’s more of a black art than a science.
Finally, I mentioned above that you can also use initial-beans-in-free-pool and max-beans-in-free-pool to configure MDBs, and that’s a whole different class of problem, which I may be looking into in a later blog.
No comments:
Post a comment