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 north.n@gmail.com designates
 74.125.83.49 as permitted sender)
References: <1390516056.86695.YahooMailNeo@web181704.mail.ne1.yahoo.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <1390516056.86695.YahooMailNeo@web181704.mail.ne1.yahoo.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <971E80C1-D48B-43FB-9D4D-1358DEB990DC@gmail.com>
Cc: "user@couchdb.apache.org" <user@couchdb.apache.org>
From: Nick North <north.n@gmail.com>
Subject: Re: Replication of attachment is extremely slow
Date: Fri, 24 Jan 2014 07:22:20 +0000
To: "user@couchdb.apache.org" <user@couchdb.apache.org>

There is a known inefficiency in parsing of attachments containing certain c=
haracter strings. This doesn't obviously sound like an instance of it, but y=
ou can eliminate the possibility very quickly if you replace all hyphens (i.=
e. the character "-") in your mixed content file by some other character, li=
ke "X". If replication of the modified file runs quickly, you've hit this pa=
rticular problem.

Nick

> On 23 Jan 2014, at 22:27, Scott Weber <scotty2541@sbcglobal.net> wrote:
>=20
> I have seen the same thing as the poster below.  Does anyone have a fix? W=
ork around?
>=20
> It would seem that the database server is doing some kind of inspection of=
 the=20
>=20
> attachments and deciding how to move them around (Based 64, UTF16, etc...)=
. =20
>=20
> Is this the case?
>=20
> Here is what I tried:
> I attached a mixed content file to a document (text+binary, kind of like a=
 PDF).  This was about 3 meg or so. Then I triggered a replication to anothe=
r database.  It took 30 seconds to replicate it *on the same box*.
>=20
> I deleted everything, and made several repeats of the this test.
>=20
> I renamed the file to *.BIN, then uploaded it.  Still took too long to rep=
licate.
>=20
> I renamed the file to *.TXT, then uploaded it.  Still took too long to rep=
licate.
>=20
> I renamed the file to *.EXE, then uploaded it.  Still took too long to rep=
licate.
>=20
> However, when I upload an *actual* executable file of about the same size,=
 it replicates it in about 1 second.
>=20
> In all cases, the "content_type" of the attachment was correct to the file=
 type.
>=20
> So clearly, something internal is ignoring the "content_type", and examini=
ng the file contents. Then deciding what to do about it.
>=20
> Is this expected behavior?  How can I get the system to simply pass attach=
ments as binary without do whatever it is doing.
>=20
> Thanks for any advice.
>=20
> -Scott
>=20
>=20
>> =46rom "Rian R. Maloney" <rian.malo...@yahoo.com>=20
>> Subject Replication of specific binary attachment is extremely slow=20
>> Date Tue, 21 Jan 2014 04:26:53 GMT=20
>> Hello Couch Community - I have an odd problem that I could use some help w=
ith. I am using
>=20
>> couch replication for attachments that are essentially a bunch of concate=
nated
>> TIFF images with some text in between each image. When I replicate a data=
base with a single
>> document that has a single binary attachment that is only 4.5mb it takes 3=
0+ seconds to
>=20
>> complete.
>=20
>>=20
>> If I zip the file it is sub second to completion
>=20
>>=20
>> My test cases have been on Windows 7 and Mac OS x10.7.5 running either
>=20
>> CouchDB 1.3, 1.4 or 1.5
>=20
>>=20
>> I am doing local replication  The CPU spikes for the entire duration
>=20
>> When I use Futon to kick off the replication, it is sub second to complet=
ion
>=20
>> but when I POST to replicate, it takes 30+ seconds ...
>=20