[ 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
