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>
