On 25/07/17 09:40, Mark Thomas wrote: > On 25/07/17 08:53, jianjun.guo wrote: >> In tomcat7 and earlier verison >> The response content (both response header and body) was put into one buffer >> before the context will be send to client. So final packet was sent only >> once commonly. >> >> >> In tomcat8.0, exactly, aflter svn version 1358055, the feature was removed. >> when the response was commited, the packet that only contains response header >> was send to client alonely. >> >> >> For any http request, socket write twicely at the least. > > Thanks for the further investigation. > > I've done a quick test with 9.0.x and 8.0.x and I also see this > behaviour with 8.0.x but not 9.0.x. I haven't looked deeper to see if it > is connector specific or what the root cause might be. I plan to do > that next.
I've spent some time looking into this and it does appear to be Tomcat 8.0.x specific. The connector refactoring in 8.5.x/9.0.x restored the buffering by default behaviour of 7.0.x. I've looked at the HTTP connectors, but not the AJP connectors. Of the HTTP connectors, NIO and APR look to be affected but not BIO or NIO2. The socketBuffer connector attribute only affects BIO. In theory, it should be possible to patch NIO and APR. Based on the later refactoring, the starting point is probably Internal[Nio|Apr]OutputBufer#addToBB(). Looking at a patch for this is not a priority for me at the moment although I'd be happy to review a patch if someone wanted to offer one. I think the changes can be contained to #addToBB() but that is based on a fairly quick review. I might have missed something - particularly related to non-blocking handling. Mark > > Mark > >> ------------------ Original ------------------ >> From: "Mark Thomas"<ma...@apache.org>; >> Date: Mon, Jul 24, 2017 09:02 PM >> To: "Tomcat Users List"<users@tomcat.apache.org>; >> >> Subject: Re: The performance reduce much for tomcat 8 ?? >> >> >> On 24/07/17 13:01, jianjun.guo wrote: >>> thanks for reply . >>> The same scenario and the same configuration, i test tomcat 8.0.45 and >>> tomcat 8.5.16 again. >>> tomcat 8.0.45 and tomcat8.0.32 have almost same performance?? >>> tomcat 8.5.16 and tomcat7.0.39 have almost same performance?? >>> Because my test case is very simple http request , big performance >>> fluctuation may be caused by a little synchronized operation. >>> >>> I found it thread stack the synchronized code in >>> InternalNioOutputBuffer.java: >>> private synchronized void addToBB(..)?? synchronized is must? >> >> svn blame is a useful command that can help point to the commit >> responsible for any given change. >> >> Sometimes (as in this case) you need to go back more than one change to >> the line in question to find the reason for a specific change. >> >> Alternatively, you can do the same thing via the viewvc interface. >> https://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/ >> >> Mark >> >> >>> >>> >>> i will test and verify it if the impact come from here. >>> >>> >>> Thanks. >>> >>> ------------------ Original ------------------ >>> From: "Mark Thomas"<ma...@apache.org>; >>> Date: Mon, Jul 24, 2017 04:29 PM >>> To: "Tomcat Users List"<users@tomcat.apache.org>; >>> >>> Subject: Re: The performance reduce much for tomcat 8 ?? >>> >>> >>> On 24/07/17 09:18, jianjun.guo wrote: >>>> Hi, >>>> I deployed a very simple jsp page to test the performance for tomcat7 vs >>>> tomcat8. >>>> >>>> >>>> The same scenario and the same configuration?? The TPS for tomcat7.0.39 is >>>> 8.3W, but for tomcat8.0.32 only 6.1W?? >>>> >>>> >>>> There is a big difference for them? Thanks for your help. >>> >>> It is hard to comment without knowing the details of the application >>> that was deployed. >>> >>> I don't recognise the units used for the results. >>> >>> 7.0.39 was released roughly 3 years earlier than 8.0.32. It is possible >>> that bug fixes applied to 7.0.x and 8.0.x have impacted performance in >>> some way. >>> >>> It is also over a year since 8.0.32 was released. Performance >>> differences between the latest 7.0.x and 8.5.x releases (or 9.0.x) are >>> more likely to be investigated. >>> >>> 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 >> > > > --------------------------------------------------------------------- > 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
