Consider scheduling your load tests for up to 60 minutes. You can always stop the test earlier. By scheduling it for 60 minutes, you retain the option to run the test longer or even pause/resume the test, effectively getting a second test for free. The cost of a shorter test, i.e. 5, 10, or 15 minutes, is the same as a 60 minute test, so there’s really nothing to loose.
Connie
Nov 292011
Thanks to Dave Thompson for sharing his experience with using BrowserMob to test the performance of a Flex app. To read the full article, check out it here.
As ConnectEDU continues to expand, it must have reliable web apps. Anything less will hamper performance and profitability. With BrowserMob Performance Monitoring solution, the company is ready to sustain their growth—not just theirs but that of the students whose dreams they help achieve. Learn More.
Customer Success Story: With BrowserMob + Gorilla Logic, Advanous pulled off an important load test.
Jul 282011
Advanous was able to pull off an important load test with an application that made heavy use of Flex. Using the Selenium platform in BrowserMob, it was a breeze for Advanous to load FlexMonkey and get down to work. Learn More.
Stop by and see us in booth 201 at Velocity. Enter to win FREE monitoring or load testing! Plus, if you’re interested in learning how to build a performance testing framework for your web application in under a day, attend our workshop: Automated Web Performance Testing before 5pm, on Tuesday, June 14th. Patrick Lightbody, founder of BrowserMob, will also be speaking at this show, his topic: “From Inception to Acquisition: One Startup’s Journey through the Cloud”. Join us next week!
By the way … I am apparently the poster child for this event…. 
Recently someone asked if our load testing performance is ever affected by other EC2 users, given the varying levels of EC2 utilization among tests/iterations. The short answer is no. The longer answer is we’ve done rigorous system testing, going beyond Amazon’s extensive measures to provide consistent performance across their cloud network.
While most other load testing tools use 500 or more virtual users per CPU core, BrowserMob is extremely conservative with our capacity (RAM, CPU, disk space, etc.). We use only one browser per core and no more than 50 virtual users. The result: highly consistent measurements and absolute confidence that any poor response times come from the site under test (SUT) and not the testing tool itself.
The Eventually Consistent developer blog reports that after researching on-demand load testing tools, EC loves BrowserMob best. Why? (1) The ability to upload Selenium and run real browsers against your site, (2) real-time reports showing response times/server errors and (3) the downloadable database which lets you run your own queries and analyze them in numerous ways. EC said BrowserMob was “the best way for us, a small shop, to learn about how our site performs.” Thanks EC and glad we could help. Read the full post.
May 202011
We apologize for the inconvenience but we’ve had several recent disruptions, some of extended length, to our services. On Tuesday evening (5/17), we pushed out a release that caused this disruption and unfortunately, it manifested negatively yesterday. During this time, you may have experienced either slow performance, or error pages reporting “Service Temporarily Unavailable”.
We are still investigating the root cause of this issue and the quality of the release. But in the meantime, we have rolled back to a more stable environment. This is high priority for us and will notify you again once we have more information.
As you all know, BrowserMob utilizes Amazon Web Services (AWS) and open source software to power our services – in fact, BrowserMob couldn’t have been started without it. We have put together a case study about our work with Amazon, highlighting the ways that it is helping us save you money.
Our approach to load testing depends on launching thousands of instances in short order, and AWS fits that model perfectly.
May 102011
As you build out your script and plan for a successful load test, it’s important to design the script that incorporates timeout values. BrowserMob has a few types of timeouts that you can use: HTTP-level, Selenium page-level, and Script-level timeouts.
HTTP-level timeouts are controlled by the HTTP client, usually the “c” variable. var c = browserMob.getActiveHttpClient(); and there are 3 commands relating to HTTP timeouts: setConnectionTimeout, setRequestTimeout, and setSocketOperationTimeout. For more information, check out our API documentation which outlines each of these commands.
Recent Comments