> Using sun's JDK 1.5.
Please use the latest JDK 6 versions. The performance differences
between Java 6 JVMs and JDK 1.5 JVMs is very, very different
(impressive). Whenever I see a perf test comparisons using JDK 1.5 I
immediately lose interest. By technology standards, JDK 1.5 is very old,
nearly obsolete.
I think if you update to latest Java 6 versions, you'll be very happy
with its performance.
charlie ...
Niall Gallagher wrote:
> Hi,
>
> In response to your comments.
>
>
>> I have to admit ab benchmark are not something I usually
>> like:
>>
>> http://weblogs.java.net/blog/sdo/archive/2007/05/how_to_test_con.html
>>
>> Also you just set the WorkerThread to 5 :-) How many thread
>> are you configuring with your framework? I would also like
>> to see the server and ab logs to see what is the issue.
>> Which JDK/OS are you running on? What kind of network. And
>> more important, what you framework offer in terms of http
>> :-)
>>
>
> Thanks, this is what I have been looking for.
>
> I have 5 servicing threads also, but I use an event distributor (based on the proactor pattern) which also uses 5 threads to distribute select events (both read and write). So, basically I would like the optimal Grizzly configuration. Because comparing the two based on thread count is not going to be fair as both have very different architectures.
>
> I am running on an Intel core 2 duo running linux kernel 2.6.27. Using suns JDK 1.5.
>
> My framework offers the full set of HTTP/1.1 features including.
>
> 1) asynchronous write support, similar to what grizzly 1.9 introduced, however I use fixed segment sizes rather than cloning
> 2) asynchronous execute support, as in read and write can be done on separate threads, or dispatched to any other thread of execution,
> similar but more transparent to Servlet 3.0 proposals, so read/write/execute can all be done in parallel
> 3) HTTP and HTTPS support
> 4) 100 continue
> 5) integrated multipart support including nested multipart lists
> 6) its NIO throughout but offers BIO semantics via an output stream or writable byte channel on the response
> 7) Internal file system to manage massive file uploads without blocking or exhausting memory
> 8) Leased sessions
> 9) No external depandancies, so is extremely light weight
>
>
>> Well most probably yes :-) But your goal is to claims your
>> framework is faster than Grizzly, right?
>>
>
> Well, in a way yes. But more importantly I want to get an accurate picture of how it compares to other NIO servers. I've only done comprehensive benchmarks on Jetty and AsyncWeb because Grizzly 1.8.x kept dropping connections for some reason, 1.9.x has been very robust so far. Simple beats Jetty by about 60% and AsyncWeb by about the same.
>
>
>> A lot of framework
>> did that as well, but at the end it is always quite easy to
>> run something different (like Faban above) and demonstrate
>> the contrary :-) Anyway, I'm interested helping and see
>> how it goes :-)
>>
>
> I have run a number of load testers, and have found ab is useful for a number of reasons. Importantly for NIO servers its very good at scattering load, and so causes a signifigant number of select interrupts. Some other frameworks just fill the socket with the whole scenario, and so does not reflect a real traffic profile.
>
> Niall
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>