You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juddi.apache.org by Francisco Matias Cuenca-Acuna <mc...@matiascuenca.com.ar> on 2003/09/24 19:05:15 UTC
[juddi-Developers] Performance round 2
Ok, I got the newest (or I should say last monday's) version of
juddi to work and I fixed some problems with my DB to accept 10
connections. As instructed I also disabled the Monitor (BTW: What is its
function??)
Unfortunately performance has no changed significantly from my
last test (10 publishes per sec and 20 find_bussiness per sec). I can say
that it got better, but not enough to even run the full tests again.
What I have discovered though is that when doing a read only test
(i.e. find_bussiness with exact match on the name) I see this traffic going
into the DB.
(what follows is the result of 20 clients going to a pair of 2 juddi nodes)
Database.receive(): applying statement SET AUTOCOMMIT TRUE
Database.receive(): applying statement SET AUTOCOMMIT FALSE
Database.receive(): applying statement SET READONLY FALSE
Database.receive(): applying statement SET AUTOCOMMIT TRUE
Database.receive(): applying statement call
"org.hsqldb.Library.getAutoCommit"()
Database.receive(): applying statement COMMIT
Database.receive(): applying statement SET READONLY FALSE
Database.receive(): applying statement SET AUTOCOMMIT FALSE
Database.receive(): applying statement call
"org.hsqldb.Library.getAutoCommit"()
Database.receive(): applying statement call
"org.hsqldb.Library.getAutoCommit"()
Database.receive(): applying statement ROLLBACK
Database.receive(): applying statement SET AUTOCOMMIT FALSE
Database.receive(): applying statement COMMIT
Database.receive(): applying statement call
"org.hsqldb.Library.getAutoCommit"()
Database.receive(): applying statement COMMIT
Database.receive(): applying statement ROLLBACK
Database.receive(): applying statement call
"org.hsqldb.Library.getAutoCommit"()
Database.receive(): applying statement ROLLBACK
Database.receive(): applying statement COMMIT
Database.receive(): applying statement call
"org.hsqldb.Library.getAutoCommit"()
Database.receive(): applying statement ROLLBACK
Why are you doing ROLLBACKs and for read traffic??? Why do you
keep on testing and setting autocommit?. Can't you do this just once?? I
think that the autocommits are coming from Transaction.java:50
In ideas about this issues or how to make performance better??
Thanks
Matias
RE: [juddi-Developers] Performance round 2
Posted by Francisco Matias Cuenca-Acuna <mc...@cs.rutgers.edu>.
At 14:58 9/25/2003 -0600, you wrote:
>Monitor is for monitoring the use of UDDI - how many people are inquiring
>and publishing. Publishing was sort of already monitored since they need
>the authtoken, but inquiry goes unnoticed and most of the people who used
>the registry almost all the time inquire. So, it has been a very useful
>thing in our site where we have to justify the usage.
How do I access this statistics from outside juddi?? Do you know
if tomcat keeps similar information?? I will need to look at this values
for my experiments too.
>Stability versus Performance. By checking the autocommit and commiting we
>are fail safe. Some of the DBs hold a lock during select, so without
>knowing the isolation level, we cannot omit the commits. For each
>connection it should do it once,
But why do you need to commit at all if I'm only reading?? What
about the rollbacks??? What is it there to abort??
>could you check how many times one connection for one client has ?
I'll do it and write back to you.
Matias
PS: Any ideas on simple benchmarks for the DB??
>
>regards,
>-Anou
>
>
> -----Original Message-----
>From: juddi-developers-admin@lists.sourceforge.net
>[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of
>Francisco Matias Cuenca-Acuna
>Sent: Wednesday, September 24, 2003 6:02 PM
>To: juddi-developers@lists.sourceforge.net
>Subject: [juddi-Developers] Performance round 2
>
> Ok, I got the newest (or I should say last monday's) version of
> juddi to work and I fixed some problems with my DB to accept 10
> connections. As instructed I also disabled the Monitor (BTW: What is its
> function??)
>
> Unfortunately performance has no changed significantly from my
> last test (10 publishes per sec and 20 find_bussiness per sec). I can say
> that it got better, but not enough to even run the full tests again.
>
> What I have discovered though is that when doing a read only test
> (i.e. find_bussiness with exact match on the name) I see this traffic
> going into the DB.
>
>(what follows is the result of 20 clients going to a pair of 2 juddi nodes)
>
>Database.receive(): applying statement SET AUTOCOMMIT TRUE
>Database.receive(): applying statement SET AUTOCOMMIT FALSE
>Database.receive(): applying statement SET READONLY FALSE
>Database.receive(): applying statement SET AUTOCOMMIT TRUE
>Database.receive(): applying statement call
>"org.hsqldb.Library.getAutoCommit"()
>Database.receive(): applying statement COMMIT
>Database.receive(): applying statement SET READONLY FALSE
>Database.receive(): applying statement SET AUTOCOMMIT FALSE
>Database.receive(): applying statement call
>"org.hsqldb.Library.getAutoCommit"()
>Database.receive(): applying statement call
>"org.hsqldb.Library.getAutoCommit"()
>Database.receive(): applying statement ROLLBACK
>Database.receive(): applying statement SET AUTOCOMMIT FALSE
>Database.receive(): applying statement COMMIT
>Database.receive(): applying statement call
>"org.hsqldb.Library.getAutoCommit"()
>Database.receive(): applying statement COMMIT
>Database.receive(): applying statement ROLLBACK
>Database.receive(): applying statement call
>"org.hsqldb.Library.getAutoCommit"()
>Database.receive(): applying statement ROLLBACK
>Database.receive(): applying statement COMMIT
>Database.receive(): applying statement call
>"org.hsqldb.Library.getAutoCommit"()
>Database.receive(): applying statement ROLLBACK
>
> Why are you doing ROLLBACKs and for read traffic??? Why do you
> keep on testing and setting autocommit?. Can't you do this just once?? I
> think that the autocommits are coming from Transaction.java:50
>
> In ideas about this issues or how to make performance better??
> Thanks
> Matias
RE: [juddi-Developers] Performance round 2
Posted by Anou Manavalan <am...@sybase.com>.
Monitor is for monitoring the use of UDDI - how many people are inquiring
and publishing. Publishing was sort of already monitored since they need the
authtoken, but inquiry goes unnoticed and most of the people who used the
registry almost all the time inquire. So, it has been a very useful thing in
our site where we have to justify the usage.
Stability versus Performance. By checking the autocommit and commiting we
are fail safe. Some of the DBs hold a lock during select, so without knowing
the isolation level, we cannot omit the commits. For each connection it
should do it once, could you check how many times one connection for one
client has ?
regards,
-Anou
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of Francisco
Matias Cuenca-Acuna
Sent: Wednesday, September 24, 2003 6:02 PM
To: juddi-developers@lists.sourceforge.net
Subject: [juddi-Developers] Performance round 2
Ok, I got the newest (or I should say last monday's) version of
juddi to work and I fixed some problems with my DB to accept 10 connections.
As instructed I also disabled the Monitor (BTW: What is its function??)
Unfortunately performance has no changed significantly from my
last test (10 publishes per sec and 20 find_bussiness per sec). I can say
that it got better, but not enough to even run the full tests again.
What I have discovered though is that when doing a read only test
(i.e. find_bussiness with exact match on the name) I see this traffic going
into the DB.
(what follows is the result of 20 clients going to a pair of 2 juddi
nodes)
Database.receive(): applying statement SET AUTOCOMMIT TRUE
Database.receive(): applying statement SET AUTOCOMMIT FALSE
Database.receive(): applying statement SET READONLY FALSE
Database.receive(): applying statement SET AUTOCOMMIT TRUE
Database.receive(): applying statement call
"org.hsqldb.Library.getAutoCommit"()
Database.receive(): applying statement COMMIT
Database.receive(): applying statement SET READONLY FALSE
Database.receive(): applying statement SET AUTOCOMMIT FALSE
Database.receive(): applying statement call
"org.hsqldb.Library.getAutoCommit"()
Database.receive(): applying statement call
"org.hsqldb.Library.getAutoCommit"()
Database.receive(): applying statement ROLLBACK
Database.receive(): applying statement SET AUTOCOMMIT FALSE
Database.receive(): applying statement COMMIT
Database.receive(): applying statement call
"org.hsqldb.Library.getAutoCommit"()
Database.receive(): applying statement COMMIT
Database.receive(): applying statement ROLLBACK
Database.receive(): applying statement call
"org.hsqldb.Library.getAutoCommit"()
Database.receive(): applying statement ROLLBACK
Database.receive(): applying statement COMMIT
Database.receive(): applying statement call
"org.hsqldb.Library.getAutoCommit"()
Database.receive(): applying statement ROLLBACK
Why are you doing ROLLBACKs and for read traffic??? Why do you
keep on testing and setting autocommit?. Can't you do this just once?? I
think that the autocommits are coming from Transaction.java:50
In ideas about this issues or how to make performance better??
Thanks
Matias