On Sun, 2006-05-21 at 07:57 -1000, Chuck Williams wrote: > Oleg, > > Thanks for doing this! Is your code committed or posted somewhere? > Please let me know when and where I can obtain it for testing, and to > create a resource-manageable http server based on it.
I plat to create a Jira ticket and attach a patch to it. I just would like to run a few more performance benchmarks. The current version of SimpleHttpServer keeps on falling flat every time I am trying to put some load on it with the HTTP benchmarking tool. At some point I'll just give up. > > In your benchmark below for Axis2's current SimpleHttpServer, note > these two lines: > > Complete requests: 1500 > > Failed requests: 1500 > This does not seem right, and the results seem too slow. Is there > perhaps an error in your test code generating faults? This is the stock version of SimpleHttpServer. There's no test code involved at all. It basically appears to drop connection on every second request when bombarded with requests in a tight loop, hence the serious performance degradation. > > Re. the 202 issue, if only used for in-only messages, then the > responses are always empty. Could you use this to provide streaming > for non-empty responses? I do not see a way to tell those messages apart at the HTTP transport level. That's the trouble. Oleg > > Chuck > > > Oleg Kalnichevski wrote on 05/20/2006 12:40 PM: > > On Sat, 2006-05-20 at 18:30 -0400, Davanum Srinivas wrote: > > > > > Oleg, > > > > > > We use it for one-way/async scenarios. Example see here: > > > http://www.w3.org/2002/ws/addr/testsuite/exchanges/#SOAP11-HTTP-In-Only > > > > > > there are more patters on that page... > > > > > > > > > > I see. Is there a change to find out whether a message falls into the > > one-way/async category before it gets fed into > > HTTPTransportUtils#processHTTPPostRequest() method? I am just trying to > > see if there is a way to avoid response content buffering for > > synchronous scenarios. > > > > Cheers, > > > > Oleg > > > > > > > thanks, > > > dims > > > > > > On 5/20/06, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > > > > > > Davanum, et al (sorry about my previous message), > > > > > > > > I took at the first stub at the rewrite of the SimpleHTTPServer based on > > > > HttpComponents HttpCore and got it (more or less) functional. In fact I > > > > appears to be holding up quite well. > > > > > > > > Judging by some _very_ _preliminary_ results SimpleHTTPServer got quite > > > > a bit faster when streaming out schema definitions and similar stuff > > > > [1]. > > > > > > > > One thing bothers me, though. From what I read in the code (I may well > > > > be wrong) it appears Axis2 must always buffer the response content in > > > > order to be able to determine what status code needs to be sent back to > > > > the user 200 (OK) or 202 (Accepted) > > > > > > > > ====================== > > > > Object contextWritten = null; > > > > if (operationContext != null) { > > > > contextWritten = > > > > operationContext.getProperty(Constants.RESPONSE_WRITTEN); > > > > } > > > > if ((contextWritten != null) && > > > > Constants.VALUE_TRUE.equals(contextWritten)) { > > > > response.setStatusLine(new StatusLine(ver, 200, "OK")); > > > > } else { > > > > response.setStatusLine(new StatusLine(ver, 202, "OK")); > > > > } > > > > ====================== > > > > > > > > What's the reason for that? What's the purpose of sending 202 back to > > > > the user? This effectively prevents me from being able to stream out > > > > response content, which has a negative impact on performance of the HTTP > > > > transport. > > > > > > > > Cheers, > > > > > > > > Oleg > > > > > > > > [1] > > > > SimpleHttpServer in Axis2 1.0 > > > > ============================= > > > > [EMAIL PROTECTED]:~/src/apache.org/jakarta/httpcomponents/httpcore$ java > > > > -cp /opt/libjava/commons-cli.jar:bin > > > > org.apache.http.contrib.benchmark.HttpBenchmark -k -n 3000 > > > > http://localhost:8080/axis2/services/MyService?xsd > > > > Server Software: null > > > > Server Hostname: localhost > > > > Server Port: 8080 > > > > > > > > Document Path: /axis2/services/MyService > > > > Document Length: 314 bytes > > > > > > > > Time taken for tests: 152.884 seconds > > > > Complete requests: 1500 > > > > Failed requests: 1500 > > > > Content transferred: 471000 bytes > > > > Requests per second: 9.81136 [#/sec] (mean) > > > > Time per request: 101.92267 [ms] (mean) > > > > > > > > SimpleHttpServer based on HttpCore and Axis SVN trunk > > > > ===================================================== > > > > [EMAIL PROTECTED]:~/src/apache.org/jakarta/httpcomponents/httpcore$ java > > > > -cp /opt/libjava/commons-cli.jar:bin > > > > org.apache.http.contrib.benchmark.HttpBenchmark -k -n 3000 > > > > http://localhost:8080/axis2/services/MyService?xsd > > > > Server Software: Simple-Server/1.1 > > > > Server Hostname: localhost > > > > Server Port: 8080 > > > > > > > > Document Path: /axis2/services/MyService > > > > Document Length: 314 bytes > > > > > > > > Time taken for tests: 1.752 seconds > > > > Complete requests: 3000 > > > > Failed requests: 0 > > > > Content transferred: 942000 bytes > > > > Requests per second: 1712.3287 [#/sec] (mean) > > > > Time per request: 0.584 [ms] (mean) > > > > > > > > > > > > > > > > On Sat, 2006-05-20 at 22:17 +0200, Oleg Kalnichevski wrote: > > > > > > > > > Davanum, et al, > > > > > > > > > > I took at the first stub at the rewrite of the SimpleHTTPServer > > > > > > > > > > > > > > > > > > > > On Thu, 2006-05-18 at 11:07 -1000, Chuck Williams wrote: > > > > > > > > > > > Thanks Oleg. I'll exercise your code, report issues, provided > > > > > > patches, > > > > > > etc., as soon as it is available. > > > > > > > > > > > > I need some features that might not be available in a simple > > > > > > implementation, primarily the ability to control a set of thread > > > > > > pools > > > > > > assigned to different operations. E.g., I've got a bunch of quick > > > > > > small > > > > > > operations and a few big slow ones. I need to limit the processing > > > > > > of > > > > > > the large ones so that reading and processing the incoming messages > > > > > > does > > > > > > not run the jvm out of memory or cause performance issues, while > > > > > > allowing the small ones to get through at high priority. In > > > > > > general, > > > > > > I'd like to be able to control the allocation of incoming messages > > > > > > to > > > > > > threads in operation-dependent thread pools, limit the threads in > > > > > > the > > > > > > each pool, and relatively prioritize the pools. > > > > > > > > > > > > This might have architectural implications has the dispatching > > > > > > needs to > > > > > > be done to determine the operation and thereby select the thread > > > > > > pool. > > > > > > It is essential that the reading of messages be performed by the > > > > > > axis2 > > > > > > message receivers so the large ones can be streamed through. > > > > > > Ideally, > > > > > > the sizes of the thread pools could be varied dynamically, so that > > > > > > for > > > > > > example a particularly large message could prevent other threads > > > > > > from > > > > > > being assigned until it completes; however, I can provide the > > > > > > dynamic > > > > > > size-based resource control in the app even with fixed size thread > > > > > > pools. Even without operation-based thread pools, so long as the > > > > > > messages are not read by the http client, I could implement this > > > > > > mechanism as a secondary thread assignment in the app. > > > > > > > > > > > > I'd be happy to add support for this kind of functionality if not > > > > > > part > > > > > > of the core package. > > > > > > > > > > > > Chuck > > > > > > > > > > > > > > > > > > Oleg Kalnichevski wrote on 05/18/2006 10:54 AM: > > > > > > > > > > > > > Chuck Williams wrote: > > > > > > > > > > > > > > > robert burrell donkin wrote on 05/18/2006 07:56 AM: > > > > > > > > > > > > > > > > > On 5/18/06, *Davanum Srinivas* <[EMAIL PROTECTED] > > > > > > > > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > > > > > > > > > > > > > <snip> > > > > > > > > > > > > > > > > > > The long term plan is to use HttpCore in HttpComponents. > > > > > > > > > See > > > > > > > > > thread: > > > > > > > > > > > > > > > > > > http://marc.theaimsgroup.com/?l=axis-dev&w=2&r=1&s=httpcomponents&q=b > > > > > > > > > > > > > > > > > > <http://marc.theaimsgroup.com/?l=axis-dev&w=2&r=1&s=httpcomponents&q=b> > > > > > > > > > > > > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > > > this will happen all the more quickly if contributors step > > > > > > > > > up and > > > > > > > > > lend a hand. > > > > > > > > > > > > > > > > > > chuck - sounds you like you have a real itch: want to help us > > > > > > > > > scratch it? > > > > > > > > > > > > > > > > > Yes, I do. Unlike some others on the list, I need to deliver a > > > > > > > > robust product using axis2 in just a few months. I chose axis2 > > > > > > > > because of its architecture, basis in stax, support for > > > > > > > > streaming, > > > > > > > > and position to be the Java soap platform of the future, but I > > > > > > > > need > > > > > > > > to make my use of it solid now. I have a dedicated soap service > > > > > > > > component and definitely want to use a thin built-in http server > > > > > > > > rather than say a full tomcat installation. > > > > > > > > > > > > > > > > Robert, are you connected with HttpCore? Do you know if I > > > > > > > > could grab > > > > > > > > it now and create a replacement for SimpleHTTPServer and friends > > > > > > > > based on it? Are there others with a similar need now who want > > > > > > > > to > > > > > > > > coordinate/collaborate? I don't mind fixing some bugs or > > > > > > > > adding a > > > > > > > > few features along the way, as I'm doing with axis2. > > > > > > > > > > > > > > > > Chuck > > > > > > > > > > > > > > > Chuck, > > > > > > > > > > > > > > You can find some info on the HttpComponents project here: > > > > > > > http://jakarta.apache.org/httpcomponents/index.html > > > > > > > > > > > > > > I'll throw together a drop-in replacement for SimpleHTTPServer > > > > > > > based > > > > > > > on HttpCore this weekend and post a patch against Axis2 SVN trunk. > > > > > > > Essentially this is all it takes to create a simple HTTP server > > > > > > > based > > > > > > > on HttpCore: > > > > > > > http://svn.apache.org/repos/asf/jakarta/httpcomponents/httpcore/trunk/src/examples/org/apache/http/examples/ElementalHttpServer.java > > > > > > > > > > > > > > > > > > > > > It will be hugely appreciated if you could help me test it and > > > > > > > see how > > > > > > > well (or badly) it fares. > > > > > > > > > > > > > > Mind you, HttpCore is still an early ALPHA. We are not prepared to > > > > > > > freeze the API yet. However, it is very much the proverbial > > > > > > > chicken > > > > > > > and egg situation: the more people start testing HttpCore in real > > > > > > > life > > > > > > > applications and give us feedback the sooner we can finalize the > > > > > > > API > > > > > > > and stabilize the code. > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > Oleg > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] For > > > > > > > > additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
