Find peak traffic periods with NetStorm and develop a plan to handle them

NetStorm makes testing with millions of active users not only possible but easy to manage. The ability to run high-volume tests in a controlled lab environment allows multiple executions while “tweaking” appropriate variables being analyzed, with the assurance that other variables will not change.

Make your site/application load faster on mobile devices

In today’s world, websites we build for clients use mobile-first UI frameworks and work well over different screen sizes. But you need to research even deeper about latency, performance, and speed on mobile devices/websites. Modified pages may help with translation, but they could be slower than pages with static content and images.

Mobile devices testing with NetStrom

RDT or Real Device Testing is a mobile app and web testing service that enables developers to run their tests on real, physical Android, and iOS devices that are hosted on secure premises. NetStorm / RDT can automate functional, performance, stress, regression, and stability testing of Android & iOS apps and associated services. NetStorm’s RDT provides a versatile mobile-application testing platform using real iOS and Android devices.

 RDT Capabilities for Ensuring Seamless Mobile Applications:

• Ensure Exceptional Customer Experience of applications on
  •  Customer handsets/devices
  • Real Desktop browsers
• Meaningful Performance Results
  • Timing Aggregation/Comparison
  • Rendering visual comparison
  • Recommendations
• Mix with Simulated device/browser load.
• Integrated with Cavisson solution suite for a server-side deeper diagnosis.

Set up monitoring and alerts

In a distributed environment, you can find multiple servers hosting a single application with multiple processes and services running on each. In cases of application outages/code or service level issues that impact user experience, it is not easy to diagnose the root cause unless alert/diagnosis data is available across different components i.e. network, infrastructure, application, third-party callouts, etc.

This is where our end-to-end observability platform, NetDiagnostics, comes into the picture. Using NetDiagnostics, metrics across different components are collected, stored, and analyzed. Using this data, NetDiagnostics alerts when any of these metrics are going from normal to a warning state based on the thresholds and gives early warning before it reaches a critical state. Once an alert comes then using advanced in-built analytics, you can find the erroneous components and drastically reduce your MTTR and MTTD.

Our unified performance intelligence platform has an in-build support of proactive alerting through which users can get notified whenever a KPI (Key Performance Indicator metrics like CPU utilization, request per second, average response time, etc.) breaches the threshold configured as part of alert rules. This allows users to get early notification of performance degradation even before an actual issue happens.

Our alerts come in three varieties:

Capacity Alerts – In this type of alert, alert generation is done based on a fixed threshold value. The user needs to define a Rule and Condition with a threshold value. If the condition is met, then the alert is generated.

Behavior Alerts -In this case, alerts are generated based on % deviation from the auto-generated baseline trends. The purpose of dynamic threshold is to:

• Provide adaptive threshold functionality for Alert.
• Generate alerts based on Identifying the baseline on the current load at a specific hour of the day.

Load Index-based Alerts – This is a highly advanced type of baseline alert, which is unique to the NetDiagnostics alert framework and it works based on the load on the system instead of a time-based trend. In this baseline, the alert engine learns the system behavior on all the loads and then utilizes this learning to compare the current data at the current load with the baseline value at the current load. Upon closely monitoring an application’s behavior, it is seen that the response time of an application is proportional to the load (PVS – page views per second) on the system.

For example, if the load (page views per second) is 10, and let us assume that the response time is 100 ms, then, if the load becomes 20 PVS, the response time also becomes high; let’s say it goes to 200 ms, and so on. Therefore, if at one particular time, the value of response time goes to 500ms on a load of 20 PVS then ideally there must be an issue and it should generate  an alert.

All monitors and alerts should be reviewed regularly and especially before a known peak traffic period. You should make sure that alert email addresses, mobile phone numbers, and Slack channels are up to date and that all notifications get through without winding up as spam. Where practicable, test these monitors and alerts against an unproductive environment.

Cavisson’s product suite is integrated with multiple platforms like PagerDuty, BigPanda, Spark, and ServiceNow to name a few. You can utilize these integrations to directly inform important stakeholders whenever a critical issue is observed.

Load test

We do not suggest load testing on a production site when you have peak traffic. Rather, you should perform load tests on your pre-production environment, in advance to have metrics to compare with and to know how much your current architecture can handle. The load testing results can also be used to adjust back-end code, caching, front-end performance, and even database indexes.

Load testing should be carried out continuously and especially whenever new features are introduced to your website. Normally the load-testing phase begins when most functional testing is complete and the system is more or less meeting functional requirements.

Unlike functional testing, the objective of load testing is not to discover defects. Here the objective is to discover bottlenecks. While functional testing is carried out with one or a few users, load testing requires deploying field scenarios where hundreds or thousands of users interact with frontend software, such as a website, or a backend system. When this load crosses a threshold and overloads the system beyond its designed capacity, it comes into the domain of stress or fatigue testing. The goal of stress testing is to break the system with excessive load and to assess the quick and graceful recovery of the system after a crash.

Load testing is made easier with NetStorm.  

NetStorm is a load generation tool that mimics the activities of hundreds of thousands of users sending requests to and receiving responses from websites in a customized and controlled manner. NetStorm can use multiple protocols to interact with target websites. NetStorm achieves this by creating virtual users that make these connections to server(s), send requests, and process the responses received in an orchestrated manner. Apart from requests and responses, it also collects data from websites to monitor performance.

Scale-up infrastructure on-demand

Maybe 10 years ago, you needed to allocate for and provision your infrastructure almost a year ahead. But with cloud-based infrastructure, girding your infrastructure happens at the touch of a button.
During peak traffic, rules can be put in place to impulsively scale up or scale out your infrastructure depending on usage metrics. As easy as it sounds, there are hazards such as file locking, database concurrency, session handling and stale data which can impact user experiences. At one point your peak traffic period is over, those same rules can scale down your infrastructure to handle normal daily traffic.

Review third-party services and apps

We have seen a rogue Google Tag Manager (GTM) script change show a whole site down. Seems impractical and initially, that’s what we thought too. Third-force inclusions such as GTM, Facebook Pixel tags, and others could make or break the experience for your customers. Your uptime and infrastructure monitors are green. But your customers are not able to make a purchase. This could be easy as a third party not serving a web font or a required JavaScript file. Having an official of third-party services used on your website is a start. From there, you need to plan how to reduce issues if any of these services are unavailable. It could be as easy as delaying a script file loading in the front end.

Let’s talk about how NetOcean lets you review third-party services and apps:

 NetOcean is a powerful back-end application simulator that removes dependencies on back-end applications and third-party systems to enable faster quality & performance testing and accelerated time-to-market. Enterprises rely on  NetOcean to stay focused on the system under test, reduce the overall cost of ownership for application testing, and reduce the time-to-market of their software applications.NetOcean tests various protocols like HTTP, HTTPS, JMS, and pop3. It has bundles of static resources of different sizes i.e. 1k, 10k, and 1 MB (responses).

You can ensure your site readiness by utilizing NetOcean’s service virtualization capabilities to:

1. Remove dependencies on external systems and applications during performance testing. For example, an e-commerce application has to integrate with a third-party payment gateway. Hence testing the checkout functionality of this application has a dependency on the payment gateway.
2. Remove dependency of development and testing teams on back-end or production systems, so they can deliver software faster.

Plan for contingency and disaster recovery

In an ideal world, you should be set for stress-free user traffic. But the unthinkable could happen. Your cloud service provider could go down or one service in a particular region could be impassive. An urgent code fix could have an unpredicted effect & consequences. Eventuality planning is key to this. Start with a support policy in place for your databases and assets. Fully automated CI/CD pipelines will allow deploying code to any new architecture as well. Cloud providers such as Microsoft Azure and Amazon AWS allow for a geo-replication that allows for your website to function even if a data center ceases to exist. Decide how much downtime you can tolerate and work your way from there when planning for an eventuality and a disaster recovery.