Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of robert.newson@gmail.com
 designates 209.85.218.218 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=DN1rUVju3MGVtWoaKC2HpapPBjJOg+xCaEPqovyn31QHMSKnT0B2dNndq3krkVCMP9
         bhhI8C8cjit3/iWL4fVnHKNK0zf5sTmAJ1JfpYmA/UGcRcEU3b2rUCLt7wtnALjiD4Yc
         ayuO5nwTJawT3T0T+7OeM06pLoM7bLH1Tqwy0=
MIME-Version: 1.0
In-Reply-To: <-2475371172427800684@unknownmsgid>
References: <4AEFFEC9.2020404@rogerbinns.com>
	 <-818254707187926005@unknownmsgid>
	 <46aeb24f0911030422n334467f5x71a0b312105d3b7f@mail.gmail.com>
	 <-2475371172427800684@unknownmsgid>
Date: Tue, 3 Nov 2009 14:15:08 +0000
Message-ID: <46aeb24f0911030615p7a846f3bnd5e9eecea24629e9@mail.gmail.com>
Subject: Re: Performance issue
From: Robert Newson <robert.newson@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

One thing that snagged me one time was a client that sent "Expect:
Continue" header. There was a time when couchdb didn't recognize this
case-insensitively. For me, this caused a two second delay to all
requests.

B.

On Tue, Nov 3, 2009 at 1:34 PM, Sebastian Negomireanu
<sebastian.negomireanu@justdesign.ro> wrote:
> I am connecting to the database from my .NET application (which uses Diva=
n
> as a library). But I've put it through a profiler and I get the large del=
ay
> when waiting for the response from the database. The time needed to run t=
he
> application itself (prepare the JSON message, parse the response etc.) is
> minimal compared to the time it waits for the request. Actually sending t=
he
> request takes less than 5ms.
>
> Anyway, I'll monitor everything with wireshark a bit later today and come
> back with the results. Maybe, as Roger pointed out, my infrastructure is =
the
> cause for this.
>
>
> Best regards,
> Sebastian Negomireanu | CTO / Managing Partner JustDesign Sibiu, Romania
> +40-726-181186 | +40-788-757462
> sebastian.negomireanu@justdesign.ro
>
> SC JustDesign SRL | Str. Dorului 20, 550352, Sibiu, Romania
> +40-269-210008 | office@justdesign.ro | www.justdesign.ro
>
>
> -----Original Message-----
> From: Robert Newson [mailto:robert.newson@gmail.com]
> Sent: Tuesday, November 03, 2009 2:22 PM
> To: user@couchdb.apache.org
> Subject: Re: Performance issue
>
> What HTTP client are you using?
>
> On Tue, Nov 3, 2009 at 11:06 AM, Sebastian Negomireanu
> <sebastian.negomireanu@justdesign.ro> wrote:
>> Ok I will try that and come back with results.
>>
>>
>> Best regards,
>> Sebastian Negomireanu | CTO / Managing Partner JustDesign Sibiu, Romania
>> +40-726-181186 | +40-788-757462
>> sebastian.negomireanu@justdesign.ro
>>
>> SC JustDesign SRL | Str. Dorului 20, 550352, Sibiu, Romania
>> +40-269-210008 | office@justdesign.ro | www.justdesign.ro
>>
>> -----Original Message-----
>> From: Roger Binns [mailto:rogerb@rogerbinns.com]
>> Sent: Tuesday, November 03, 2009 11:59 AM
>> To: user@couchdb.apache.org
>> Subject: Re: Performance issue
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Sebastian Negomireanu wrote:
>>> In both scenarios, I get response times around 500ms
>>
>> In these kind of situations I am a big fan of using Wireshark to see
> exactly
>> what the response time is. =A0There could be all sorts of funky stuff go=
ing
> on
>> such as proxy servers, DNS lookups, IPv6 failing and then going to IPv4
> and
>> who knows what else that may be major contributions to the time as
> observed
>> by the client side code.
>>
>> Roger
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAkrv/sgACgkQmOOfHg372QTcGQCdF0U0esBf+ODH54UESA1onxr2
>> i8AAn3beEdWJr0GbJXP1Z0hFirMWqyPO
>> =3DmUU0
>> -----END PGP SIGNATURE-----
>>
>>
>>
>
>
>