I was using Jmeter HTTPS Test Script Recorder to record a login request.
Please see the snapshot, I already added the URL patters to exclude the .js files, but I still get the js requests.
Why it's failed?
You can check that if you look at the contents of the said requests. Most likely they are GET requests, and most likely they have one or more Parameters. Regex .*\.js looks specifically for .js at the end of the URL. But if GET request has parameters, on recording its URL would look like <...>.js?param=value, so the regex .*\.js will not match (although the name of the request will still be the same).
So you need to specify 2 regex exclusions: .*\.js and .*\.js?.*
I know that it doesn't answer your question, but actually excluding images and .js files is not something you should be normally doing. I would rather use that field to filter out the "external" URLs, which are not connected to your application like 3rd-party banners, widgets, images, etc. - anything which is not related to your application under test. Even if you see it in response, these entities are being loaded from external sources which you cannot control so they are not interesting and the picture of your load test might be impacted.
So I would suggest the following:
In "Grouping" drop-down choose Store 1st sampler of each trade group only
Make sure that Follow Redirects and Retrieve All Embedded Resources. are turned on in the recorded requests. If not - enabled them via HTTP Request Defaults. Also check Use concurrent pool box is ticked as real browsers download images, styles and scripts in multi-threaded manner.
When it comes to running your test add HTTP Cache Manager to your test plan as well-behaved browsers download images, scripts and styles only once, on subsequent requests they are being returned from browsers cache and this situation needs to be properly simulated
For anyone else arriving here from google looking for an answer to this question:
You may simply be looking at the wrong place.
If you're looking at the workbench results tree, you'll see all requests. They are not filtered here. I've thought this was a bug with JMeter more times than I care to admit.
Instead, look inside the Recording controller tree (which is collapsed by default), where the results are in fact being filtered:
Related
How to get the page load time of an application which has n number of CSS, js, images, etc? How to do the configuration in JMeter?I have tried integrating selenium, but I can only find the scenario load time not the exact load time of a page.
There is a special setting responsible for parsing the DOM and retrieval of so called "embedded resources": images, CSS, JavaScript, sounds, fonts, etc.
It lives under "Advanced" tab of the HTTP Request sampler
If you have more than one HTTP Request sampler - consider adding HTTP Request Defaults configuration element, if you define the setting there - it will be applied to all HTTP Request samplers in the HTTP Request Defaults scope.
You can use Dmitri T's solution, but I think that solution is to simulate new users every time. You need to treat Jmeter as a protocol tool rather than a smart fully featured browser. I suggest you do scripts recording and put parallel controller in place and put recorded scripts under the parallel controller.
You need to make sure you understand each time a page is loading, which ones are cache, which ones are not. Using recording scripts to add them under parallel controller, I think you can download the parallel controller in Jmeter plugin manager..
While checking performance of public website why we exclude java scripts, style sheets and include only basic request which returns HTML file(host "www.test.com" and "/" in path.
You need to exclude these scripts, styles and images only during recording of your test scenario with the HTTP(S) Test Script Recorder as if you record these calls they will be captured, but when you replay them it will have nothing in common with that happens in the reality.
Real browsers act as follows:
They download these scripts, images and styles when requesting the main page, but do it in parallel using several concurrent threads to speed up the process. So the main request forks into several sub-requests which are downloading all this stuff. In JMeter you can mimic this behaviour using "Retrieve All Embedded Resources" switch either in HTTP Request or in HTTP Request Defaults
As you already know, browsers download scripts, images and styles and do it using several concurrent threads. The next point is that well-behaved browsers do it only once, on subsequent requests this stuff is being returned from the browser's cache. So you need to add a HTTP Cache Manager to your Test Plan to simulate this functionality representing browser cache and not overload the server
Regarding 3-rd party content. If your web site uses scripts, images, videos, etc. from other domains - it is recommended to exclude these requests from your load testing scope as most likely you don't have any control of these 3-rd party content providers and won't be able to do anything even if the bottleneck is due to external server, your load test should focus solely on your application.
See How To Make JMeter Behave More Like A Real Browser guide for more information on above hints and few more recommendations.
Because JMeter is only retrieving page elements, and does not execute javascript or render these components like real browsers do. Personally i like to retrieve all embedded resources to give myself a better understanding of the total load time, even if javascript is not executed/rendered.
You can also do a selective retrieval, or a full retrieval if you wish.
Use the checkbox named "retrieve embedded resources", or specify which elements should be retrieved. Getting full retrieval is also handy to see whether there are broken links to components in the page.
I am just wondering why do we exclude photos and css files in jmeter script because if i think from end user prospective,images takes more time to load.
The only content to be excluded from test script is "external" content, i.e. any third-party banners, pictures, maps, analytics, etc. content needs to be filtered out.
JMeter test needs to be as much realistic as possible to correctly simulate user activity. So:
Images, scripts, styles, etc. do not need to be excluded from JMeter test
The best way to handle them is as Vinoth S suggests using "Retrieve All Embedded Resources" functionality (and it is also better to use concurrent pool of 2-4 threads for it). The most optimal way of configuring it is via HTTP Request Defaults config element so the change could be applied to all HTTP Request Samplers.
It is also good to add HTTP Cache Manager from "reality" perspective as real browsers download all this stuff like images, scripts and styles, but they do it only once, on subsequent requests the content is being returned from browser's cache and the actual request to the server is not being made.
See How to make JMeter behave more like a real browser guide for other recommendations on how to make your test more realistic.
css/jpg/js files are all embedded static resources in the HTML response you get.
so instead of sending a recorded request, you can select the below option in the HTTP sampler. JMeter will take care of downloading these files for you just like a real browser.
I know this is an open ended question, but hopefully it will get some good answers before the thread is locked...
I'm wondering what methods there are to programmatically check (language agnostic) if a website is online from a client perspective (assume you can't make changes to the site/server, but you can rely on certain behaviours of the site.)
The result of each method could stack to provide a measure of certainty that the site is up/down - that is, a method does not have to provide a definite indication if the site is up/down on its own.
Some common tests just to check 'upness' may be:
Ping the site (which in the case of shared hosting isn't very
indicative)
Send a http head/get request and check the status
Others I can think of to check that the site is up and functioning:
Check you received a well formed html response i.e. html to html
tags, if the site is experiencing trouble it may spit an error and
exit without writing the rest of the page (not all that reliable
though because the site may handle most errors in a better way)
Check certain content is or is not on the page, i.e. perhaps there is some content that is always present on your pages, or always present in the case of an error
Can anybody think of any other methods that could be used to help determine if a site is in fact up/down and functioning/not functioning correctly from within a program?
If your get request on a page that displays info from database comes back with status 200 and matching keywords are found, you can be pretty certain that your site is up and running.
And you don't really need to write your own script to do that. There are free services such as GotSiteMonitor, Pingdom, UptimeRobot etc. allows you to monitor your site.
Based your set of test on the unit tests priciple. It is normally used in programming to test classes, modules or other artefacts after changes have been made. You can use any of the available frameworks, so don't have to reinvent the wheel. You must describe (implement) tests to be run, in your case a typical test should request a url inside the page and then do some evaluations like:
call result (for example return code of curl execution)
http return code
http headers
response mime type
response size
response content (test against a regular expression)
This way you can add, remove and modify single tests without having to care about the framework, once you are up. You can also chain tests, so perform a login in one test and virtually click a button in subsequent test.
There are also tools to handle such test runs automatically including visualization of results, statistics and the like.
OK, it sounds like you want to test and monitor your website from a customer experience perspective rather than purely establishing if a server is up (using ping for example). An effective way to replicate the customer experience is to simulate tests against the site using one of the headless browser testing tools (phantomJS is great a great choice) as they will render the page fully (including images, CSS, JS etc.) giving you a real page load time. These tools also allow you to make assertions on all aspects of the HTML content and HTTP response.
pingdom recently started offering a (paid for) service to perform these exact types of checks for alongside their existing monitoring solution. The demo is worth looking at, their interface for writing the actual tests is very nice.
We are using JMeter's built-in HTTP Proxy to record a test case. It was decided to capture all requests going to the server, and therefore there is no include/exclude rule set in the proxy. My question is whether there is a necessity in load testing to capture calls to JS, CSS, PNGs and other embedded resources?
So, technically speaking if I call a JSP that includes such resources, JSs, CSSs and images then will their timings (such as response time and latency) be automatically included in JMeter? I know that JMeter is not a browser and therefore it cannot execute client-side scripts but does it automatically discover/consider such resources even when there is not any explicit call to them in the test case.
To answer the question,
YES you can remove all embedded resources from being explicitly called. Requests have a checkbox on the bottom that says "retrieve embedded resources". This would grab all CSS, JPG, etc.
It's also a great way to find broken links and resources in a web app.
Yes it does record all those resources you mentioned. If you look at the recorded test you'll see all you CSS, PNG, js etc files listed too. You can simply remove them if you think some or all are not relevant to your test.