have a performance advantage - at
least out of the box without any tweaking or special options.
Best regards,
*---*--*
| Jon Barnett |
| E-Mail: [EMAIL PROTECTED
://www.amitysolutions.com.au/documents/URLRewriting-technote.pdf.
Best regards,
*---*--*
| Jon Barnett |
| E-Mail: [EMAIL PROTECTED] |
| Homepage
.
*---*--*
| Jon Barnett |
| E-Mail: [EMAIL PROTECTED] |
| Homepage: http://www.amitysolutions.com.au Date: 16.11.2003 |
| |
| Is he
process, some preparation work and where to copy the files
afterwards.
It is available at
http://www.amitysolutions.com.au/documents/JBossJetty4.2.14-technote.pdf
Hope it helps.
*---*--*
| Jon Barnett
.
*-**
| Jon Barnett |
| E-Mail: [EMAIL PROTECTED] |
| Homepage: http://www.amitysolutions.com.auDate: 28.10.2003
,
*-**
| Jon Barnett |
| E-Mail: [EMAIL PROTECTED] |
| Homepage: http://www.amitysolutions.com.auDate: 26.10.2003
,
*-**
| Jon Barnett |
| E-Mail: [EMAIL PROTECTED] |
| Homepage: http://www.amitysolutions.com.auDate: 25.10.2003
AJP13 is used for web server - servlet container communication. You use
this with a JK/JK2 connector on the web server (mod_jk/mod_jk2 for Apache,
with similar connectors for IIS, iPlanet and so on). This allows the web
server to forward web requests to the back-end Tomcat or Jetty for
content. So
Have you tried the following?
1) Build an optimized version of JBoss.
2) Used different JVMs - IBM SDK best on Linux. YMMV.
3) Check GC with -verbose:gc and tune accordingly - there has been one
report that a Sun JVM distributed GC performed full GC with RMI operations
on every collection cycle,
This has to do with the Linux thread/process model. Under Linux, each
thread is represented as a process. You can update your process utilities,
psutils to the latest package and they will list a single process for your
JBoss run-time. With your current utilities, you can ps aux and see that
the
Sorry. I was using Jetty terminology. I meant connectors for handling web
requests. So if you are not using the AJP13 connector, comment it out if
it hasn't been already.
One thing about the servlet containers. I couldn't be sure that the
pre-built Tomcat and Jetty bundles are optimized so you
Tim,
Good to hear the problem has been resolved. I'll have to note the issue
with stored procedures.
With regards to your commit problems, Postgresql does not like receiving a
commit when no transactions are queued. From memory, I think the JBoss
transaction manager generates a commit when the
Have you logged information on pool sizes, bean lifecycles (particularly
for the stateful session beans) and so on? You'll probably want to monitor
activity on the servlets as well - session expiry probably being an
important event. No session expiry on servlets results in a memory leak.
The
This is a native method error on your Sparc system. Have you applied the
appropriate patches to your OS as per Sun recommendations for the Sparc
platform re:J2SE?
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/J2SE
Regards,
JonB
-Original Message-
From: [EMAIL PROTECTED]
The bug is rather minor in the scheme of things. We've tested JBoss under
load with ECperf using this configuration (IBM SDK 1.4.1) and it works
fine. We've also had installations running for longer than a month with
the new SDK (switching from IBM SDK 1.4.0).
As Adrian notes, it does mean that
Most JVMs only set aside a heap with a maximum of 16M (I think). This is
the play area for your objects so it seems you are exceeding that. Add to
your JAVA_OPTS something like -Xmx64m or an appropriate amount - you'll
need to figure out just how much heap you will need.
You can check the meaning
In the forums, people have asked a few times about installing Axis in
JBoss. There are a variety of reasons people will choose this over
JBoss.NET - we do it so we can migrate between different app servers as
well as onto standalone Tomcat configurations. It makes it easier for us
since not every
It's a fault in the IBM LinkedList implementation.
Regards,
JonB
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Rafal
Kedziorski
Sent: Saturday, 9 August 2003 1:02 AM
To: [EMAIL PROTECTED]
Subject: [JBoss-user] Exception from JBoss 3.2.2RC2
hi,
JBoss proper plays little direct role in the rendering of WAP content.
This is really governed by your web-application configuration. The steps
are the same regardless of the servlet container although execution may
change slightly.
1. Add the mime-types for serving static content (if your web
The other problem with BLOBs in the entity table is the actual SQL. This
has a large impact on your retrieval speed. Even if you do not materialise
the binary data into a Java object, on the database side of things, if the
BLOB column is included in the query, the time to perform the select can
We had another good question about performance comparisons with regard to
our study. As we have maintained, we have not attempted to produce a head
to head comparison. JVMs execute code differently and we wanted to be free
of such direct comparisons. We were more interested in the parallel
Having discovered a problem with expectations on the JVM, we revisited our
original tests and invoked some GC settings. It returned a response curve
that was in line with our original expectations. It also highlights the
importance of the GC implementation.
There were a few strange test
If you look at the Appendix D results, the first section shows the
toggling of the new parallel GC and concurrent mark/sweep algorithms.
Section 1.3.1 mentions that we employ server mode for JVMs. This second
one is also important because it limits the variance in results you get
from a
Yes. I know Mercury Interactive costs a lot. We've seen clients who want
guarantees on performance for the commercial application servers but balk
when you tell them the cost of Mercury Interactive.
For a load tool to rival Mercury Interactive, I'd probably suggest looking
at something like
I'm not sure I fully understand what you are driving at so let me try and
paraphrase your question and answer that. You can come back and tell me
I've misinterpreted it. ;)
Should someone developing J2EE applications for deployment on JBoss
require the JBoss source code?
There is usually no need
OK. I think I understand. Do you need to produce internal builds for
reference on different OS/JDK combinations and should you build your own
binary distribution from the source?
Generally not. Things are pretty much going to work as is on any system
for the binary distribution - hopefully that
OK. I can see the focus on cluster rollover. ;)
We have conducted tests in a similar manner to queuing requests remotely.
You can create a stateless EJB to make remote and local calls to itself
(or other EJBs) as well as naming server lookups. If you look at our JBoss
performance paper you'll see
Just my two bits worth again -
I guess fully built applications are fine for exercising the entire app
server or as much as you can make it exercise the entire app server, and
perhaps I focus on the micro-level a bit too much but:
The high level testing view doesn't tell you individual breaking
As some people have asked about more complex loads, we provide an example
that first lead us to investigate the issue of performance. With a
multi-CPU system at our disposal, we should be able to generate a lookup
load and a remote invocation load using multiple threads and measure
throughput.
Kevin, Bela;
First thanks for the offer of help, Bela. Being downunder, sometimes you
feel a bit isolated - where is the Australian JBoss user community? ;)
Anyway, I'm not sure where things are headed with testing but help is
always appreciated.
The testing question is a big one. It depends on
We side-tracked slightly while looking at JBoss performance. We noticed
some noticeable variations in response times and significant enough
changes in throughput to question our assumptions about thread performance
in a multiprocessor environment.
The results of our investigation of Java threads
After working all weekend on some load testing with JBoss (thanks to the
JBoss Group, LLC) - we came to a few conclusions. The IBM SDK 1.4.0 breaks
remarkably quickly under load - for ECperf 1.1 the JBoss/IBM JVM hit 100%
CPU at txRate=3 and subsequently failed response times whereas the Sun JDK
smime.p7m
Description: S/MIME encrypted message
OK. This is just an update on the performance modifications. The latest
change is actually not a big one - as with most of the changes I have
implemented.
The underlying findEntities works with an ArrayList but returns a
Collection. So I changed this to return an ArrayList. The Trove benchmarks
require the user to do
ArrayList list results = (ArrayList)home.findByBlah();
??
Or are you saying the the Iterator uses get?
Thanks,
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Jon
Barnett
Sent: Friday, July 11, 2003 11:05 AM
To: [EMAIL
Version 1 of our document on some simple code improvements to JBoss 3.2.0
and the effect on performance is now available. We'll work on the document
as time allows. The current data covers performance measurements based on
Linux/IBM SDK/Trove. The document is an 820K pdf available from the
Due to ECperf use requirements, we can't report anything too concrete.
Some unofficial information :-
For ECperf 1.1 on our meagre test configuration, the standard JBoss 3.2.0
distribution fails at txRate=1 for a Sun JDK 1.4.1_01 - failures with
manufacturing and orders response times and failure
In some spare time, just wrote a simple test rig to check the performance of calls
using the optimized and Trove modified JBoss versus standard JBoss. The internal VM
calls were invoked by 3 parallel threads that had a stateless session bean look itself
up and make a single method call (that
might appreciate the immediate memory reclaim and the
reduced GC interruption later.
JonB
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Jon Barnett
Sent: Tuesday, 1 July 2003 11:57 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-user] On the performance
I'd check your initial assumption that the connection is not set to
autocommit. I think you'll find it is still in autocommit. To test, you
can set it to false before you use it.
JonB
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Karl Koster
Sent:
Actually, I didn't mean change the pool as that would change for
everything you did with connections from the pool. I meant just change it
for your local connection.
e.g. conn.setAutocommit(false);
This is code we built back in JBoss 2.2 days against Oracle - we don't
have an in-house Oracle as
Good question. I'm not saying that standard JBoss should include them. I'm
just investigating the impact.
Now the GNU projects have always been high quality, and the Trove package
seems to have reached a certain level of maturity so I feel that I can
play with the intermix just to see what
While we've got a few spare cycles, we thought to pursue this whole
performance thing some more. We grabbed hold of the GNU Trove collections
implementation and started converting 3.2.0 source to use these
collections. So far we have only done it partially in one strategic area.
Working off the
It seems you are waiting for the home interface to be bound to the JNDI.
This might be a naive question as I haven't tried creating a dependency on
an EJB, but can't you define the depend to be
jboss.j2ee:jndiName=...,service=...? I'm assuming that if the home
interface is bound that the EJB must
Don't install JBoss, or the Java JDK in any paths that contain spaces (and
if you have a separate Tomcat install, the same applies). It breaks JNDI
and RMI, and it can't be worked around (or not that I've ever found in
four years).
JonB
-Original Message-
From: [EMAIL PROTECTED]
Bill,
Thanks for clarifying that. I didn't headline it enough about the JBoss
internal optimizations on the comms for those who weren't aware of it.
The thing that was surprising to us was how well this works compared to an
explicit local call. We thought there would at least be some change in
We did some additional testing by tweaking web applications to use local
interfaces to EJBs. These comparisons were made to our performance tests
conducted earlier
(http://www.amitysolutions.com.au/downloads/JBoss_optimizations.pdf)
We found that they had little impact over the optimizations that
The J2EE standard does not mandate the use of packaging. It is just a
means of simplifying production deployment. And I agree, in the
development phase, this encourages a monolithic approach to things - which
is actually anti-J2EE because the point of having small worker units like
EJBs is that
We've updated our changes to operate with the JBoss SourceForge
distribution of ECperf 1.1. Apart from dealing with a problem we were in
the middle of fixing, the CVS had a less invasive JBoss configuration.
I hope however, that our documentation helps others walk through the
installation
Good question. I should probably add it to the documentation as a
clarifier on the optimization process.
Most of our development happens on Windows 2000 so we use the Sun JDK
libaries with Jikes for compilation of our own code. However, for the
optimization testing of JBoss, we used the Sun JDK
It basically tells the JVM to ignore OS signals, among other things. In
particular, it tells the JVM to ignore an OS shutdown signal.
See this article from IBM for all you ever wanted to know on signal
handling.
http://www-106.ibm.com/developerworks/ibm/library/i-signalhandling/
JonB
You could always move to WebSphere. I've seen that take upwards
of an hour to deploy things! :-)
--
Danny Yates
Or you could go back to the good old days, when Tomcat was in a separate
VM and you either coded in a deployment kicker or stopped, deleted the WAR
and restarted Tomcat.
I also
Using the local interface bypasses the need to use a PortableRemoteObject,
which can be quite expensive.
So the coding for local use is:
Object ref = naming.lookup(DefinitionManagerLocal);
DefinitionManagerLocalHome home = (DefinitionManagerLocalHome)ref;
DefinitionManagerLocal definitionManager
, but it does provide some feel for
the magnitude of the changes that might be achieved.
Hope it is of use.
Jon Barnett
smime.p7s
Description: S/MIME cryptographic signature
Check your security policies. See this for more information.
http://developer.java.sun.com/developer/onlineTraining/Programming/JDCBook
/appA.html
If it is an applet-based application, consider signing it. See this:
http://java.sun.com/docs/books/tutorial/security1.2/toolsign/index.html
With
In case anyone is interested, we went through trying to get ECperf 1.1
working with JBoss 3.2.0. We thought the JBoss-ECperf 1.0 kit instructions
meant it should be easy. Turned out to be a traumatic event trying to work
out what was happening and what to change. Anyway, I've made available
56 matches
Mail list logo
