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/12 14:18:23 UTC
[juddi-Developers] First performance numbers for jUDDI
Hi again. I've started to measure the performance of jUDDI on my
particular setup which is as follows:
Server:
-Latest juddi running on JWSDK
-HSQLDB database (using direct jdbc conection)
-All running in a quad Pentium III 500Mhz with 1GB of ram
Clients:
-I have seven distributed across US
-Use UDDI4J
-run on at least 800Mhz machines
My first test is about write performance, for this matter I downloaded
all business entities from www.xmethods.com (Total of 3272 providing 419
services) and I gave a copy of this set to all of the clients. Then I start
all the clients in parallel to publish new entities as fast as possible
while measuring throughput. Using this configuration, I can saturate all the
4 cpus of the server.
Now the results are very discouraging, the overall troughput is 10.39
publish operations per second. Any idea why am I getting such a lame
performance??? As far as I can tell the neither the DB nor the disk is the
bottleneck. It seems as if the CPU is consumed exclusively by juddi and
tomcat.
Any suggestions??? I will start benchmarking read performance today
Matias
PS: Each client only authenticates with juddi at the beginning of a
benchmark session
RE: [juddi-Developers] First performance numbers for jUDDI
Posted by Anou Manavalan <am...@sybase.com>.
I have the logtime+reqhost added in the primarykey of the table. In ASE the
datetime efficiency is to 0.003 secs. It will probably vary with other DBs
and I guess its not nice to keep it as a PK. Theoretically, it is not nice
to have a table with no PK, but for reality, it doesn't matter for MONITOR
table, so I removed the PK itself from that table.
Even though it is a really nice feature to improve performance for those who
don't care about monitoring, I made it to be turned off from the config. The
property file now has
juddi.monitor = true
juddi.monitorClass = org.juddi.monitor.jdbc.JDBCMonitor
The juddi.monitor = true can be changed to false to switch it off.
Matias,
To get rid of the error, you can remove the primary key from the MONITOR
table, or better yet, try the new files from CVS to see if it improves the
perfomance with monitor switched off.
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: Saturday, September 13, 2003 5:03 PM
To: juddi-developers@lists.sourceforge.net
Cc: steve@viens.net
Subject: RE: [juddi-Developers] First performance numbers for jUDDI
this. I bet we'll quickly identify some low-hanging fruit that will
speed things up.
This would be great!!
Can you tell me:
1. Could you define what you refer to as a "publish operation".
I call UDDI4J's save_business with a a random business that I got
from xmethods
2. Is the HSQL database on the same machine (running in the same VM)?
I have two JVMs running on a quad machine. One where JWSDK
(tomcat) and juddi are running and another one were my software and HSQLDB
are running (both JVMs are from Sun)
3. Are you using jUDDI's custom connection pooling? (i.e.
juddi.useConnectionPool=true)
Yes, and here is something interesting that I found. If I set the
number of connections to more than one I get the following type of errors.
Still I don't think that having one connection is important to performance
since HSQLDB can take several connections BUT serves one at a time (i.e it
is not multi threaded)
Here are the errors I get on tomcat's log
2003-09-12 15:18:01,329 [Thread-10] ERROR
org.juddi.function.FindBusinessFunctio
n - RegistryException: Connection is broken: Broken pipe
SOAPFault Actor: null
SOAPFault Code: null
SOAPFault String: Connection is broken: Broken pipe
[A DispositionReport was not present]
2003-09-12 15:18:01,001 [Thread-7] ERROR
org.juddi.monitor.jdbc.MonitorDAO - jav
a.sql.SQLException: Violation of unique index: SYS_PK_MONITOR in statement
[INSE
RT INTO MONITOR
(REMOTE_HOST,REQUEST_URI,CALLED_FUNCTION,AUTH_TOKEN,UDDI_VERSION
,LOG_TIME,FAULT) VALUES
('128.42.6.145','/inquiry','find_business','','2.0','200
3-09-12 15:18:00.996','')]
2003-09-12 15:18:01,003 [Thread-7] ERROR
org.juddi.monitor.jdbc.JDBCMonitor - Re
gistryException: Violation of unique index: SYS_PK_MONITOR in statement
[INSERT
INTO MONITOR
(REMOTE_HOST,REQUEST_URI,CALLED_FUNCTION,AUTH_TOKEN,UDDI_VERSION,LO
G_TIME,FAULT) VALUES
('128.42.6.145','/inquiry','find_business','','2.0','2003-0
9-12 15:18:00.996','')]
SOAPFault Actor: null
SOAPFault Code: null
SOAPFault String: Violation of unique index: SYS_PK_MONITOR in statement
[INSER
T INTO MONITOR
(REMOTE_HOST,REQUEST_URI,CALLED_FUNCTION,AUTH_TOKEN,UDDI_VERSION,
LOG_TIME,FAULT) VALUES
('128.42.6.145','/inquiry','find_business','','2.0','2003
-09-12 15:18:00.996','')]
[A DispositionReport was not present]
Reading here
http://hsqldb.sourceforge.net/doc/hsqlAdvancedGuide.html learnt that
creating sort lived connection quickly will cause problems with HSQLDB.
Therefore I think that one persistent connection would be the best setup.
4. Are you building jUDDI from the source in CVS or using 0.8.0
binary download?
I'm using Thursday's CVS image
5. What Log4j logging level do you have set (in log4j.properties)?
log4j.rootCategory=WARN, LOGFILE
log4j.logger.org.apache.axis.enterprise=FATAL, CONSOLE
and no debug
It might be worthwhile to see if changing to a later release of Axis (a
nightly build) would have any effect on your numbers.
I tried with today's cvs image on both juddi and uddi4j and I got
no difference
Here are all the tests that I've done so far, I guess that you
will be interested on the total throughput numbers for read/write with only
one server (and severa clients and client threads). The for multiple servers
is because I'm using HSQLDB/R to have single distributed DB across all the
juddi servers
read
using 3 jdbc connection from 4x5 clients to 1 server around 21.82
find business per sec
using 1 jdbc connection from 4x7 clients to 3 server
avg client throughput (req/sec) 2.0600834352134
total throughput (req/sec) 57.5298238035347
write
using 1 jdbc connection from 1x7 clients to 1 server
avg client throughput (req/sec) 1.14207052535533
total throughput (req/sec) 7.97256039717822
using 1 jdbc connection from 4x7 clients to 3 server
avg client throughput (req/sec) 1.09666880134624
total throughput (req/sec) 24.1267136296172
By looking at the CPU usage and disk usage on the clients and the
servers I believe that juddi is the bottleneck of my configuration. For
example I did a test in which my clients request the happyjuddi.jsp page and
I get a throughput of 1000 req/seq, but when I bring UDDI4J and JUDDI into
play the throughput falls as shown before.
What is juddi doing for example on a publish??
Thanks
Matias
BTW: My read test consists of doing a find_business on a articular
business name with exact match.
Steve
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net] On Behalf Of
Francisco Matias Cuenca-Acuna
Sent: Thursday, September 11, 2003 9:17 AM
To: juddi-developers@lists.sourceforge.net
Subject: [juddi-Developers] First performance numbers for jUDDI
Hi again. I've started to measure the performance of jUDDI on my
particular setup which is as follows:
Server:
-Latest juddi running on JWSDK
-HSQLDB database (using direct jdbc conection)
-All running in a quad Pentium III 500Mhz with 1GB of ram
Clients:
-I have seven distributed across US
-Use UDDI4J
-run on at least 800Mhz machines
My first test is about write performance, for this matter I
downloaded all business entities from www.xmethods.com (Total of 3272
providing 419
services) and I gave a copy of this set to all of the clients. Then I
start all the clients in parallel to publish new entities as fast as
possible while measuring throughput. Using this configuration, I can
saturate all the 4 cpus of the server.
Now the results are very discouraging, the overall troughput is
10.39 publish operations per second. Any idea why am I getting such a
lame performance??? As far as I can tell the neither the DB nor the disk
is the bottleneck. It seems as if the CPU is consumed exclusively by
juddi and tomcat.
Any suggestions??? I will start benchmarking read performance today
Matias
PS: Each client only authenticates with juddi at the beginning of a
benchmark session
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
juddi-developers mailing list juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
juddi-developers mailing list
juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers
RE: [juddi-Developers] First performance numbers for jUDDI
Posted by Francisco Matias Cuenca-Acuna <mc...@matiascuenca.com.ar>.
>this. I bet we'll quickly identify some low-hanging fruit that will
>speed things up.
This would be great!!
>Can you tell me:
>
> 1. Could you define what you refer to as a "publish operation".
I call UDDI4J's save_business with a a random business that I got
from xmethods
> 2. Is the HSQL database on the same machine (running in the same VM)?
I have two JVMs running on a quad machine. One where JWSDK
(tomcat) and juddi are running and another one were my software and HSQLDB
are running (both JVMs are from Sun)
> 3. Are you using jUDDI's custom connection pooling? (i.e.
>juddi.useConnectionPool=true)
Yes, and here is something interesting that I found. If I set the
number of connections to more than one I get the following type of errors.
Still I don't think that having one connection is important to performance
since HSQLDB can take several connections BUT serves one at a time (i.e it
is not multi threaded)
Here are the errors I get on tomcat's log
2003-09-12 15:18:01,329 [Thread-10] ERROR
org.juddi.function.FindBusinessFunctio
n - RegistryException: Connection is broken: Broken pipe
SOAPFault Actor: null
SOAPFault Code: null
SOAPFault String: Connection is broken: Broken pipe
[A DispositionReport was not present]
2003-09-12 15:18:01,001 [Thread-7] ERROR org.juddi.monitor.jdbc.MonitorDAO
- jav
a.sql.SQLException: Violation of unique index: SYS_PK_MONITOR in statement
[INSE
RT INTO MONITOR
(REMOTE_HOST,REQUEST_URI,CALLED_FUNCTION,AUTH_TOKEN,UDDI_VERSION
,LOG_TIME,FAULT) VALUES
('128.42.6.145','/inquiry','find_business','','2.0','200
3-09-12 15:18:00.996','')]
2003-09-12 15:18:01,003 [Thread-7] ERROR org.juddi.monitor.jdbc.JDBCMonitor
- Re
gistryException: Violation of unique index: SYS_PK_MONITOR in statement
[INSERT
INTO MONITOR
(REMOTE_HOST,REQUEST_URI,CALLED_FUNCTION,AUTH_TOKEN,UDDI_VERSION,LO
G_TIME,FAULT) VALUES
('128.42.6.145','/inquiry','find_business','','2.0','2003-0
9-12 15:18:00.996','')]
SOAPFault Actor: null
SOAPFault Code: null
SOAPFault String: Violation of unique index: SYS_PK_MONITOR in statement [INSER
T INTO MONITOR
(REMOTE_HOST,REQUEST_URI,CALLED_FUNCTION,AUTH_TOKEN,UDDI_VERSION,
LOG_TIME,FAULT) VALUES
('128.42.6.145','/inquiry','find_business','','2.0','2003
-09-12 15:18:00.996','')]
[A DispositionReport was not present]
Reading here
http://hsqldb.sourceforge.net/doc/hsqlAdvancedGuide.html learnt that
creating sort lived connection quickly will cause problems with HSQLDB.
Therefore I think that one persistent connection would be the best setup.
> 4. Are you building jUDDI from the source in CVS or using 0.8.0
>binary download?
I'm using Thursday's CVS image
> 5. What Log4j logging level do you have set (in log4j.properties)?
log4j.rootCategory=WARN, LOGFILE
log4j.logger.org.apache.axis.enterprise=FATAL, CONSOLE
and no debug
>It might be worthwhile to see if changing to a later release of Axis (a
>nightly build) would have any effect on your numbers.
I tried with today's cvs image on both juddi and uddi4j and I got
no difference
Here are all the tests that I've done so far, I guess that you
will be interested on the total throughput numbers for read/write with only
one server (and severa clients and client threads). The for multiple
servers is because I'm using HSQLDB/R to have single distributed DB across
all the juddi servers
read
using 3 jdbc connection from 4x5 clients to 1 server around 21.82
find business per sec
using 1 jdbc connection from 4x7 clients to 3 server
avg client throughput (req/sec) 2.0600834352134
total throughput (req/sec) 57.5298238035347
write
using 1 jdbc connection from 1x7 clients to 1 server
avg client throughput (req/sec) 1.14207052535533
total throughput (req/sec) 7.97256039717822
using 1 jdbc connection from 4x7 clients to 3 server
avg client throughput (req/sec) 1.09666880134624
total throughput (req/sec) 24.1267136296172
By looking at the CPU usage and disk usage on the clients and the
servers I believe that juddi is the bottleneck of my configuration. For
example I did a test in which my clients request the happyjuddi.jsp page
and I get a throughput of 1000 req/seq, but when I bring UDDI4J and JUDDI
into play the throughput falls as shown before.
What is juddi doing for example on a publish??
Thanks
Matias
BTW: My read test consists of doing a find_business on a articular business
name with exact match.
>Steve
>
>-----Original Message-----
>From: juddi-developers-admin@lists.sourceforge.net
>[mailto:juddi-developers-admin@lists.sourceforge.net] On Behalf Of
>Francisco Matias Cuenca-Acuna
>Sent: Thursday, September 11, 2003 9:17 AM
>To: juddi-developers@lists.sourceforge.net
>Subject: [juddi-Developers] First performance numbers for jUDDI
>
>
> Hi again. I've started to measure the performance of jUDDI on my
>particular setup which is as follows:
>
>Server:
>
> -Latest juddi running on JWSDK
>
> -HSQLDB database (using direct jdbc conection)
>
> -All running in a quad Pentium III 500Mhz with 1GB of ram
>
>Clients:
>
> -I have seven distributed across US
>
> -Use UDDI4J
>
> -run on at least 800Mhz machines
>
>
>
> My first test is about write performance, for this matter I
>downloaded all business entities from www.xmethods.com (Total of 3272
>providing 419
>services) and I gave a copy of this set to all of the clients. Then I
>start all the clients in parallel to publish new entities as fast as
>possible while measuring throughput. Using this configuration, I can
>saturate all the 4 cpus of the server.
>
>
>
> Now the results are very discouraging, the overall troughput is
>10.39 publish operations per second. Any idea why am I getting such a
>lame performance??? As far as I can tell the neither the DB nor the disk
>is the bottleneck. It seems as if the CPU is consumed exclusively by
>juddi and tomcat.
>
>
>
> Any suggestions??? I will start benchmarking read performance today
>
>
>
> Matias
>
>
>
>PS: Each client only authenticates with juddi at the beginning of a
>benchmark session
>
>
>
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf _______________________________________________
>juddi-developers mailing list juddi-developers@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/juddi-developers
>
>
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>juddi-developers mailing list
>juddi-developers@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/juddi-developers
[juddi-Developers] Mmm something broke
Posted by Francisco Matias Cuenca-Acuna <mc...@matiascuenca.com.ar>.
Steve & Anou: I'm trying to do some of the stuff that you
suggested to try to improve performance. I did a CVS update today, but I
found that new my tests are not running. I'm getting this message on the
server side
2003-09-17 17:35:40,023 [Thread-13] INFO org.juddi.util.Loader - Using the
Conte
xt ClassLoader
2003-09-17 17:35:40,029 [Thread-13] WARN org.juddi.util.Loader - Failed to
load
the class with context class loader java.lang.ClassNotFoundException: false
2003-09-17 17:35:40,029 [Thread-13] INFO org.juddi.util.Loader - Using the
Syste
m ClassLoader
2003-09-17 17:35:40,030 [Thread-13] WARN org.juddi.util.Loader - Failed to
load
the class with system class loader java.lang.ClassNotFoundException: false
and this on the client side
java.sql.SQLException: No suitable driver
I guess that you have changed something and now the hsqldb.jar
file (located under juddi.war/WEB-INF/lib/) is not being loaded any more.
Any ideas on how to fix this??
Also, I have a question about juddy / log4j / tomcat 5. I've set
the following on log4j.properties.
log4j.debug
log4j.appender.LOGFILE.File=/tmp/juddi.log
log4j.rootCategory=DEBUG, LOGFILE
Still nothing is being logged. Can I somehow being overriding this
directive from Tomcat?? (without me realizing)
Here are some answers to previous emails
>Any chance you could configure jUDDI to use connection pooling available
>through Tomcat's Administrative interface (i.e. create a jUDDI DataSource)
>to see if that has any effect on performance?
No, this would be hard because my infrastructure is deploying
tomcat and for this I'll have to ship it with hsqldb and the data source
built into tomcat
>Connection pooling can help you in keeping the connection open BUT I think
>the real performance problem could be the DB being used ( just my guess,
>want to try Sybase DB ;-).
>
>And I think performance numbers for jUDDI should be made along with the DB
>performance numbers too. It is really nice that you are trying it out,
>that awakens us to focus more on that :-)
No doubt about this, but from reading posts on the hsqldb
developer's list, their DB seems fast enough to blame juddi at this point.
Ultimately I believe the DB should become the bottleneck, unless all the
xml and soap fluff needed in juddi kills the CPU on servers with all
running on one machine/CPU.
I was thinking about modifying juddi to return an empty set on
find_bussines and this way measure the overhead introduced by
UDDI4J->SOAP->network->Catalina->Tomcat->AXIS->parsing->juddi. Is there
something already there to test this?
Thanks for your help
Matias
PS: I'm CCing you directly because sourceforge lists seems to be flaky and
sometime it takes 24 hours for my message to show up
RE: [juddi-Developers] First performance numbers for jUDDI
Posted by Steve Viens <st...@viens.net>.
Matias,
It just occurred to me that there were some posts to the axis-users
lists back in June-July about performance problems with Axis 1.1 final
(which is what the currently release of jUDDI uses for it's SOAP
transport).
http://marc.theaimsgroup.com/?l=axis-user&m=105905412203161&w=2
It might be worthwhile to see if changing to a later release of Axis (a
nightly build) would have any effect on your numbers.
Steve
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net] On Behalf Of
Francisco Matias Cuenca-Acuna
Sent: Thursday, September 11, 2003 9:17 AM
To: juddi-developers@lists.sourceforge.net
Subject: [juddi-Developers] First performance numbers for jUDDI
Hi again. I've started to measure the performance of jUDDI on my
particular setup which is as follows:
Server:
-Latest juddi running on JWSDK
-HSQLDB database (using direct jdbc conection)
-All running in a quad Pentium III 500Mhz with 1GB of ram
Clients:
-I have seven distributed across US
-Use UDDI4J
-run on at least 800Mhz machines
My first test is about write performance, for this matter I
downloaded all business entities from www.xmethods.com (Total of 3272
providing 419
services) and I gave a copy of this set to all of the clients. Then I
start all the clients in parallel to publish new entities as fast as
possible while measuring throughput. Using this configuration, I can
saturate all the 4 cpus of the server.
Now the results are very discouraging, the overall troughput is
10.39 publish operations per second. Any idea why am I getting such a
lame performance??? As far as I can tell the neither the DB nor the disk
is the bottleneck. It seems as if the CPU is consumed exclusively by
juddi and tomcat.
Any suggestions??? I will start benchmarking read performance today
Matias
PS: Each client only authenticates with juddi at the beginning of a
benchmark session
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
juddi-developers mailing list juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers
RE: [juddi-Developers] First performance numbers for jUDDI
Posted by Steve Viens <st...@viens.net>.
Matias,
Not much has been done to measure jUDDI performance to date. I'll be
very interested in what you discover and very happy to help to improve
this. I bet we'll quickly identify some low-hanging fruit that will
speed things up.
Can you tell me:
1. Could you define what you refer to as a "publish operation".
2. Is the HSQL database on the same machine (running in the same VM)?
3. Are you using jUDDI's custom connection pooling? (i.e.
juddi.useConnectionPool=true)
4. Are you building jUDDI from the source in CVS or using 0.8.0
binary download?
5. What Log4j logging level do you have set (in log4j.properties)?
Steve
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net] On Behalf Of
Francisco Matias Cuenca-Acuna
Sent: Thursday, September 11, 2003 9:17 AM
To: juddi-developers@lists.sourceforge.net
Subject: [juddi-Developers] First performance numbers for jUDDI
Hi again. I've started to measure the performance of jUDDI on my
particular setup which is as follows:
Server:
-Latest juddi running on JWSDK
-HSQLDB database (using direct jdbc conection)
-All running in a quad Pentium III 500Mhz with 1GB of ram
Clients:
-I have seven distributed across US
-Use UDDI4J
-run on at least 800Mhz machines
My first test is about write performance, for this matter I
downloaded all business entities from www.xmethods.com (Total of 3272
providing 419
services) and I gave a copy of this set to all of the clients. Then I
start all the clients in parallel to publish new entities as fast as
possible while measuring throughput. Using this configuration, I can
saturate all the 4 cpus of the server.
Now the results are very discouraging, the overall troughput is
10.39 publish operations per second. Any idea why am I getting such a
lame performance??? As far as I can tell the neither the DB nor the disk
is the bottleneck. It seems as if the CPU is consumed exclusively by
juddi and tomcat.
Any suggestions??? I will start benchmarking read performance today
Matias
PS: Each client only authenticates with juddi at the beginning of a
benchmark session
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
juddi-developers mailing list juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers