Ilya Sterin wrote:
How many sessions did you create in your load-test ?
One,
So it makes sense that, using an OrderedThreadPoolExecutor, the messages
are processed one after the other on a single thread. The
OrderedThreadPoolExecutor contract is clear : it keeps the event being
processed in the order they arrive across a session.
but we're streaming very small protocol payloads and then
performing tasks that require more IO/Processing, therefore the
IoHandlers are proportionally heavier than the decoder, causing a
backup once the lots of messages are coming. Our use case, it's not
inconceivable that we'd receive 20 thousand messages in a few seconds.
Depending on the machine, I think that MINA can afford the load. The
tests we have done on ADS (in the case we are having one single client,
thus one single session, and an orderedThreadPoolExecutor) shows that,
on my Centrino duo laptop, we can reach around a thousand LDAP request
per second.
What is exactly your configuration, and your number of req/s ?
<snip/>
OrderedThreadPool is about serializing the events PER SESSION.
This means that the order of the messageReceived events _per session_
is guaranteed to be preserved.
But events from multiple sessions are not serialized.
Yes, I see that now. Though I know see some benefit to the thread
model in 1.* series of MINA, it's still not clear to me why the
restriction of only having multithreading ability per session matters.
It depens on how you deal with the message order. In our case, i would
be _very_ disapointed if the unbind message arrives _before_ the search
message, on the same session ...
I don't see the huge benefit for pushing a thread pool executor into
the pipeline before the the IoHandler,
since it'll be processed
serially and the benefit of spinning of a different thread for that as
opposed to processing it in the same thread as the decoder, is
subjective. Though the decoder can go back to processing, the
pipeline will never get ahead of the IoHandler thread. The only
benefit I see is snappier responses to the connected client. Either
way, I'm sure there are some apps (or more than I think), that would
benefit from such a model, but in our case we wanted the protocol
codec thread to not get too much ahead of the IoHandlers, so that
model wasn't beneficial.
At least, you have a choice.
Thanks for the help. We've migrated to 2.0 and it works great. We
went from processing 6 requests per second in IoHandler, to 150-200,
Do you mean you _were_ able to process only 6 req/s with mina 1.1.6 or
that your application was receinving this load ? In other words, are
these the limits you have reached ? I would be very surprise to hear
that MINA 1.1.6 was not able to process more than 6 req/s ...
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
