Am 6. März 2016 13:07:39 MEZ, schrieb Tullio Bettinazzi <tullio0...@live.it>: >What do you mean with : >Have you tried switching the connectors on the tomcat side?
The http connector has different implementations. See http://tomcat.apache.org/tomcat-8.0-doc/config/http.html Felix > ??? >Tks > > >> Subject: Re: Performance regression from 7 to 8 >> To: users@tomcat.apache.org >> From: felix.schumac...@internetallee.de >> Date: Sat, 5 Mar 2016 14:00:11 +0100 >> >> Am 05.03.2016 um 12:34 schrieb Tullio Bettinazzi: >> > This is not a memory problem because, otherwise, I'll have the same >problem on all client systems. >> > It's a communication related problem between server and clients but >not strictly a network problem because, otherwise, two clients, >connected to the same cable would perform in the same way. >> If it is stable slow on one client, then you could take threaddumps >on >> the tomcat side and look what it is doing. On the network side, you >> could look at a tcpdump. >> >> Have you tried switching the connectors on the tomcat side? >> >> Felix >> > Tks >> > Tullio >> > >> >> Subject: Re: Performance regression from 7 to 8 >> >> To: users@tomcat.apache.org >> >> From: felix.schumac...@internetallee.de >> >> Date: Sat, 5 Mar 2016 11:13:58 +0100 >> >> >> >> Am 04.03.2016 um 14:19 schrieb Tullio Bettinazzi: >> >>> Done and nothing changed. >> >>> Any suggestion ? >> >> It could be related to memory usage. >> >> >> >> Tomcat 8 can use more memory than tomcat 7 (See >> >> >https://mail-archives.apache.org/mod_mbox/tomcat-users/201602.mbox/%3ccacbju2wmw7mntevb6hwjqdfzsjpmfiuw6k_dn1u0ufh0haj...@mail.gmail.com%3E) >> >> >> >> So try to look at your memory consumption and adjust the limits >for the >> >> jvm accordingly. For monitoring, you can enable gc logging, or use >> >> something like jstat, jconsole, jvisualvm, jmc or any other >monitoring tool. >> >> >> >> Mark has worked on the memory issue and lowered consumption for >newer >> >> versions. I think they will be in the next release. >> >> >> >> Regards, >> >> Felix >> >>> 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()); >> >>> } >> >>> } >> >>> >> >>>> Date: Fri, 4 Mar 2016 12:58:02 +0100 >> >>>> Subject: Re: Performance regression from 7 to 8 >> >>>> From: r...@apache.org >> >>>> To: users@tomcat.apache.org >> >>>> >> >>>> 2016-03-04 12:42 GMT+01:00 Mark Thomas <ma...@apache.org>: >> >>>> >> >>>>> On 04/03/2016 11:17, Tullio Bettinazzi wrote: >> >>>>>> This servlet reproduces the problem perfectly. >> >>>>> Getting better but still some room for improvement. >> >>>>> - You don't need to implement doPost() >> >>>>> - You don't need to call System.gc() (or if you do look there >for >> >>>>> the problem) >> >>>>> >> >>>> Yes, it's on every get and will cause a major concurrency issue. >> >>>> >> >>>> >> >>>>> - You do need to remove the use of the ComunicationChannelHttp >and >> >>>>> Cronometro classes (and if that fixes the problem look >there >> >>>>> for the root cause) >> >>>>> - The try/catch in doGet() should not be necessary either >> >>>>> >> >>>> Also writing individual bytes is more costly even if there's >some buffering. >> >>>> >> >>>> Rémy >> >>>> >> >>>>> Mark >> >>>>> >> >>>>>> package axioma.rubik.engine.web.servlet; >> >>>>>> >> >>>>>> import java.io.*; >> >>>>>> import javax.servlet.ServletException; >> >>>>>> import javax.servlet.annotation.WebServlet; >> >>>>>> import javax.servlet.http.*; >> >>>>>> import axioma.rubik.engine.web.ComunicationChannelHttp; >> >>>>>> import it.axioma.rubik.engine.Cronometro; >> >>>>>> >> >>>>>> @WebServlet(name="Test8", description="Direct update of data", >> >>>>> urlPatterns={"/Test8"}) >> >>>>>> public class Test8Servlet extends HttpServlet { >> >>>>>> >> >>>>>> private static final long serialVersionUID = 1L; >> >>>>>> >> >>>>>> @Override >> >>>>>> protected void doPost(HttpServletRequest request, >> >>>>> HttpServletResponse response) throws ServletException, >IOException { >> >>>>>> this.doGet(request,response); >> >>>>>> } >> >>>>>> >> >>>>>> @Override >> >>>>>> protected void doGet(HttpServletRequest request, >HttpServletResponse >> >>>>> response) throws ServletException, IOException { >> >>>>>> try { >> >>>>>> fai(response); >> >>>>>> System.gc(); >> >>>>>> } catch (Exception ex) { >> >>>>>> ex.printStackTrace(); >> >>>>>> } >> >>>>>> ComunicationChannelHttp.CONTEXT_MANAGER.clean(); >> >>>>>> } >> >>>>>> >> >>>>>> public void fai(HttpServletResponse response) { >> >>>>>> Cronometro crono = new Cronometro(); >> >>>>>> ByteArrayOutputStream bbs = new >ByteArrayOutputStream(); >> >>>>>> BufferedOutputStream bos = new >BufferedOutputStream(bbs); >> >>>>>> try { >> >>>>>> for(int i = 0; i < 400000; i++) { >> >>>>>> bos.write(96); >> >>>>>> } >> >>>>>> bos.flush(); >> >>>>>> System.out.println("Step 1 : "+crono.elapsed()); >> >>>>>> bbs.writeTo(response.getOutputStream()); >> >>>>>> System.out.println("Step 1 : "+crono.elapsed()); >> >>>>>> } catch (IOException ex) { >> >>>>>> ex.printStackTrace(); >> >>>>>> } >> >>>>>> } >> >>>>>> >> >>>>>> } >> >>>>>> >> >>>>>> >> >>>>>>> Subject: Re: Performance regression from 7 to 8 >> >>>>>>> To: users@tomcat.apache.org >> >>>>>>> From: ma...@apache.org >> >>>>>>> Date: Fri, 4 Mar 2016 10:38:30 +0000 >> >>>>>>> >> >>>>>>> On 04/03/2016 10:24, Tullio Bettinazzi wrote: >> >>>>>>>> The problem is all in this small piece of code >> >>>>>>>> ByteArrayOutputStream bbs = new >ByteArrayOutputStream(); >> >>>>>>>> BufferedOutputStream bos = new >BufferedOutputStream(bbs); >> >>>>>>>> trans.eseguiTrasformazioneOut(bos); >> >>>>>>>> try { >> >>>>>>>> bos.flush(); >> >>>>>>>> initReponse(xpFileTypeOut.getMimeType(), >xpFilename); >> >>>>>>>> bbs.writeTo(getOutputStream()); >> >>>>>>>> } catch (IOException ex) { >> >>>>>>>> Messaggi.getErrori().getLogger().error("Errore >in >> >>>>> emettiFile ", ex); >> >>>>>>>> } >> >>>>>>>> The yellow instruction take 100 ms in Tomcat7, quite stable >on all >> >>>>> clients, in Tomcat8 it takes from 50 ms to 4500 ms stable on a >single >> >>>>> client PC but very different from client to client. >> >>>>>>>> Tks >> >>>>>>>> Tullio >> >>>>>>> I'll repeat what I said previously: >> >>>>>>> >> >>>>>>> Try creating the *simplest possible* web application that >demonstrates >> >>>>> the >> >>>>>>> problem. >> >>>>>>> >> >>>>>>> Mark >> >>>>>>> >> >>>>>>>>> Subject: Re: Performance regression from 7 to 8 >> >>>>>>>>> To: users@tomcat.apache.org >> >>>>>>>>> From: ma...@apache.org >> >>>>>>>>> Date: Fri, 4 Mar 2016 09:42:22 +0000 >> >>>>>>>>> >> >>>>>>>>> On 04/03/2016 09:39, Tullio Bettinazzi wrote: >> >>>>>>>>>> I applied tour suggestion and analyzed, with firebug, the >> >>>>> composition of the time. >> >>>>>>>>>> The difference between 7 and 8 is the "receiving" time >which is more >> >>>>> or less zero in 7 and 2sec. in 8. >> >>>>>>>>>> How can I understand such difference ? >> >>>>>>>>> Try creating the simplest possible web application that >demonstrates >> >>>>> the >> >>>>>>>>> problem. >> >>>>>>>>> >> >>>>>>>>> Mark >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>>> Tks >> >>>>>>>>>> Tullio >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> P.S. : same server, same client, same network, same code >both 7 and >> >>>>> 8 installed from scratch >> >>>>>>>>>>> Subject: Re: Performance regression from 7 to 8 >> >>>>>>>>>>> To: users@tomcat.apache.org >> >>>>>>>>>>> From: geor...@mhsoftware.com >> >>>>>>>>>>> Date: Thu, 3 Mar 2016 09:30:33 -0700 >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> On 3/3/2016 4:06 AM, Tullio Bettinazzi wrote: >> >>>>>>>>>>>> I've an application in which I write a page from a >Buffered Stream >> >>>>> directly to the Servlet output stream (more or less 300kb). >> >>>>>>>>>>>> In 7 it works perfectly (100ms). >> >>>>>>>>>>>> >> >>>>>>>>>>>> In 8 , depending from the network connection and mainly >from the >> >>>>>>>>>>>> http client itself (the browser in the PC) the same >operation >> >>>>> takes from >> >>>>>>>>>>>> 50ms to 4500 ms. >> >>>>>>>>>>> One of the things I would look at is the browser debug >window. Open >> >>>>> the >> >>>>>>>>>>> debugger, and go to the Networks/Timings tab and load >both pages. >> >>>>> That >> >>>>>>>>>>> would give some insights as to what's happening. Perhaps >it is the >> >>>>> page. >> >>>>>>>>>>> Perhaps there's something else. >> >>>>>>>>>>> >> >>>>>>>>>>>> On the same PC I find more or less the same time using >Chrome and >> >>>>> Firefox also changing network connections (wifi, lan, adsl). >> >>>>>>>>>>>> Could someone suggest a solution ? >> >>>>>>>>>>>> >> >>>>>>>>>>>> Tks >> >>>>>>>>>>>> Tullio >> >>>>>>>>>>>> >> >>>>>>>>>>> -- >> >>>>>>>>>>> George Sexton >> >>>>>>>>>>> *MH Software, Inc.* >> >>>>>>>>>>> Voice: 303 438 9585 >> >>>>>>>>>>> http://www.connectdaily.com >> >>>>>>>>> >--------------------------------------------------------------------- >> >>>>>>>>> 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 >> >> >> > >> >> >> --------------------------------------------------------------------- >> 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
