load time for linearized pdf

[Mitch White <MW...@atonesoftware.com>]

I'm load testing an app which returns pdf documents. Manual response times
are consistently 1min 10sec before the document is displayed. Jmeter
consistently returns a load time of about half that number. 

 

Load time: 32125

HTTP response code: 200

HTTP response message: OK

 

HTTP response headers:

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Expires: Sat, 6 May 1995 12:00:00 GMT

Cache-Control: max-age=0

Cache-Control: post-check=0, pre-check=0

Pragma: public

Content-disposition: inline; filename=loanfile.pdf

Content-Type: application/pdf

Date: Thu, 22 Jun 2006 16:23:21 GMT

 

The response data tab shows this message: "Response too large to be displayed
(1716116 bytes)." This is the correct size.

My initial impression was that jmeter was moving on to the next request after
it got the first pdf byte range, but the size shown is very close to the size
of the entire pdf. Any ideas why there is this discrepancy in response time?

 

These pdf docs have been "linearized". As background info, I have included
the following paragraphs from:

http://www.jguru.com/faq/view.jsp?EID=236545

In short summary, when Acrobat receives the first part of file it can
determine that it is in linearized form. This enables it to cache the tables
that are present at the beginning of the file and then close the connection,
preventing the entire document from downloading all at once. From then on
Acrobat fetches each page or object as it is needed from the web server. It
does this by using the HTTP byte range headers in requests, and your servlet
needs to support these for it to work properly. 

The byte range headers are described in the HTTP/1.1 RFC #2616 section 14.35,
but a brief description is that in any HTTP request there may be extra
headers that indicate the client is requesting only part of the entity,
rather than the full entity. These headers indicate a byte range, or offest
and length, that the client is asking for. An example is: 

GET /example.pdf HTTP/1.1
Range: bytes=0-1023
 
Thanks,
mkw

 

 

Re: load time for linearized pdf

[Peter Lin <wo...@gmail.com>]

honestly I don't know what that occurs.  the way jmeter works is the thread
will read the inputstream completely before moving on to the next request.

one potential cause for the difference between browser time and jmeter time
is that browsers are slower. JMeter only counts the bytes, but doesn't
attempt to interpret the data.

peter

On 6/22/06, Mitch White <MW...@atonesoftware.com> wrote:
>
> I'm load testing an app which returns pdf documents. Manual response times
> are consistently 1min 10sec before the document is displayed. Jmeter
> consistently returns a load time of about half that number.
>
>
>
> Load time: 32125
>
> HTTP response code: 200
>
> HTTP response message: OK
>
>
>
> HTTP response headers:
>
> HTTP/1.1 200 OK
>
> Server: Apache-Coyote/1.1
>
> Expires: Sat, 6 May 1995 12:00:00 GMT
>
> Cache-Control: max-age=0
>
> Cache-Control: post-check=0, pre-check=0
>
> Pragma: public
>
> Content-disposition: inline; filename=loanfile.pdf
>
> Content-Type: application/pdf
>
> Date: Thu, 22 Jun 2006 16:23:21 GMT
>
>
>
> The response data tab shows this message: "Response too large to be
> displayed
> (1716116 bytes)." This is the correct size.
>
> My initial impression was that jmeter was moving on to the next request
> after
> it got the first pdf byte range, but the size shown is very close to the
> size
> of the entire pdf. Any ideas why there is this discrepancy in response
> time?
>
>
>
> These pdf docs have been "linearized". As background info, I have included
> the following paragraphs from:
>
> http://www.jguru.com/faq/view.jsp?EID=236545
>
> In short summary, when Acrobat receives the first part of file it can
> determine that it is in linearized form. This enables it to cache the
> tables
> that are present at the beginning of the file and then close the
> connection,
> preventing the entire document from downloading all at once. From then on
> Acrobat fetches each page or object as it is needed from the web server.
> It
> does this by using the HTTP byte range headers in requests, and your
> servlet
> needs to support these for it to work properly.
>
> The byte range headers are described in the HTTP/1.1 RFC #2616 section
> 14.35,
> but a brief description is that in any HTTP request there may be extra
> headers that indicate the client is requesting only part of the entity,
> rather than the full entity. These headers indicate a byte range, or
> offest
> and length, that the client is asking for. An example is:
>
> GET /example.pdf HTTP/1.1
> Range: bytes=0-1023
>
> Thanks,
> mkw
>
>
>
>
>
>
>