Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <27639863.1179921196483.JavaMail.jira@brutus>
Date: Wed, 23 May 2007 04:53:16 -0700 (PDT)
From: =?utf-8?Q?=C3=98ystein_Gr=C3=B8vlen_=28JIRA=29?= <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2586)
 BlobClob4BlobTest.tesPositionAgressive takes very long time
In-Reply-To: <29928540.1177419315520.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DERBY-2586?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498209 ]=20

=C3=98ystein Gr=C3=B8vlen commented on DERBY-2586:
----------------------------------------

> Once I changed the blob/clob to hold only 4k in memory and if it exceeds
> use a file it started taking very long because of the file i/o over
> heads. If we change the max buffer size (higher than 4k) we will be
> getting better performance for clob/blob of length smaller than the new
> value. But there may be risk of getting out of memory exception if we
> keep the value large and there are too many active blob and clob.I think
> we need not make the buffer size too large, as right now after making
> the stream buffered we are able to get performance comparable to the
> older implementation.

I think it is important that temporary storage is only used when the LOB is=
 updated.  Hence, when reading a LOB, one should make sure that the LOB is =
not written to temporary storage, regardless of size.


> BlobClob4BlobTest.tesPositionAgressive takes very long time
> -----------------------------------------------------------
>
>                 Key: DERBY-2586
>                 URL: https://issues.apache.org/jira/browse/DERBY-2586
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>            Reporter: =C3=98ystein Gr=C3=B8vlen
>         Assigned To: Anurag Shekhar
>             Fix For: 10.3.0.0
>
>         Attachments: derby-2586.diff
>
>
> Dan reports that BlobClob4BlobTest.tesPositionAgressive takes very long t=
o run:
> > In a test run (junit-all) of 5,816 fixtures that took 4124 seconds (~68=
mins) *three* fixtures took 53% of the total time.
> >
> > testPositionAgressive                1564.684 seconds
> > testNetworkServerSecurityMechanism    497.280 seconds
> > testTypesInActionStatement            128.928 seconds=20
> Knut Anders reports that this behavior is fairly new:
> > It seems like it started taking a lot more time at revision 530085. I h=
ad
> > run the tests at an earlier revision.
> This was a check-in for DERBY-2346.  Since Anurag is currently on vacatio=
n, I will try to look into this.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.