Pavel, At first glance, this looks fantastic. You've given the added benefit of moving more of the JavaMail-related logic into SOAPContext, which is great. Why should many of these components know the least bit about JavaMail? I'll give this a more thorough look and commit as soon as I can.
Regarding the big time consumers, DocumentBulder.parse and InputStream.read are expected to be time hogs and are somewhat out of our control. For the other two, RPCMessage.extractFromEnvelope and Envelope.Marshall, do you see any improvements that can be made further down the execution path, e.g. in serializers and deserializers? Scott Nichol ----- Original Message ----- From: "Pavel Ausianik" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, November 15, 2002 9:59 AM Subject: RE: Using mime parts - huge drawbacks > > > Hi, > > I think I managed make it compatible to existing code and yet still mush > faster (8-10 sec of 60 I had in the morning ). The Mime part will be creates > as soon as it requested, otherwise plain Envelope used > Also I set up initial buffer in couple of classes... > > Please take a look > > Also, if comparing to yesterday's picture timeload, we have 4 big time > consumers, which I suppose quite logical > > 1. DocumentBulder.parse > 2. RPCMessage.extractFromEnvelope > 3. EnvelopeMaprshall > 4. InputStream.read > > 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> -- To unsubscribe, e-mail: <mailto:soap-dev-unsubscribe@;xml.apache.org> For additional commands, e-mail: <mailto:soap-dev-help@;xml.apache.org>
