I'm looking for tools for measuring webpage performance with certain browser(Chrome) extension installed. I would like to know things like # of requests, time to first byte, slowest call, average call, FCP, and LCP et. al..
I've used development tool that comes with the browser and extensions such as Page load time, Performance-Analyser.
I'm look for some method/tool that can load pages one by one from a list and be able to download the results, so I can test many webpages and batch process the results.
Thanks.
You can use any suitable browser automation framework i.e. Selenium which is some form a de-facto standard
Check out 6 Easy Steps to Testing Your Chrome Extension With Selenium for example
There is also Lighthouse tool which can also be considered and executed from shell scripts or programmatically, however it's more web-oriented hence not all metrics will be applicable so you might get a lot of false-negative results.
Related
I am currently working on multiple Load testing tool such as Jmeter, LoadRunner and Gatling.
All above tool works upon protocol level user load testing except TrueClient protocol offered by LoadRunner. Now something like real browser testing is in place which is definitely high on resources consumption tools such as LoadNinja and Flood.IO works on this novel concept.
I have few queries in this regards
What will be the scenario where real browser based load testing fits perfectly?
What real browser testing offers which is not possible in protocol based load testing?
I know, we can use Jmeter to Mimic browser behavior for load testing but is there anything different that real browser testing has to offer?
....this novel concept.....
You're showing your age a bit here. Full client testing was state of the art in 1996 before companies shifted en masse to protocol based testing because it's more efficient in terms of resources. (Mercury, HP, Microfocus) LoadRunner, and (Segue, Borland, Microfocus) Silk, and (Rational, IBM) Robot, have retained the ability to use full GUI virtual users (run full clients using functional automation tools) since this time. TruClient is a recent addition which runs a full client, but simply does not write the output to the screen, so you get 99% of the benefits and the measurements
What is the benefit. Well, historically two tier client server clients were thick. Lots of application processing going on. So having a GUI Virtual user in a small quantity combined with protocol virtual users allowed you to measure the cost/weight of the client. The flows to the server might take two seconds, but with the transform and present in the client it might take an addtional 10 seconds. You now know where the bottleneck is/was in the user experience.
Well, welcome to the days of future past. The web, once super thin as a presentation later, has become just as thick as the classical two tier client server applications. I might argue thicker as the modern browser interpreting JavaScript is more of a resource hog than the two tier compiled apps of years past. It is simply universally available and based upon a common client-server protocol - HTTP.
Now that the web is thick, there is value in understanding the delta between arrival and presentation. You can also observe much of this data inside of the performance tab of Chrome. We also have great w3c in browser metrics which can provide insight into the cost/weight of the local code execution.
Shifting the logic to the client also has resulted in a challenge on trying to reproduce the logic and flow of the JavaScript frameworks for producing the protocol level dataflows back and forth. Here's where the old client-server interfaces has a distinct advantage, the protocols were highly structured in terms of data representation. So, even with a complex thick client it became easy to represent and modify the dataflows at the protocol level (think database as an example, rows, columns....). HTML/HTTP is very much unstructured. Your developer can send and receive virtually anything as long as the carrier is HTTP and you can transform it to be used in JavaScript.
To make it easier and more time efficient for script creation with complex JavaScript frameworks the GUI virtual user has come back into vogue. Instead of running a full functional testing tool driving a browser, where we can have 1 browser and 1 copy of the test tool per OS instance, we now have something that scale a bit more efficiently, Truclient, where multiple can be run per OS instance. There is no getting around the high resource cost of the underlying browser instance however.
Let me try to answer your questions below:
What will be the scenario where real browser based load testing fits perfectly?
What real browser testing offers which is not possible in protocol based load testing?
Some companies do real browser based load testing. However, as you rightly concluded that it is extremely costly to simulate such scenarios. Fintech Companies mostly do that if the load is pretty less (say 100 users) and application they want to test is extremely critical and such applications cannot be tested using the standard api load tests as these are mostly legacy applications.
I know, we can use JMeter to Mimic browser behaviour for load testing but is there anything different that real browser testing has to offer?
Yes, real Browsers have JavaScript. Sometimes if implementation is poor on the front end (website), you cannot catch these issues using service level load tests. It makes sense to load test if you want to see how well the JS written by the developers or other logic is affecting page load times.
It is important to understand that performance testing is not limited to APIs alone but the entire user experience as well.
Hope this helps.
There are 2 types of test you need to consider:
Backend performance test: simulating X real users which are concurrently accessing the web application. The goal is to determine relationship between increasing number of virtual users and response time/throughput (number of requests per second), identify saturation point, first bottleneck, etc.
Frontend performance test: protocol-based load testing tools don't actually render the page therefore even if response from the server came quickly it might be the case that due to a bug in client-side JavaScript rendering will take a lot of time therefore you might want to use real browser (1-2 instances) in order to collect browser performance metrics
Well-behaved performance test should check both scenarios, it's better to conduct main load using protocol-based tools and at the same time access the application with the real browser in order to perform client-side measurements.
i have a website what can be used by 50 users at the same time. Those users will be in the same room.
My problem is to know how much bandwith (in Mb/s) do I need to rent for that room so that they can access my website comfortably (speed up and down) ?
The average page size of my website is 1MB.
I searched for answers on the internet and all I got was bandwith used in a month (for servers).
Sorry if my question is "vague", I did my best to make it clear.
Thank you in advance for your answers.
Using https://gtmetrix.com/ you can test your websites speed, page size, and load times
There are several alternatives you just have to do the research
The more important issue you should focus on is why your page is 1Mb that should be your first priority to resolve and using tools like gtmetrix can help
I recommend load testing your site to figure that out. If you're at all familiar with JMeter, you can use it to create a script that simulates a user navigating your site, then run multiple instances of that user (in your case, 50) to see how the site holds up under load.
You can learn more about JMeter here:
https://jmeter.apache.org/
If you're not familiar with creating JMeter scripts, you can record and auto-generate basic scripts using the Blazemeter Chrome Extension, here.
For low-load testing (50 users is pretty low), you can upload your JMeter script to Blazemeter, and with a free tier Blazemeter account, you can perform some basic tests to see how your site holds up. If you go that route, I recommend focusing on avg. response time and hits/second in order to determine what your bandwidth need truly is under load.
Okay, here's a complicated one I've been breaking my head over all week.
I'm creating a self service system, which allows people to identify themselves by barcode or by smartcard, and then perform an arbitrary action. I run a Tomcat application container locally on each machine to serve up the pages and connect to external resources that are required. It also allows me to serve webpages which I then can use to display content on the screen.
I chose HTML as a display technology because it gives a lot of freedom as to how things could look. The program also involves a lot of Javascript to interact with the customer and hardware (through a RESTful API). I picked Javascript because it's a natural complement to HTML and is supported by all modern browsers.
Currently this system is being tested at a number of sites, and everything seems to work okay. I'm running it in Chrome's kiosk mode. Which serves me well, but there are a number of downsides. Here is where the problems start. ;-)
First of all I am petrified that Chrome's auto-update will eventually break my Javascript code. Secondly, I run a small Chrome plugin to read smartcard numbers, and every time the workstation is shutdown incorrectly Chrome's user profile becomes corrupted and the extension needs to be set up again. I could easily fix the first issue by turning off auto-update but it complicates my installation procedure.
Actually, having to install any browser complicates my installation procedure.
I did consider using internet explorer because it's basically everywhere, but with the three dominant versions out there I'm not sure if it's a good approach. My Javascript is quite complex and making it work on older versions will be a pain. Not even mentioning having to write an ActiveX component for my smartcards.
This is why I set out to make a small browser wrapper that runs in full screen, and can read smartcard numbers. This also has downsides. I use Qt: Qt's QtWebkit weighs a hefty 10MB, and it adds another number of dependencies to my application.
It really feels like I have to pick from three options that all have downsides. It really is something I should have investigated before I wrote the entire program. I guess it is a lesson learnt well.
On to the questions:
Is there a pain free way out of this situation? (probably not)
Is there a browser I can depend on without adding tens of megabytes to my project?
Is there another alternative you could suggest?
If you do not see another way out, which option would you pick?
I am looking to simulate heavy load on my web server by constantly visiting a list of urls over and over and over again!
Initially, I planned to write a simple script using wget/curl but because the site uses a lot of ajax requests for much of its heavy lifting, this isn't a feasible options. It would require me to write a complicated script to parse the html from the link, extract the ajax request, curl them. I would have to do this recursively for each request.
Ideally there is some way to get a broswer (or something similar) to just loop through a list of urls spending 15-30 seconds on each link before moving on! This would mean all my javascript will be executed when each url is visited and the sites load will be representative
Anyone know how i can do this easily?
Take a look at LoadBooster(https://www.loadbooster.com). It is a cloud-based load testing service which utilizes headless scriptable browser PhantomJS to test web sites. Disclaimer: I work for LoadBooster.
What you're looking for is "load testing software". There are a lot of solutions - how well they handle AJAX varies greatly. A tool that drives a real browser (via something like Selenium) might be the easiest for you to get started with - assuming your test scenarios are really as simple as "visit this list of URLs". There is at least one real-browser web-based testing tool that can do this for you (BrowserMob). Our product, Web Performance Load Tester, simulates the browser but we are generally able to handle AJAX pretty well. AFAIK, all of the free solutions are pretty limited in what they can do - particularly when AJAX is involved.
Use apache bench.
ab
Something simple like this:
> ab -k -n 100 -c 100 -g myresults.txt http://myajax.com/page
The above would mean, 100 pages over 100 concurrent connections, all with keep alive, and save the results to the text file myresults.txt.
http://www.google.co.uk/search?sourceid=chrome&ie=UTF-8&q=ab+apache
There is also seige.
I used WebLOAD for a similar type of test - it's correlation engine is very useful in heavy AJAX situations.
I need to write a script that insert 1-million records of username or emails by crawling the web, into database.
The script may be any types like python,ruby,php etc.
Please let me know is it possible ?if possible please provide the information how can I build the script.
Thanks
You should also look at Apache Nutch and Apache Gora which would do what you're looking for. Nutch does the actual crawling which Gora stores the results in Cassandra, Hive or MySQL
Its possible may take some time though depending on your machine's performance and your internet connection.You could use PHP's cURL library to automatically send Web requests and then you could easily parse the data using a library for example :simplHtmlDOM or using native PHP DOM. But beware of running out of memory, also I highly recommend running the script from shell rather than a web browser. Also consider using multi curl functions, to fasten the process.
This is extreamly easy and fast to implement, although multi-threading would give a huge performance boost in this scenario, so I suggest using one of the other languages you proposed. I know you could do this in Java easily using Apache HttpClient library and manipulate the DOM and extract data using native x-path support, regex or use one of the many third party dom implementations in Java.
I strongly recommend also checking out Java library HtmlUnit, where it could make your life much easier, but you could maybe take a performance hit for that. A good multi-threading implementation would give a huge performance boost but a bad one could make your program run worse.
Here is some resources for python:
http://docs.python.org/library/httplib.html
http://www.boddie.org.uk/python/HTML.html
http://www.tutorialspoint.com/python/python_multithreading.htm
I would add a little on crawl side.
you said crawl the web. So here the crawling direction (i.e. after fetching a page, which link to visit next becomes very important). But if you already have a list of webpages (called seed URLs list) with you then you simply need to download them and parse out reqd. data. If you just need to parse email addresses, then regex would be your option. Because html does not have any tag for emails, then htmldom parser wouldnt help you.