Scott,
I have long experience of using OptimizeIt www.optimizeIt.com (now owned by
Borland). You can download evaluation version here. I can't compare it to
other profilers (have no experience) but I think OptimizeIt absolutely
great, you only need few time to start gaining from it. For ex. it useful
even for debugging - you can count number of calls of each method and
understand that for ex. number of call of some methods is too high / too
low. Before you get some experience I would recommend you to always do
profiling in classic JVM, with Instrumentation method, with no filter
enabled (you'll found these settings if try OptimizeIt). Memory profiler is
very useful as well
ComplexRequest.java is a simple performance test class we used
Java mail is 1.2
Manifest-Version: 1.0
SCCS-ID: @(#)javamail.mf 1.4 00/09/26
Extension-Name: javax.mail
Specification-Title: JavaMail(TM) API Design Specification
Specification-Version: 1.2
Specification-Vendor: Sun Microsystems, Inc.
Implementation-Version: 1.2
Implementation-Vendor: Sun Microsystems, Inc.
Implementation-Vendor-Id: com.sun
About invoke you are absolutely right - and I also thought about having a
simple SOAPContext + some extensions for multipart, but do not have idea
how to have compatible to previous version. Maybe create some
SimpleSOAPContext and makeSOAPContext inherited from it... But even in this
case old applications mey need to be recompiled, although I do not expect
any client application to refer SOAPContext directly, but I'm not sure what
is the scenario for using attachments...
I also not sure how it would affect Mail transport.
BTW another drawback I have noticed in SOAPContext today is that it always
creates following vars, but rarely use it. If create an simple class, this
should be eliminated as well
protected Hashtable bag = new Hashtable(); // this one seems to
be used only in server responce...
protected Vector multiRef = new Vector();
protected Hashtable deserializedMultiRef = new Hashtable();
Best regards,
Pavel
> -----Original Message-----
> From: Scott Nichol [mailto:snicholnews@;scottnichol.com]
> Sent: Thursday, November 14, 2002 6:54 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Using mime parts - huge drawbacks
>
>
> Thanks for yet another valuable contribution! I've committed this
> patch. Your others will have to wait a little while since I have to
> earn some money today (instead of working on Apache SOAP).
>
> I have some questions.
>
> 1. What do you use to do this profile? I have very little experience
> with profilers, mainly with JInsight, but that was over a year ago.
>
> 2. What is "ComplexRequest"?
>
> 3. Do you know what version of JavaMail you are using?
>
> Something very interesting that I had not noticed before is that
> provider.invoke gets on the request and response contexts, so
> that even
> "plain" RPCs have their SOAP envelope put into SOAPContext and
> subsequently extracted. I am thinking that the SOAPContext
> should gain
> the ability to hold a SOAP envelope other than simply as the root part
> to avoid the expense of extracting it. In fact, SOAPContext should be
> able to keep track of whether there are any attachments versus just an
> evelope to optimize the situation where there is only an envelope. We
> would use lazy evaluation to stuff it into the root part if the root
> part is requested, but otherwise provide shortcuts to just access the
> envelope.
>
> Scott Nichol
>
> ----- Original Message -----
> From: "Pavel Ausianik" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, November 14, 2002 9:04 AM
> Subject: RE: Using mime parts - huge drawbacks
>
>
> > Scott,
> >
> > Here is server time picture taken on the Tomcat server , processing
> > ComplexRequest.
> > The red ellipses show that MimePart initialization takes 10-15% of
> CPU
> > load.
> > The blue ellipses show that ContentType is also quite expensive for
> benefits
> > it provide. I prepared patch for caching ContentType...
> >
> > Pavel
> >
> > > -----Original Message-----
> > > From: Scott Nichol [mailto:snicholnews@;scottnichol.com]
> > > Sent: Wednesday, November 13, 2002 5:48 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Using mime parts - huge drawbacks
> > >
> > >
> > > Pavel,
> > >
> > > Yes, this is a good observation. In the case where there are no
> > > attachments, the process could be streamlined by serializing
> directly.
> > > I am still actively working on this part of the code
> > > (TransportMessage,
> > > SOAPContext, Call) and will look at sidestepping some of the
> activity
> > > where there are no attachments, just a SOAP envelope, which
> > > as you point
> > > out is the typical scenario.
> > >
> > > Scott Nichol
> > >
> > > ----- Original Message -----
> > > From: "Pavel Ausianik" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Wednesday, November 13, 2002 9:04 AM
> > > Subject: Using mime parts - huge drawbacks
> > >
> > >
> > > > Hello,
> > > >
> > > > thinking more on the current code I have found interesting
> > > thing. Most
> > > > requests we have a simple, straight SOAP envelopes, without any
> > > attachments.
> > > > Looking how it is processed I have found following (traced from
> > > > httpconnection):
> > > >
> > > > In SOAPHTTPConnection.send() we call TransportMessage.save().
> > > > Let's look into it (see my comment how I understand it:
> > > >
> > > > String rootContentType = null;
> > > >
> > > > // Root Part is Not set for Simple Envelope !
> > > >
> > > > if (ctx.isRootPartSet()) {
> > > > //... Not in use for simple case
> > > > }
> > > >
> > > > if (rootContentType == null)
> > > > rootContentType =
> Constants.HEADERVAL_CONTENT_TYPE_UTF8;
> > > > if (getEnvelope() != null) {
> > > >
> > > > // Now really create root part - how important it is if we
> > > now how to
> > > write
> > > > this Envelope without involving Mime !!!
> > > >
> > > > ctx.setRootPart(envelope, rootContentType);
> > > > } else {
> > > > //... Not in use for simple case
> > > > }
> > > >
> > > > // Print the whole response to a byte array.
> > > > // Tracing into this code we'll found that all it will do it add
> > > > unnecessary header to envelope
> > > > // The headers include Content-Type - we know which is,
> > > > // Content-id - do we need it? Even if yes we can create any id
> > > > // Content-Transfer-Encoding - not for HTTp, anyway we
> force it to
> 8
> > > bit
> > > > // Content-Lenght - easy to calculate
> > > >
> > > > ByteArrayOutputStream payload =
> > > > new ByteArrayOutputStream(1024);
> > > > ctx.writeTo(payload);
> > > > bytes = payload.toByteArray();
> > > >
> > > > // Now strip off the headers. (Grmbl, get rid
> of JavaMail
> > > > // for MIME support). Just intercept the Content-Type
> > > > // Remove headers which created right now....
> > > >
> > > > ....
> > > >
> > > > // TODO: should not send for HTTP response
> > > > headers.put("Accept-Encoding", "x-gzip");
> > > > if (Boolean.TRUE.equals(ctx.getGzip())) {
> > > > // Deflate
> > > > ByteArrayOutputStream baos =
> > > > new
> > > ByteArrayOutputStream(bytes.length
> > > * 2);
> > > > GZIPOutputStream gzos = new GZIPOutputStream(baos);
> > > > gzos.write(bytes, offset, bytes.length - offset);
> > > > gzos.close();
> > > > baos.close();
> > > > bytes = baos.toByteArray();
> > > > offset = 0;
> > > >
> > > > headers.put("Content-Encoding", "x-gzip");
> > > > }
> > > >
> > > > Seems like we are doing wonderful job of running a lot
> unnecessary
> > > > operations, involving a lot of memory allocations... It
> > > could be most
> > > > advanced improvement we ever done!
> > > >
> > > > Best regards,
> > > > Pavel
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > <mailto:soap-dev-unsubscribe@;xml.apache.org>
> > > For additional commands, e-mail:
> <mailto:soap-dev-help@;xml.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
<mailto:soap-dev-unsubscribe@;xml.apache.org>
> For additional commands, e-mail: <mailto:soap-dev-help@;xml.apache.org>
>
>
------------------------------------------------------------------------
--------
> --
> To unsubscribe, e-mail: <mailto:soap-dev-unsubscribe@;xml.apache.org>
> For additional commands, e-mail: <mailto:soap-dev-help@;xml.apache.org>
--
To unsubscribe, e-mail: <mailto:soap-dev-unsubscribe@;xml.apache.org>
For additional commands, e-mail: <mailto:soap-dev-help@;xml.apache.org>
--
To unsubscribe, e-mail: <mailto:soap-dev-unsubscribe@;xml.apache.org>
For additional commands, e-mail: <mailto:soap-dev-help@;xml.apache.org>
