On 04/12/2019 02:23, Behrang Saeedzadeh wrote:
> I am not expecting it to take less time, but to provide better throughput.

Despite what you appear to think, you have written two synchronous,
blocking I/O upload servlets. Not one synchronous and one
non-synchronous. With synchronous I/O less time == more throughput.

> With 1000 concurrent users, the sync version was still performing better
> (mean req/second).

Entirely as expected.

An asynchronous approach is not magic pixie dust that automatically
improves performance. In some scenarios it will make performance
(throughput and time per request) worse.

Neither is writing an asynchronous upload servlet as simple as taking
all the code from your synchronous doPost() method and surrounding it with:
asyncContext.start(() -> {
    <original doPost() method code here>
});

All that does is start a separate thread to do the synchronous, blocking
I/O you had in the original method. i.e. more server side work to
achieve exactly the same result.

For an asynchronous file upload servlet to provide improved throughput:

1. It needs to use non-blocking I/O. Your doesn't.

2. The clients need to be sending data sufficiently slowly that a thread
reading the upload with blocking I/O spends a reasonable amount of time
blocking, waiting for more data to arrive. Your tests don't do that.

Mark

> 
> 
> Best regards,
> Behrang Saeedzadeh
> (Sent from my cellphone.)
> 
> On Mon, 2 Dec. 2019, 8:44 am Mark Thomas, <ma...@apache.org> wrote:
> 
>> On 01/12/2019 02:17, Behrang Saeedzadeh wrote:
>>
>> <snip/>
>>
>>> Any ideas what am I missing here?
>>
>> Async provides scalability, not raw performance.
>>
>> You haven't written a async file upload servlet. That would require
>> non-blocking I/O and look more like this:
>>
>> https://github.com/apache/tomcat/blob/master/webapps/examples/WEB-INF/classes/nonblocking/ByteCounter.java
>>
>> Step back from your code for a second. The async version does exactly
>> the same thing as the sync version apart from it does a bunch of *extra*
>> stuff (creating the Runnable and dispatching it to a different thread).
>> Why would you expect the code that does extra stuff, to take less time
>> when it does more?
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to