directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: Scalability / performance testing?
Date Mon, 30 Dec 2013 17:12:00 GMT
Le 12/30/13 5:42 PM, Marc Boorshtein a écrit :
> I was wondering if anyone's done any performance or scalability testing on
> apacheds 2.0.0M15?  I know no 2 benchmarks are the same so I'm not looking
> for comparisons with other directories.

I have done some benchmarks 6 months ago with 5 injectors sending as
manu search request as possible to the server. I won't say it's enough
to guarantee that the server is stable enough...
>
> I ask because I've completed the integration of MyVD into apacheds and for
> the most part it works great.  I setup a test to see how hard I could beat
> on MyVD built on apacheds and found that for the most part performance was
> very good.  One area I'm a little concerned on is I see the following
> messages in my logs:
>
> [2013-12-27 23:13:55,427][pool-6-thread-2] INFO  LdapRequestHandler -
> ignoring the message MessageType : SEARCH_REQUEST
> Message ID : 5378
>     SearchRequest
>         baseDn : 'o=Tremolo'
>         filter :
> '(&(objectClass=inetOrgPerson)(mail=testuser114@ad1.local.aws))'
>         scope : whole subtree
>         typesOnly : false
>         Size Limit : 1000
>         Time Limit : no limit
>         Deref Aliases : never Deref Aliases
>         attributes :
> org.apache.directory.api.ldap.model.message.SearchRequestImpl@9cd91e8areceived
> from null session

This is typical of a client hving closed the connection just after
having sent a search request. It sounds weird, but it's a possibility :

    public final void handleMessage( IoSession session, T message )
throws Exception
    {
        LdapSession ldapSession =
ldapServer.getLdapSessionManager().getLdapSession( session );

        if ( ldapSession == null )
        {
            // in some cases the session is becoming null though the
client is sending the UnbindRequest
            // before closing
            LOG.info( "ignoring the message {} received from null
session", message );
            return;
        }

>
> and
>
> [2013-12-27 23:13:55,584][pool-6-thread-3] INFO  LdapRequestHandler -
> ignoring the message MessageType : BIND_REQUEST
> Message ID : 5435
>     BindRequest
>         Version : '3'
>         Name : 'CN=testuser934,ou=ad2-domain-com,o=Tremolo'
>         Simple authentication : '$tart123/0x24 0x74 0x61 0x72 0x74 0x31
> 0x32 0x33 '
>  received from null session
>
> under very heavy load (50 threads constantly logging-in with no "down" time
> for other work being done).  How can something have a "null" session?

The BIND operation is different from a session. A LdapSession is
associated with a physical connection, while the Bind operation is just
a message sent by the user. For some reason, (the protocol mandate it),
you have to accept concurrent operations for a single session, like for
instance an Abandon request should be processed even if a search request
is being processed.

Thus we have more than one thread processing the incoming requests, and
in some cases, processing a Unbind request might be unliky and being
done on a already closed connection.
>
> Are there any guide lines for how to configure apacheds?  ie the number of
> threads?

You can increase the number of processing thread in the transport layer
:
http://directory.apache.org/apacheds/advanced-ug/2-server-config.html#transports
(check the ads-transportNbThreads paramenter).

Now, if you can insolate some problem, we would be happy to check what's
going on !

One last thing : we will conduct some load tests very soon.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 


Mime
View raw message