You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2006/06/17 14:08:29 UTC
[jira] Created: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Long wait interval between requests with a single threaded client
-----------------------------------------------------------------
Key: DIRMINA-221
URL: http://issues.apache.org/jira/browse/DIRMINA-221
Project: Directory MINA
Type: Improvement
Reporter: Emmanuel Lecharny
Priority: Critical
Hi MINA band,
we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
...
private void notifyAdded()
{
if( waiters > 0 )
notify();
}
...
...
public synchronized void waitForNewItem() throws InterruptedException
{
waiters++;
try
{
while( super.isEmpty() )
{
wait();
...
Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
...
Waited : 42
fetchBuffer : 42
Waited : 0
fetchBuffer : 0
Waited : 1
fetchBuffer : 1
Waited : 39
fetchBuffer : 39
Waited : 0
fetchBuffer : 0
Waited : 1
fetchBuffer : 1
Waited : 39
fetchBuffer : 39
Waited : 0
fetchBuffer : 0
Waited : 1
fetchBuffer : 1
Waited : 39
fetchBuffer : 39
Waited : 0
fetchBuffer : 0
Waited : 1
...
I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12416619 ]
Emmanuel Lecharny commented on DIRMINA-221:
-------------------------------------------
Well, we won't be able to switch to Java 5 Queue, because we must keep the jdk 1.4 compatibility.
I will try the util.concurrent one. Just a question : why do we need a queue here?
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "peter royal (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12416784 ]
peter royal commented on DIRMINA-221:
-------------------------------------
Try toggling that TCP_NODELAY to disable nagle's algo.. I've seen it give high latency on small packet sizes.
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=all ]
Emmanuel Lecharny resolved DIRMINA-221:
---------------------------------------
Resolution: Invalid
That's very true ... I should have been tired yesturday :)
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12416713 ]
Emmanuel Lecharny commented on DIRMINA-221:
-------------------------------------------
I was plain wrong when thinking that we should have synchronous req/resp. The RFC states exactly the opposite :
"Although servers are required to return responses whenever such
responses are defined in the protocol, there is no requirement for
synchronous behavior on the part of either clients or servers.
Requests and responses for multiple operations generally may be
exchanged between a client and server in any order. If required,
synchronous behavior may be controlled by client applications."
So we *must* queue requests.
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12417431 ]
Emmanuel Lecharny commented on DIRMINA-221:
-------------------------------------------
Yeah, I know that Trustin. But I don't want to close the issue until I commit the changed I made in the server.
(I also know I'm lazzy not to open a DirServer issue for this one ;)
It will be closed really soon!
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12416867 ]
Trustin Lee commented on DIRMINA-221:
-------------------------------------
Ah I forgot to mention that I ran client and server in the same machine. Emmanuel told me he tested in the same way though.
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12416872 ]
Emmanuel Lecharny commented on DIRMINA-221:
-------------------------------------------
Trustin, how is it possible that more than one message is contained in one packet? We are supposed to send a message and wait for the response, and looping like that. On my linux box, I get a standard througput of 25 req/s, without any lost response. If I disable Nable algo on the server side only, or on the client and server side, then the server receive 2 or 3 requests, and suddendly, it stops (or I think this is more likely the client which never receive the response, because if I stop the client and relaunch it, I can get some more requests on the server).
I didn't test the program on W$, I just have various linux boxes (ubuntu 6.0.6 and FC5)
Client and server run on the same machine, too.
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=all ]
Emmanuel Lecharny updated DIRMINA-221:
--------------------------------------
Attachment: test-server.tgz
The client/server test written by Alex. It's an eclipse project.
Alex will commit it soon in the sandbax
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12417418 ]
Trustin Lee commented on DIRMINA-221:
-------------------------------------
Thank you, Emmanuel, but you didn't close the issue. You are the reporter, so you're the only one who can close this issue. Please change the status of this issue from 'Resolved' to 'Closed'.
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=all ]
Emmanuel Lecharny closed DIRMINA-221:
-------------------------------------
The patch has been commited.
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Reopened: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=all ]
Trustin Lee reopened DIRMINA-221:
---------------------------------
Please close this issue again as 'invalid' instead of 'fixed'. We didn't change any part of code. :)
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12416649 ]
Alex Karasulu commented on DIRMINA-221:
---------------------------------------
ooooppppps to checkout don't forget co:
svn co https://svn.apache.org/repos/asf/directory/sandbox/akarasulu/mina-profiling
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "peter royal (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12416620 ]
peter royal commented on DIRMINA-221:
-------------------------------------
My guess is that this is in the ThreadPoolFilter, where it puts the data for a given connection into a Queue. (the consumer side is the Thread that will do the processing).
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12417051 ]
Emmanuel Lecharny commented on DIRMINA-221:
-------------------------------------------
Ok, thanks to Trustin, the problem I had with the attached C/S is that if I switch the TcpNoWait flag to true, then I can receive packets that could contain more than one message. The client was not writen expecting this, so it stalls.
I gonna give ADS a chance with the TcpNoDelay, and I think it may work.
We just have to wait until 9PM, CEST to have the results... Office is calling me :(
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Trustin Lee (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12416866 ]
Trustin Lee commented on DIRMINA-221:
-------------------------------------
Alex, the test code you checked in to the svn repository has a problem that it stops sending messages when more than one messages are contained in one packet. It runs for only a few seconds but the throughput looks fine for me. The maximum value I got was about 1000~3000, without disabling Nagle's algorithm. The result doesn't change even if I don't disable it.
I ran the tests in JDK 1.5.0_06, Windows XP Professionsl. Is this the only problem for Linux or other platforms?
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "peter royal (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12416616 ]
peter royal commented on DIRMINA-221:
-------------------------------------
Is the test case in SVN somewhere so we can take a peek?
My first random thought is, are you comfortable switching out the BlockingQueue implementation? Try one that ships with Java 5, or perhaps the util.concurrent backport, and see how it performs.
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12416648 ]
Alex Karasulu commented on DIRMINA-221:
---------------------------------------
I committed this simple client server application (the one that is attached above by emmanuel) for profiling and tuning MINA to increase the requests per second up past 25/s per client. Here's how to check it out:
svn https://svn.apache.org/repos/asf/directory/sandbox/akarasulu/mina-profiling
Here's a problem description:
Problem Statement
=================
Presently we can only get a single thread to pump 25 requests per second
regardless of the protocol into a MINA server. There is a natural latency
somewhere and we're trying to figure it out.
This project includes a simple client and server for testing and profiling
MINA for performance. The goal is to get the requests per second that a
client can have serviced up as high as it can go. 25/s is just not
acceptable.
Simple LDAP Client/Server
=========================
The following project is for profiling MINA using a very simple client and
server. It has two module: client and server.
The client is a hardcoded LDAP client. It sends ethereal captured LDAP PDUs to
any LDAP server to read the RootDSE. It first sends a bind PDU with a bind
principal of 'uid=admin,ou=system' and password of 'secret'. The bind is a
simple bind as you see. Again the PDU is a captured byte array so there's
really nothing LDAP specific in the code. After the bind the client sends one
or more search requests. The number of requests are specified as a parameter
to the client application. Finally after searching the RootDSE N number of
times the client sends an Unbind request to the server. All requests are
precaptured byte[]s of PDUs. To build and run the client issue the following
command:
client.sh <hostname> <port> <n>
Where <n> is the number of search requests to send to the server.
The server likewise sends pre-constructed captured PDU byte[]s back to the
client. For the bind request it checks the request type and returns a bind
response of success. For the search request it returns a byte[] containing the
RootDSE entry and then sends a search done PDU in another byte[]. The server
reports to the command line every second the number of requests per second it
has processed. Building and running the server is simple:
server.sh
If you want to profile the server using yourkit you'll want to setup your
LD_LIBRARY_PATH to point to the area where the shared libraries for yourkit are
stored for your platform. For example my setup is as follows:
export LD_LIBRARY_PATH=/opt/tools/yjp-5.1/bin/linux-x86-32
Now to run the server then attach the profiler to it start the server like so:
server.sh profile
To override the default listener port which is 10389 just add another port
value after the profile keyword like so:
server.sh profile 1024
If you're not profiling but want to override the port just add the port number:
server.sh 1024
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12416966 ]
Emmanuel Lecharny commented on DIRMINA-221:
-------------------------------------------
Guys, thanks for alll those informations.
I tested the different options like setTcpNoDelay(), but I still have this very low througput. It seems that it's something we experience on Linux, not on Windows. At this point, I'm just asking myself if this is still a Socket issue, and when I look but to my first post, which shows that we have a 40ms wait time in the waitForNewItem() method.
Any idea ?
Thanks !
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12416621 ]
Emmanuel Lecharny commented on DIRMINA-221:
-------------------------------------------
Does it make sense to queue a user request when this user tries to send as many request he can before receiving the responses? My guess is that we may use a synchronous protocol between a user and the server, ie blocking the client until the response has been totally sent to the user, before accepting a new request.
To be clear, for user A :
req1 --> server
req2 --> server
req3 --> server
resp1 <-- server
req4 --> server
....
should not be possible.
We should have :
req1 --> server
(wait)
resp1<--
req1 --> server
(wait)
resp1 <-- server.
Am I totally wrong ? Because if this is what we want implemented, using a queue does not make sense into a single user session.
If a user want to send more than one request, then he has to open a new session.
At this point, I'm just wondering how is the AbandonRequest handled... Grrrr....
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "peter royal (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=comments#action_12416617 ]
peter royal commented on DIRMINA-221:
-------------------------------------
Specifically, something like:
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/WaitFreeQueue.html
or
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/LinkedQueue.html
or for Java 5, LinkedBlockingQueue
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (DIRMINA-221) Long wait interval between requests
with a single threaded client
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRMINA-221?page=all ]
Emmanuel Lecharny resolved DIRMINA-221:
---------------------------------------
Resolution: Fixed
Ok, thanks you all, guys :)
The pb was solved by setting the TCPNoWait configuration. I'm not anymore stuck to 25 req/s with a mono-thread client : I'm around 350 search requests per second, which is not so bad.
Thanks again !
> Long wait interval between requests with a single threaded client
> -----------------------------------------------------------------
>
> Key: DIRMINA-221
> URL: http://issues.apache.org/jira/browse/DIRMINA-221
> Project: Directory MINA
> Type: Improvement
> Reporter: Emmanuel Lecharny
> Priority: Critical
> Attachments: test-server.tgz
>
> Hi MINA band,
> we are currently experiencing a very strange behavior in MINA. While doing performances tests of ADS? we found that we cannot go upper than 25 search requests per second. We stripped the server from its backend, and eventually, Alex wrote a single client/server program unsing MINA to isolate the pb.
> Vasically, we have a client which continuously send requests, and get a result from a very simplified server. If the client has only one thread running, there is a wall we hit ate around 25 req/s. If we use more than one thread, suddenly this wall go up to NbThreads*25 req/s (ie, with 4 threads requesting, we reach 100 req/s, with 10, 250 req/s, ... with 100 threads, we have 1500 req/s).
> After having put some traces into MINA, here what I found in BlockingQueue : those two methods seems to be connected. When you call notifyAdd, then the method waitForNewItem() wait stops. We are waiting for an average of 40ms for each request in the waitForNewItem() method, ad I don't know which kind of processing or synchronization generate those 40ms wait.
> ...
> private void notifyAdded()
> {
> if( waiters > 0 )
> notify();
> }
> ...
> ...
> public synchronized void waitForNewItem() throws InterruptedException
> {
> waiters++;
> try
> {
> while( super.isEmpty() )
> {
> wait();
> ...
> Here is a sample of time wait we have in the fetchBuffer() method, which call the waitForNewItem() method (time is in ms) :
> ...
> Waited : 42
> fetchBuffer : 42
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> fetchBuffer : 1
> Waited : 39
> fetchBuffer : 39
> Waited : 0
> fetchBuffer : 0
> Waited : 1
> ...
> I know that the wait I get the delay is not very optimal (System.currentTimeMillis()), but 40 ms is *very* long.
> At this point, Alex and me are clueless. We have not enough understanding on the Mina internals to explian and fix this problem - if it's a problem -, or to configure MINA to avoid this kind of behavior.
> If any of you could help us, this will be *very* appreciated, as the whole LDAP server perfomance relies on MINA.
> Thanks !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira