The doc (
http://tomcat.apache.org/tomcat-8.0-doc/config/http.html#NIO2_specific_configuration
) doesn't say which one is the best, but we may think that the non-blocking
will work better under heavy load.
If not servicing hundreds of clients at the same moment, I would use the
blocking connector ( http11.Http11Protocol )
regards
2016-03-09 10:12 GMT+01:00 Tullio Bettinazzi <tullio0...@live.it>:
> 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 ?
> 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
> > > >
> > >
> > >
>
>
