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