[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] xmlBlaster performance issues
Thanks for your feedback. We have tried most of your suggestions. We
saw some improvement.
However, I think I mis-characterized our throughput before. I mentioned
the LoadTestSub test and a figure near 300 mps. Those 300 mps were
using your packaged test with Java client, running both the client and
server on the same machine in two different terminals.
Our *actual* measured throughput in practice between all of our
applications can rarely exceed about 30 mps. More than that though, in
a test where we had two simple clients (a "sender" and "receiver", both
written using the C API), we maxed out at 30 mps at first -- but over
time, the server slowed down. Over just a few thousand messages (2 or 3
minutes) it ran down to only 7-10 mps. We could completely disconnect
and shut down both clients, but after a reconnect (without restarting
the server) the same (ever-slowing-down) rate continued. This was also
after we uncommented the 7 lines in the properties file, so
theoretically nothing should be persistent.
It was this "slowing down over time" behavior that has really been
causing us problems. (I was so busy describing our environment last
time and trying to enumerate all our issues that I let that one slip by.
:) ) It appears to be on the sending side of the C client. In
particular, "Publish" has always seemed like it should be a non-blocking
call, so in our main C app we didn't take any special precautions (such
as a message dispatch thread), and just called our send routines
wherever we needed to in our main program loop. Over the lifetime of
the application though, the rest of our interface begins to slow to a
crawl. We can alleviate this with something like a dispatch thread, but
that just means we'd be pushing the problem somewhere else where a queue
would just be getting backed up.
Does any of this "slowing down" behavior sound familiar to you?
piegdon at soartech.com