Am 09.03.2016 um 10:12 schrieb Tullio Bettinazzi:
I tested with http11.Http11Protocol, http11.Http11NioProtocol and 
http11.Http11Nio2Protocol and the problem reproduces only with 
http11.Http11NioProtocol.
It seems to be a bug of the Nio protocol.
It's better to use Nio2 or standard ? What's the difference ?
Maybe Marks webinar will help you: https://www.youtube.com/watch?v=LBSWixIwMmU

On the other hand, now that you can switch the problems on and off on the server side, can you try to dig deeper into the problem? Maybe take a tcpdump from one client that has problems with the nio connector and compare that to a tcpdump from the same client to the nio2 or bio connector?

Have you identified any other commonalities between clients that expose problems with the nio connector? Browser, OS, network topology?

Regards,
 Felix

Tks
Tullio


Date: Mon, 7 Mar 2016 16:26:24 +0100
Subject: Re: Performance regression from 7 to 8
From: aterrest...@gmail.com
To: users@tomcat.apache.org

Tullio,

as suggested before by Felix, maybe you should try different connector
configurations (defaults for HTTP connector are different between T7
(blocking) and T8 (non-blocking)) and see if this changes anything.

For example in the server.xml file :

     <Connector port="8880"
protocol="org.apache.coyote.http11.Http11Protocol" address="YOURSERVER"
                connectionTimeout="20000"
                disableUploadTimeout="false"
                connectionUploadTimeout="3600000"
                redirectPort="8843" />

and

     <Connector port="8880"
protocol="org.apache.coyote.http11.Http11NioProtocol" address="YOURSERVER"
                connectionTimeout="20000"
                disableUploadTimeout="false"
                connectionUploadTimeout="3600000"
                redirectPort="8843" />


Your code is simple, only buffering and writing to an OutputStream. Don't
know how, but I believe that only the buffering can introduce some delay.

best regards






2016-03-07 15:43 GMT+01:00 Tullio Bettinazzi <tullio0...@live.it>:

As I already explained is not a reproductable problem.
I tested the testcase in my environment and I reproduced the problem on
some clients but not on all clients : the same clients where I noticed the
problem in the real application.
I'm not able to understand what's the relevant difference among them (not
OS version, not network, not browser).
The problem disappears using tomcat 7.
Tks
Tullio

Subject: Re: Performance regression from 7 to 8
To: users@tomcat.apache.org
From: ma...@apache.org
Date: Mon, 7 Mar 2016 11:52:40 +0000

On 06/03/2016 08:45, Tullio Bettinazzi wrote:
I tested with 8.20 and 8.32
With nothing changed I meant simply that results didn't change.
I can't repeat the problem you are describing with your provided test
case.
I ran:
- ab -k -n 1000 -c 1 localhost:8080/user002/Test
- latest 8.0.x code
- your test case with and without setting the content length (as an
   HTTP/1.0 client ab needs the content length to use keep-alive with
   large response bodies

I saw average response times of 6ms with a maximum of 9ms.
The content length header made no difference (apart from keep-alive
being used as expected).

If the problem you are describing was widespread I'd expect to see other
users reporting this on the mailing list.

Given that:
- I can't repeat this
- Other users aren't reporting it
- Only you are seeing the issue

this looks like an issue with your environment rather than with Tomcat.
I'd recommend using tools like Wireshark and YourKit to find out exactly
what is going on.

Mark


Tks
Tullio

Subject: Re: Performance regression from 7 to 8
To: users@tomcat.apache.org
From: ma...@apache.org
Date: Sat, 5 Mar 2016 18:40:36 +0000

On 04/03/2016 13:19, Tullio Bettinazzi wrote:
Done and nothing changed.
What has changed is that you have now provided a test case that
someone
else can run easily and confirm, or not, your findings.

Any suggestion ?
Before anyone spends time looking at this the other question I don't
see
answered in this thread is "Exactly which Tomcat 8 version were you
testing?". If it isn't the the latest then you'll need to retest to
confirm the issue hasn't already been fixed.

Mark

Here the code.

package axioma.rubik.engine.web.servlet;

import java.io.*;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.*;

@WebServlet(name="Test8", description="Direct update of data",
urlPatterns={"/Test8"})
public class Test8Servlet extends HttpServlet {

     private static final long serialVersionUID = 1L;

     @Override
     protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
         try {
             fai(response);
         } catch (Exception ex) {
             ex.printStackTrace();
         }
     }

     public void fai(HttpServletResponse response) throws IOException
{
         ByteArrayOutputStream bbs = new ByteArrayOutputStream();
         BufferedOutputStream bos = new BufferedOutputStream(bbs);
         for(int i = 0; i < 400000; i++) {
             bos.write(96);
         }
         bos.flush();
         bbs.writeTo(response.getOutputStream());
     }
}

---------------------------------------------------------------------
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


                                        


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

Reply via email to