couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benoit Chesneau (JIRA)" <>
Subject [jira] [Updated] (COUCHDB-1634) authentication slows down all requests
Date Thu, 20 Dec 2012 18:11:13 GMT


Benoit Chesneau updated COUCHDB-1634:

    Affects Version/s:     (was: 1.2.1)
> authentication slows down all requests
> --------------------------------------
>                 Key: COUCHDB-1634
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>          Components: HTTP Interface
>    Affects Versions: 1.2, 1.3
>            Reporter: Benoit Chesneau
> I did yesterday a lot of test on the replication yesterday and found why the replication
was so slow and the CPU use so much on the "server". 
> The tests consisted in replicating 10000 docs from 1 "server" node on a machine  in 100
then 10 databases on 1 "client" node on another machine. The replication was launched on the
"client" node  (source is the "server" node). The replications on the 100 dbs are launched
concurrently. The point is to simulate more or less 100 devices replicating on the "server"
 node at the same time.s connections
> For 100 replications tasks the time was ~1h with basic auth against ~10mn without. In
the mean time teh CPU on the "server" node was at 700% with all the cores taken (8) and thoughtput
was  ~6-8Mb/s . Same diff apply to 10 concurrent replication tasks. 
> This morning I did a quick test going back on sha1 and the replication was faster x2.
cpu was really less used  < 100% 
> I think this is quite expected since we are doing on each request the following workflow:
> - base64.decode(auth header)
> - get user doc (cached or not)
> - hash auth 
> - and compare to what we have in the doc or settings
> But I think we should improve it asap. If one optimisation should be made that should
be here imo. Playing with the number of itterations of the hashing helps indeed but isn't
enough. Also cookie auth even if I didn't test it yet should be faster since it doens't try
to iterrate or such but still. 
> Maybe we should introduce a session system in couch? Since at the end it will only consist
in checking a tocken against another it may be faster. Or using other solution I don't yet.
Others dbs are a lot faster on that purpose. ANyway I don't have a strong opinion on what
the solution should be . But this is a big bottleneck for real usages of couchdb.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message