You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-user@jakarta.apache.org by St...@hyperion.com on 2002/09/06 23:22:59 UTC
Upgraded to SLIDE_1_0 - Poor Performance
We have been working with Slide v1.0.16 for almost 3 months now and were
successfully able to deploy it as a webapp within the Tomcat 4.0.4
environment and have other webservices that access the Slide Kernel as part
of our application.
This week, we decided to upgrade to the SLIDE_1_0 branch, which I
understood contained all the bug fixes to the v1.0.16 release. We were
able to download the source from CVS for the SLIDE_1_0 branch and got
everything to compile. Then, we just upgraded all the Slide components in
our environment to the new ones and there was a significant performance
decrease accessing all the information, in some cases as much as 8x slower.
Upon changing in and out jar files from the two different versions, I think
I was able to isolate it to the "slide-stores.jar" file. If I use every
other jar file from the SLIDE_1_0 build, and keep the "slide-stores.jar
file from the v1.0.16 release, everything works great. As soon as I
replace this jar file with the one from the SLIDE_1_0 branch, performance
just crawls. I have looked through the files in CVS to see what might have
changed and I cannot find anything that might have caused such a drop in
performance.
Does anyone have any ideas on this issue??
- Stan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Upgraded to SLIDE_1_0 - Poor Performance
Posted by Lukasz Kowalczyk <lu...@jazzpolice.pl>.
Wednesday, September 11, 2002, 10:24:33 AM, you wrote:
LZ> Hi,
LZ> about performance in a JDBC Store, I wonder if a possible solution could be
LZ> to put
LZ> some index or primary Key in the tabels.
LZ> For example huge tables like Object or Property has no Primary Key.
LZ> has somebody considered this way?
I added a few indexes to my database and it looks like performance
went up (I didn't do any timing tests yet). SQL for indexes is
included below (postgresql).
create index idx_rc_uri_xnumber on revisioncontent (uri, xnumber);
create index idx_obj_uri on objects (uri);
create index idx_chld_uri on children (uri);
create index idx_lnks_linkto on links (linkto);
create index idx_lnks_link on links (link);
create index idx_perm_osar on permissions (object, subject, action, revisionnumber);
create index idx_perm_obj on permissions (object);
create index idx_lcks_id on locks (id);
create index idx_lcks_obj on locks (object);
create index idx_revs_uri on revisions (uri);
create index idx_wrkrev_uri on workingrevision (uri);
create index idx_ltstrev_uri on latestrevisions (uri);
create index idx_rev_uri on revision (uri);
create index idx_rev_uri_xnumber on revision (uri, xnumber);
create index idx_brnch_uri_xnumber on branches (uri, xnumber);
create index idx_lbl_uri_xnumber on label (uri, xnumber);
create index idx_prop_uri_xnumber on property (uri, xnumber);
--
Łukasz Kowalczyk
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Upgraded to SLIDE_1_0 - Poor Performance
Posted by Luca Zago <za...@libero.it>.
Hi,
about performance in a JDBC Store, I wonder if a possible solution could be
to put
some index or primary Key in the tabels.
For example huge tables like Object or Property has no Primary Key.
has somebody considered this way?
At 08.02 11/09/2002 +0200, you wrote:
>Sung-Gu wrote:
>>----- Original Message -----
>>From: <St...@hyperion.com>
>>
>>>other jar file from the SLIDE_1_0 build, and keep the "slide-stores.jar
>>>file from the v1.0.16 release, everything works great. As soon as I
>>
>>Is the binary a version with factory mechanism that Christopher Lenz was
>>done or not?
>>I guess he might know about it. :)
>
>Nope ;-)
>The factory stuff is (a) in the the WebDAV layer, and (b) not causing
>performance degradation.
>
>As I've written Stan in a direct mail, I suspect that the connection
>validation stuff added to the JDBC stores is the "bad guy"... at least
>it's pretty much the only big change in the relevant code.
>
>--
>Christopher Lenz
>/=/ cmlenz at gmx.de
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Upgraded to SLIDE_1_0 - Poor Performance
Posted by Christopher Lenz <cm...@gmx.de>.
Sung-Gu wrote:
> ----- Original Message -----
> From: <St...@hyperion.com>
>
>>other jar file from the SLIDE_1_0 build, and keep the "slide-stores.jar
>>file from the v1.0.16 release, everything works great. As soon as I
>
>
> Is the binary a version with factory mechanism that Christopher Lenz was
> done or not?
> I guess he might know about it. :)
Nope ;-)
The factory stuff is (a) in the the WebDAV layer, and (b) not causing
performance degradation.
As I've written Stan in a direct mail, I suspect that the connection
validation stuff added to the JDBC stores is the "bad guy"... at least
it's pretty much the only big change in the relevant code.
--
Christopher Lenz
/=/ cmlenz at gmx.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Upgraded to SLIDE_1_0 - Poor Performance
Posted by Sung-Gu <je...@apache.org>.
----- Original Message -----
From: <St...@hyperion.com>
> other jar file from the SLIDE_1_0 build, and keep the "slide-stores.jar
> file from the v1.0.16 release, everything works great. As soon as I
Is the binary a version with factory mechanism that Christopher Lenz was
done or not?
I guess he might know about it. :)
Sung-Gu
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>