jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "BOLB (Bohdan L Bodnar)" <B...@panduit.com>
Subject RE: Measuring page load / rendering time
Date Mon, 10 Jun 2013 16:18:57 GMT
I've a similar problem, but I think it may be somewhat more complex:

I'm looking at end-to-end performance of a system where there are two state machines:  one
in the server and one in the browser.  The browser displays and manipulates entities, each
with a unique ID, and sends entity-related API commands to the server (in the form of https
calls).  The IDs are dynamic; i.e., they change from call-to-call even for the same entity.
 Using jmeter to load the server required putting intelligence into the load generation script
to extract these IDs.  This was a time-consuming manual task that was successful and is now
saving me a tremendous amount of time.  Instrumenting the browser would be a terrific next
step.

Sam, would you be so kind as to keep us appraised of what you're doing?

Best regards,

Bo


-----Original Message-----
From: nmq [mailto:nmq0607@gmail.com] 
Sent: Monday, June 10, 2013 7:48 AM
To: JMeter Users List
Subject: Re: Measuring page load / rendering time

Very useful observations and opinions. I'm going to get more details on how the page is being
rendered and hopefully will be able to start somewhere.
Thank you

Regards
Sam


On Sat, Jun 8, 2013 at 6:24 AM, Shmuel Krakower <shmulikk@gmail.com> wrote:

> Hi
> I am not sure you really need the page rendering time in your case.
> If you think you need it as part of the load tests, this is because 
> you think that the dynamic load of next 100 items is related somehow 
> with the rendering time.
>
> In fact, you can measure loading times of the main page and interact 
> with the relevant AJAX call to get the next 100 items and so on.
> So if you build up your load test to interact with those two services 
> (main page and web service which gets X amount of items) you can load 
> your system properly and get some figures.
>
> As Adrian wrote, measuring rendering times may diverse and currently 
> no good technology to cover this with load tests.
>
> Shmuel Krakower.
> www.Beatsoo.org - re-use your jmeter scripts for application 
> performance monitoring from worldwide locations for free.
>
>
> On Sat, Jun 8, 2013 at 12:13 AM, Shay Ginsbourg <sginsbourg@gmail.com
> >wrote:
>
> > Note this new sampler:
> >
> > "Web Driver Sampler automates the execution and collection of 
> > Performance metrics on the Browser (client-side).
> > A large part of performance testing, up to this point, has been on 
> > the server side of things.
> > However, with the advancement of technology, HTML5, JS and CSS 
> > improvements, more and more logic and behavior have been pushed down 
> > to the client.
> > This adds to the overall perceived performance of website/webapp, 
> > but this metric is not available in JMeter."
> >
> > See:  
> > https://code.google.com/p/jmeter-plugins/wiki/WebDriverTutorial
> >
> > That might add a missing feature highly requested.
> >
> > -SG
> >
> >
> >
> >
> > On Fri, Jun 7, 2013 at 4:46 PM, Adrian Speteanu 
> > <asp.adieu@gmail.com>
> > wrote:
> > >
> > > Hi,
> > >
> > > I have a different approach to this. But there's a lot of 
> > > background to it, which can't be covered answering a specific 
> > > question (how to measure
> X),
> > > all of it resumes to: you should not look for shortcuts and 
> > > instead
> > should
> > > do things the right way. Measuring rendering times is the complete 
> > > opposite of doing things that way. Its a dead-end, because it is 
> > > too hard to
> track
> > > and fully cover. Are you going to test on a large enough number of 
> > > PC/Mac/Linux hardware configurations in conjunction with a large 
> > > number
> > of
> > > software versions (OS, browsers, other plugins that might affect 
> > > rendering)? Is your test matrix going to be comprehensive enough?
> Usually
> > > its not.
> > >
> > > The approach to front-end should be different because UI has 
> > > different specific problems. I use YSlow!, a plugin for Firebug 
> > > that works on Firefox. It shows "missing optimisations", and gives 
> > > a good starting
> > point
> > > for a development team to obtain the best rendering time for their 
> > > project.
> > > With JMeter, you create the load on the server side and with one
> desktop
> > > machine, you evaluate what will be the most probable user 
> > > experience during high traffic and then improve that. Its the best 
> > > thing you can do, and
> > the
> > > only honest approach to this problem. You can still make 
> > > measurement taking several samples from tools like Firebug, 
> > > Chrome's dev tools and so on,
> > but
> > > what's the point? Are you trying to benchmark the renderer or your
> server
> > > application? If its the second, there are more questions you ask.
> > >
> > > Regards,
> > > Adrian S
> > >
> > >
> > >
> > >
> > > On Thu, Jun 6, 2013 at 3:28 PM, nmq <nmq0607@gmail.com> wrote:
> > >
> > > > Hi everyone
> > > >
> > > > I have been told that JMeter does not measure page load or 
> > > > rendering time.
> > > > Does anyone know of a roundabout way of making approximations 
> > > > using JMeter, which would be fairly close to actual times.
> > > >
> > > > Or if anyone knows of a better tool that can be used to achieve this?
> > > >
> > > > The AUT is a secured web portal giving access to a limited 
> > > > number of users and is document intensive. I need to measure the 
> > > > page load time of
> the
> > > > Documents page which displays the first 100 documents and as the 
> > > > user scrolls down, renders the next 100 and so forth.
> > > >
> > > > Any tips or help for load/performance testing would be appreciated.
> > > >
> > > > Thanks
> > > > Sam
> > > >
> >
> >
> >
> >
> > --
> >
> > Providing quality services to the appreciated contractors and customers:
> >
> > * Applango * Arad Technologies * Astea Israel * BioControl Medical * 
> > Biometrix * Cognifit * Earlysense * Given Imaging * IBM WorkLight * 
> > Idit Software Solutions * In-House * Israeli Ministry of Finance * 
> > Menora Insurance * Mentors Channel * Mominis * Ness Technologies * 
> > ORAM International * Partner-Orange * Peer39 * Physio-Logic * 
> > Pneumedicare * RealCommerce * Safecharge International * Shaker * 
> > Strauss-Water Tami4 * Tact-Matrix * TaKaDu * Tel-Aviv University * 
> > Tescom-ONE * TesTeam * Tuttnauer * Verix * Visionix * Visionsense * 
> > WinBuyer * XMPie-Xerox *
> >
> > Special notice:
> >
> > In 2013, the entire operation of Ginsbourg.Com is being upgraded to 
> > cloud-based quality service.
> >
> >
> > Regards,
> >
> >
> > Shay Ginsbourg
> >
> > Regulatory & Testing Affairs Consultant
> >
> >
> > WWW.GINSBOURG.COM
> >
> >
> > Providing Regulatory, Medical & Performance Testing services since 2008:
> >
> > * IEC 62304 Medical Device Software Life Cycle * IEEE 829 Software 
> > Test Documentation * ISO 14971 Medical Device Risk Management * FDA 
> > 21 CFR
> Part
> > 11 Software Validation * CE Medical Device Directive 93/42/EEC 
> > dossier * IEC
> > 60601-1:2005 3rd ED PEMS - Medical Electrical Equipment * End-to-end 
> > verification, validation, and testing (VV&T) * FDA and CE 
> > submissions * Open source free testing tools implementation * 
> > Functionality and regression testing * Software Performance & Load 
> > testing * Software Testing Advanced Automation * Medical Software 
> > Verification & Validation * Medical Device Verification & Validation 
> > * Medical Device Regulatory Submission * Organizational Regulatory 
> > Qualification *
> >
> > Formerly QA Manager of LoadRunner at Mercury Interactive
> >
> > M.Sc. cum laude in Bio-Medical Engineering
> >
> > M.Sc. in Mechanical Engineering
> >
> >
> > Work:   +972(0)3-5185873
> >
> > Mobile:  +972(0)54-6690915
> >
> >
> > Email: sginsbourg@gmail.com
> >
> >
> > Visit my personal page on LinkedIn at:
> > http://www.linkedin.com/in/shayginsbourg
> >
> >
> > Please consider your environmental responsibility before printing 
> > this e-mail.
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> > For additional commands, e-mail: user-help@jmeter.apache.org
> >
> >
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org


Mime
View raw message