Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Thu, 20 Dec 2012 18:11:13 +0000 (UTC)
From: "Benoit Chesneau (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12624861.1356025798212.37553.1356027073543@arcas>
In-Reply-To: <JIRA.12624861.1356025798212@arcas>
References: <JIRA.12624861.1356025798212@arcas>
Subject: [jira] [Updated] (COUCHDB-1634) authentication slows down all
 requests
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/COUCHDB-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benoit Chesneau updated COUCHDB-1634:
-------------------------------------

    Affects Version/s:     (was: 1.2.1)
                       1.2
    
> authentication slows down all requests
> --------------------------------------
>
>                 Key: COUCHDB-1634
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1634
>             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: http://www.atlassian.com/software/jira