Pavel, I applied these patches, but the mime sample does not work. Please get this sample working and submit a new patch.
Thanks. 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:[EMAIL PROTECTED]] > > 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:[EMAIL PROTECTED]] > > > > 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:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > -------- > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > ------------------------------------------------------------------------ -------- > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
