What is “Use Concurrent Queue for Request Manager"?
Well, this is what Oracle states: Reduces lock contention by using concurrent buffer queue to park incoming requests. Enabling this attribute increases throughput as requests are scheduled without acquiring any locks.
There are two things we need to know before talking about locks:
- Serialization is the process of converting an object into a stream of bytes
- Context Switches is the switching of the CPU from one process or thread to another
So, Serialization affects scalability and Context Switches hurts performance - and becuase contended locking causes both, reducing lock contention improves both performance and scalability.
Two things govern the cause of Lock Contention, the first is how often that lock is requested, and the second being how long it’s held once acquired.
If the requests are at a suitable level, then most attempts to acquire the lock will not become contended - nor will it pose a significant scalability restriction. On the other hand, if the lock is in high demand then threads will become blocked waiting for a release, worst case scenario in this state the processors will sit idle even if there is plenty of work to perform.
There are a few ways to reduce lock contention, reduce the demand or frequency of the lock requests, replace exclusive locks with coordination mechanisms that permit greater concurrency, and lastly reduce the time that locks are held for - or in our case with WebLogic - turn on the “Use Concurrent Queue for Request Manager” setting.
So, what is a Concurrent Queue? Well, it’s a queue that uses a linear array with a (conceptually) infinite capacity - although there will only be a finite number of items stored in the queue. The items can be enqueued and dequeued an unlimited number of times.
Concurrent Queue is one of many settings that can be used to fine-tune WebLogic to get better performance, but it can also make things a lot worse. There are pros and cons to most things you implement but pre-testing in a non-live environment is key to a successful role out.
Before making the change in your Production environment, run load tests in, say, a duplicate Dev/UAT setup. Test the load before and after making the change - I’d advise to leave at least 2 to 3 weeks before making the change in Production, although this will depend very much on how often your Dev/UAT is used and the load/traffic.
When making the change in Production, if you have monitoring in place such as Graphite/Grafana or ELK then take a snapshot of the metrics before switching this feature on, then monitor for a few days to make sure performance has not dropped, look for any tell-tale signs in the Server logs or Thread Monitor.
There you go - hopefully this quickie has shed a little light on a useful WLS setting.