Chrome can be used to simulate a slow connection. Install Chrome if it is not already installed on your system. After that, open a new tab and press CTRL + SHIFT + I to bring up the developer tools window, or click on the hamburger icon, then More tools, then Developer tools.
Now click on Network section – a drop-down menu of pre-configured speeds appears, which you can use to simulate a slow connection.
To add your own custom values, click the Add button under Custom. To create a new profile, click the Add Custom Profile button.
This is an excellent tool that is integrated into Chrome that you can use to determine the load time of your website on slower connections. Please feel free to leave a comment if you have any questions. Enjoy!
Consider six of the most critical metrics to monitor and the value they provide.
Response Metrics
Average response time is the time between a client’s initial request and the final byte of a server’s response, which includes the delivery of HTML, images, CSS, JavaScript, and any other resources. It is the most precise standard method of determining the actual user experience.
Peak response time is a roundtrip time measurement for a request/response cycle, but it focuses on the longest cycle rather than an average. Rapid response times assist in identifying potentially problematic anomalies.
Error Rate quantifies the proportion of problematic requests to total requests. While it is not uncommon for some errors to occur during periods of high load, error rates should be kept to a minimum to optimize the user experience.
Volume Metrics
Concurrent users indicate the number of virtual users that are active at any given time. While requests per second are comparable (see below), the difference is that each concurrent user can generate a large number of requests.
Requests per second indicate the total number of requests sent to the server each second, which may include requests for HTML pages, CSS stylesheets, XML documents, JavaScript files, and images, among other resources.
Throughput indicates the amount of bandwidth consumed during the test in kilobytes per second. Low throughput may indicate the need for resource compression.
Hey Guys, Lighthouse is an open-source, automated tool for improving the quality of web pages. You can run it against any web page, public or requiring authentication. It has audits for performance, accessibility, progressive web apps, SEO and more. This tool has can make everyone’s life easy – Developers / SDETs / Product Managers.
You can run Lighthouse in Chrome DevTools, from the command line, as a Node module or you can also use https://web.dev/measure/ to measure the performance. You give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page did. From there, use the failing audits as indicators on how to improve the page. Each audit has a reference doc explaining why the audit is important, as well as how to fix it.
As far as the webpage Performance Test is concerned, Lighthouse measures the following metrics:
First Contentful Paint: FCP measures how long it takes the browser to render the first piece of DOM content after a user navigates to your page. Images, non-white <canvas> elements, and SVGs on your page are considered DOM content; anything inside an iframe isn’t included.
Speed Index: Speed Index measures how quickly content is visually displayed during page load. Lighthouse first captures a video of the page loading in the browser and computes the visual progression between frames. Lighthouse then uses the Speedline Node.js module to generate the Speed Index score.
Largest Contentful Paint: Largest Contentful Paint (LCP) is an important, user-centric metric for measuring perceived load speed because it marks the point in the page load timeline when the page’s main content has likely loaded—a fast LCP helps reassure the user that the page is useful. The Largest Contentful Paint (LCP) metric reports the render time of the largest image or text block visible within the viewport, relative to when the page first started loading.
Time to Interactive: TTI measures how long it takes a page to become fully interactive. A page is considered fully interactive when:
The page displays useful content, which is measured by the First Contentful Paint,
Event handlers are registered for most visible page elements, and
The page responds to user interactions within 50 milliseconds.
Total Blocking Time: TBT measures the total amount of time that a page is blocked from responding to user input, such as mouse clicks, screen taps, or keyboard presses. The sum is calculated by adding the blocking portion of all long tasks between First Contentful Paint and Time to Interactive. Any task that executes for more than 50 ms is a long task. The amount of time after 50 ms is the blocking portion. For example, if Lighthouse detects a 70 ms long task, the blocking portion would be 20 ms.
Cumulative Layout Shift: Cumulative Layout Shift (CLS) is an important, user-centric metric for measuring visual stability because it helps quantify how often users experience unexpected layout shifts—a low CLS helps ensure that the page is delightful.
CLS measures the sum total of all individual layout shift scores for every unexpected layout shift that occurs during the entire lifespan of the page.
A layout shift occurs any time a visible element changes its position from one rendered frame to the next.
If your project is replacing an existing system, it is immensely valuable to establish a baseline for the new system based on the existing system. Start by analyzing the usage patterns of the existing site. What operations are most common? What paths are users following through the site? How many users are accessing the system at various times throughout the day? Wherever possible, this data should come from system logs rather than assumptions and guesswork. Then start designing your test:
Create a mix of scenarios that account for 70-80% of the site usage
Add any other scenarios that are known, or suspected, of having poor performance or affecting the overall performance of the system.
Run a test that simulates various load levels corresponding to the load levels seen throughout a typical day
Verify that the results agree with actual performance of the system during real-world use. If it does not, then adjust the test design and scenario mix to better match the real-world usage. Return to step 3 and try again
Having an accurate benchmark of the existing system yields several benefits:
Performance measurements of the existing system can be compared objectively to the new system
Research on the usage patterns of existing users will greatly improve the estimates of usage of the new system – improving the design and accuracy of tests on the new system
Endurance Testing – It is a type of performance testing where the testing is conducted to evaluate the behavior of the system when a significant workload is given continuously.
Spike Testing – It is a type of performance testing that is performed to analyze the behavior of the system when the load is increased substantially.
Q: What are the top 3 Response KPIs for Performance Testing?
Average response time – time to first byte or last byte
Peak response time – tells your longest cycle
Error rate – percentage of problems compared to all requests
Q:What Is Distributed Load Testing?
Distributed load testing is the process of simulating a very high workload of an enormous number of users using multiple systems. As a single system cannot generate a large number of threads (users), multiple systems are used for load testing. It helps to distribute the tests and the load.
Q:What is the difference between front-end and back-end performance testing? Which one is more important?
Front-end performance is concerned with how quickly text, images, and other page elements are displayed on a user’s browser page.
Back-end performance is concerned with how quickly these elements are processed by the site’s servers and sent to the user’s machine upon request. Remember: Front-end performance is the part of the iceberg above the water line, and back-end performance is everything underneath that you can’t see.
Both are important because they can both determine whether a user continues to use your application.
Q:You run a load test against a server with 4GB RAM and the results show an average response time of 30 seconds for a particular request. The production server has been allocated 8GB RAM. What would you expect the average response time of the same request to be in production given the same load?
While you may be tempted to answer that the response time would be halved to 15 seconds, reality is rarely that convenient. Response times are a factor of so much more than memory. Things like CPU utilisation, network throughput, latency, load balancing configuration, and just application logic are always going to influence load tests. You can’t assume a linear progression in response time just because you’ve upgraded one part of the hardware. This is why it’s important to load test against an environment that is as production-like as possible.
Q: After running a load test, the results show that 300 transactions were executed with a PASSED status and returning responses of HTTP 200. However, the DBA tells you that there were no records written to the database as a result of the transactions. How would you troubleshoot this?
Its important to add various counters and monitors DB servers too. + Its very important to add assertions to make sure a request is successful. In the above mentioned case, it can be a bug or it can be due to poor scripting too. Adding right assertions, and counters will help in troubleshooting.
Q: Have you heard about New Relic or Datadog?
These are the monitoring tools.
Q: What are the benefits of monitoring tools like – New Relic , Datadog, etc?
Monitoring tools lets you monitor all your infrastructure in one place by creating monitors that will continuously check the health of your infrastructure. Access everything you need in one dashboard and see the data as it comes in straight from your systems.
Establishes end-to-end application performance and stability, by identifying and leveraging preventative tasks on-demand.
Creation of active metrics associated with data response times, CPU usage, load-balance alarms, exceptions etc.
Neotys explained in a simple way how we can do Performance Testing early in the cycle and how can we minimize the risk and costs.
Test-Driven Development is a great tool for functional testing, but can you apply the same technique to performance testing?
Why not?
The purpose of TDD is to build out small unit tests, or scenarios, under which you control your initial coding. Your tests will fail the first time you run them because you haven’t actually developed any code. But once you do start coding, you’ll end up with just enough code to pass the test.
Some Tricks for Performance TDD:
1. Create small-batch load tests that can stress small components. As you start planning your module, think about how that module would be stressed. What algorithms are most likely to limit scalability? Is there an opportunity for resource contention? Do you have queries that could impact performance if they get too large or complicated? Then create your test scenarios specifically to stress the component in these ways. As you and your team work through more and more of the product, you’ll end up building an amazing library of load test scenarios that you can leverage in lots of interesting ways moving forward.
2. Don’t apply TDD to optimizations, instead just use it for base-level performance. The job of a performance engineer is often focused on optimizing code that’s already been written by someone. TDD isn’t really going to be much help here. Remember, TDD is best leveraged at the beginning of the code-writing process. So that’s where you should start. As your product matures, it’s completely appropriate to make your load tests incrementally more demanding (a certain function must return in 2 seconds instead of 4 seconds), but that may not always be the ideal place to focus because scaling problems are often driven by more complex interactions that are best suited for different kinds of test methodologies.
3. Automate. TDD and automation go hand-in-hand, and you should approach it that way from the beginning. Think about how to automate your TDD from the moment you start doing it, like any modern development method. By doing this, you’ll be able to easily plug your performance testing into other automated processes like continuous integration, but you’ll also end up with a number of micro-load test scenarios that can be strung together into a larger automated test scenario. This gives you a ton of leverage.
Performance specifications should ask the following questions, at a minimum:
In detail, what is the performance test scope? What subsystems, interfaces, components, etc. are in and out of scope for this test?
For the user interfaces (UIs) involved, how many concurrent users are expected for each (specify peak vs. nominal)?
What does the target system (hardware) look like (specify all server and network appliance configurations)?
What is the Application Workload Mix of each system component? (for example: 20% log-in, 40% search, 30% item select, 10% checkout).
What is the System Workload Mix? [Multiple workloads may be simulated in a single performance test] (for example: 30% Workload A, 20% Workload B, 50% Workload C).
What are the time requirements for any/all back-end batch processes (specify peak vs. nominal)?
Important write-up for folks who are new to performance testing.
According to the Microsoft Developer Network the Performance Testing Methodology consists of the following activities:
Identify the Test Environment. Identify the physical test environment and the production environment as well as the tools and resources available to the test team. The physical environment includes hardware, software, and network configurations. Having a thorough understanding of the entire test environment at the outset enables more efficient test design and planning and helps you identify testing challenges early in the project. In some situations, this process must be revisited periodically throughout the project’s life cycle.
Identify Performance Acceptance Criteria. Identify the response time, throughput, and resource-use goals and constraints. In general, response time is a user concern, throughput is a business concern, and resource use is a system concern. Additionally, identify project success criteria that may not be captured by those goals and constraints; for example, using performance tests to evaluate which combination of configuration settings will result in the most desirable performance characteristics.
Plan and Design Tests. Identify key scenarios, determine variability among representative users and how to simulate that variability, define test data, and establish metrics to be collected. Consolidate this information into one or more models of system usage to be implemented, executed, and analyzed.
Configure the Test Environment. Prepare the test environment, tools, and resources necessary to execute each strategy, as features and components become available for test. Ensure that the test environment is instrumented for resource monitoring as necessary.
Implement the Test Design. Develop the performance tests in accordance with the test design.
Execute the Test. Run and monitor your tests. Validate the tests, test data, and results collection. Execute validated tests for analysis while monitoring the test and the test environment.
Analyze Results, Tune, and Retest. Analyse, Consolidate and share results data. Make a tuning change and retest. Compare the results of both tests. Each improvement made will return smaller improvement than the previous improvement. When do you stop? When you reach a CPU bottleneck, the choices then are either improve the code or add more CPU.
