...
There are different strategies that could be used to fix this problem, such as refactoring the code, replacing the XML parsing library or the mechanism used within the library, re-structuring the use of mutexes to multiple instances or changing them to be RW mutexes.
Central Logger
In the case of the central logger, it's not a mystery the slow down comes from the remote call to the central logger.
| Code Block | ||
|---|---|---|
| ||
m_logger->writeRecords(reclist); |
Here the slowdown accounts for ~70/80 μs on a local deployment, but can get closer to 1 ms when the central logger is on a different machine than the process generating the logs.
Again, there are several alternatives to improve the thread contention problems, for example by queuing this task and dispatching them on a separate thread. It is also possible to replace the writeRecords method to be oneway on the IDL, which makes it 2x/3x faster on the local deployment, and it also makes it invariant to the deployment as this call does not wait for a reply from the remote object. The drawback is losing the ability to assess whether the message was sent or there was a problem along the way, which could be leveraged by the use of a callback object.