Scott, If looking further for possible performance optimizations I see following directions:
1. In HTTPUtils.post cache all information related to URL - parsed host, port, protocol, etc, most part of the header for post. Since most client applications use a single (or at least not many) URLs to connect to server, this could save some time on the client side. Another possible improvement here - instead of creating header values as Strings from byte[] - create it from char[]. Surprisingly getting Sun's ByteToChar converter many times (for every new String() ) is not fast, requires several StringBuffer allocations and reallocations, etc. 2. Look on how we go through DOM tree. Big enough time currently is taken by may times searching from the bottom of the tree back to envelope definition for namespace. Please look at the picture attached ParameterSerializer.unmarshall is called 81 time . DOMUtils.getNamespaceURIFrom prefix is called 486 time - which I suppose occurs , because for every parameter, DOMUtils search from namespace declaration up to Envelope definition. Possible solution for this - use NSStack or similar class in unmarshall. BTW do not be mistaken by short % time for this calls, the same occurs in several branches below Envelope.unmarchall which is about 17-20% of the whole call on the client. I guess it is possible to improve it to by 2-5% . 3. :-) Look for faster DOM implementation. Actully I would say maybe we should stop on this near this point , and make release, further optimizations will not be so important in comparison to what we already have. Best regards, Pavel > -----Original Message----- > From: Scott Nichol [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 15, 2002 9:48 PM > To: [EMAIL PROTECTED] > Subject: Re: Using mime parts - huge drawbacks > > > 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:[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]> >
<<attachment: untitled.GIF>>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
