WO2025196802A1

WO2025196802A1 - System and method for web performance testing

Info

Publication number: WO2025196802A1
Application number: PCT/IN2025/050248
Authority: WO
Inventors: Pradeep Kumar Bhatnagar; Aayush Bhatnagar; Haresh Ambaliya; Bhoopendra THAKUR; Yogita GUNJAL; Priyamvada Singh
Original assignee: Jio Platforms Ltd
Current assignee: Jio Platforms Ltd
Priority date: 2024-03-21
Filing date: 2025-02-19
Publication date: 2025-09-25
Anticipated expiration: 2026-09-21

Abstract

The present disclosure provides a system (102) and a method for web performance testing. The system (102) initiates a web performance test through a web performance testing software module installed on a user equipment, which 5 generates test result data upon completion. An input module receives the test result data from the web performance testing software module. A synchronization module transmits the test result data to a load balancer, which distributes it across a network of servers. These servers stream the test result data into a distributed event streaming platform. A processing module retrieves and processes the streamed data 10 to generate processed test results, which are then stored in one or more databases. The system facilitates efficient web performance testing by managing and processing large volumes of test data across distributed resources.

Description

SYSTEM AND METHOD FOR WEB PERFORMANCE TESTING

RESERVATION OF RIGHTS

[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and/or trade dress protection, belonging to JIO PLATFORMS LIMITED or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.

FIELD OF THE DISCLOSURE

[0002] The embodiments of the present disclosure generally relate to wireless communication networks. In particular, the present disclosure relates to a system and method for web performance testing.

DEFINITION

[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.

[0004] Web performance testing refers to a process of evaluating and measuring the speed, responsiveness, and stability of web applications or websites under various conditions.

[0005] User equipment refers to a device capable of accessing web resources and running performance tests, such as smartphones, tablets, laptops, or desktop computers. [0006] Web performance testing software module refers to a specialized application installed on the user equipment that facilitates the execution of web performance tests and collection of performance metrics.

[0007] Page load time refers to a duration required for a web page to fully load, from the initial request to the complete rendering of all elements.

[0008] Time to first byte (TTFB) refers to a duration between sending a Hypertext Transfer Protocol (HTTP) request and receiving a first byte of a response from a server.

[0009] Time to interactive refers to a duration required for a web page to become fully interactive, with all visual elements rendered and event handlers attached.

[0010] Network latency refers to delays in data transmission over a network, often measured as the time taken for data packets to travel from source to destination.

[0011] Encryption refers to a process of converting data into a coded format to protect its confidentiality and integrity during transmission or storage.

[0012] Work order refers to a set of automated testing tasks scheduled to be performed at specified intervals without manual intervention.

BACKGROUND OF THE DISCLOSURE

[0013] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art. [0014] As wireless technologies advance, there is a need to cope with the 5G and 6G requirements and deliver a high level of service to customers. In recent years, mobile devices have become common with powerful processors, larger and more colorful displays, and wireless networking capabilities. However, mobile devices typically have limitations on memory capacity, data storage capacity, and central processing unit (CPU) capacity.

[0015] As wireless networks evolve, mobile devices are moving from being occasionally connected to near-constant network connectivity. Further, the various mobile applications (apps) that are developed, built, and deployed are changing with the increasing internet speed. As such, real-time results of the applications' performance are necessary wherever mobile applications are to be deployed for measuring metrics of the app upon deployment. This type of mobile application performance management is necessary to identify issues quickly before user complaints are realized.

[0016] Web performance testing (WPT) is a critical process for ensuring the quality and reliability of mobile applications. WPT involves using software tools to simulate how a mobile application runs under an expected workload and measuring according to benchmarks and standards. However, conventional systems and methods for WPT face several challenges.

[0017] Current systems struggle to successfully synchronize the data collected/captured from the mobile devices to backend systems, leading to potential data loss and incomplete test results. Existing solutions often fail to provide realtime insights into application performance, delaying identifying critical issues. As the mobile applications grow in complexity and scale, measuring and monitoring their performance in complex distributed systems becomes increasingly difficult, requiring the allocation of more resources.

[0018] The current systems suffer from data leakage problems, posing significant risks to sensitive test data and potentially compromising the integrity of the testing process. Given the limitations of mobile devices in terms of memory, storage, and processing power, conventional WPT methods may not be optimized for efficient resource utilization. Existing solutions often struggle to effectively manage and coordinate tests across multiple servers and platforms, leading to inconsistent results and inefficient use of testing resources.

[0019] These limitations can result in a degradation of mobile application performance and a corresponding negative user experience. If such bottlenecks are not immediately identified upon deployment, users are less likely to use the mobile applications again, which eventually results in loss of user base and widespread mobile application adoption. Conventional systems and methods face difficulty in providing a comprehensive, secure, and efficient solution for web performance testing that addresses the challenges of data synchronization, real-time analysis, and scalability while optimizing resource utilization on mobile devices.

[0020] There is, therefore, a need in the art to provide a method and a system that can overcome the shortcomings of the existing prior arts.

SUMMARY OF THE DISCLOSURE

[0021] In an exemplary embodiment, a system for web performance testing is described. The system includes a memory, and one or more processors coupled to the memory. The one or more processors are configured to execute a set of instructions stored in the memory. The set of instructions includes receiving, by an input module, a test result data from a web performance testing software module installed on a user equipment. The set of instructions also includes transmitting, by a synchronization module, the generated test result data to a load balancer. The set of instructions further includes distributing, by the load balancer, the transmitted test result data to at least one server of a plurality of servers. The set of instructions also includes streaming, by the at least one server of a plurality of servers, the distributed test result data into a distributed event streaming platform. The set of instructions further includes retrieving, by a processing module, the streamed test result data from the distributed event streaming platform. The set of instructions also includes processing, by the processing module, the retrieved test result data to generate a processed test result data. The set of instructions further includes storing, by the processing module, the processed test result data in one or more databases.

[0022] In some embodiments, the test result data includes a set of parameters related to at least one of a page load time, a time to first byte, a time to interactive, or a network latency.

[0023] In some embodiments, a test execution module is configured to transmit a web performance work order comprising one or more attributes to the web performance testing software module, wherein the one or more attributes include a specific time and a random time interval.

[0024] In some embodiments, the random time interval is used to distribute network load and prevent simultaneous data transmissions from a plurality of user equipments.

[0025] In some embodiments, the web performance testing software module is configured to extract the one or more attributes from the web performance work order and initiate the web performance test based on the extracted one or more attributes to generate the test result data upon completion of the web performance test.

[0026] In some embodiments, the web performance testing software module is configured to generate a sync request to sync the test result data with the data stored in the one or more databases.

[0027] In some embodiments, the web performance testing software module is further configured to initiate the web performance test by opening a web interface by the web performance testing software module on the user equipment.

[0028] In some embodiments, the web performance testing software module is further configured to execute the web performance test by parsing one or more Uniform Resource Locators (URLs) to retrieve at least one of a protocol, a host, a port, or a path. [0029] In some embodiments, the web performance testing software module is further configured to encrypt the generated test result data before transmission to the synchronization module.

[0030] In some embodiments, the processing module is configured to process the retrieved test result data by decrypting the retrieved test result data.

[0031] In some embodiments, the processing module is further configured to process the retrieved test result data by mapping the retrieved test result data with location data before storage. The location data includes at least one of: latitude, longitude, Cell ID, Mobile Country Code (MCC), or Mobile Network Code (MNC).

[0032] In some embodiments, the system further includes a gateway server. The gateway server is configured to receive the processed test result data from the processing module. Additionally, the gateway server manages data flow between the processing module and the one or more databases based on a set of predefined criteria.

[0033] In some embodiments, the web performance testing software module is configured to transmit the generated test result data by performing steps comprising of delaying the transmission of the test result data by the extracted random time interval and transmitting the test result data after the delay.

[0034] In another exemplary embodiment, a method for web performance testing is described. The method includes receiving, by an input module, a test result data from a web performance testing software module installed on a user equipment. The method includes initiating, by a test execution module, a web performance test within the web performance testing software module on the user equipment to generate test result data upon completion of the web performance test. The method also includes transmitting, by a synchronization module, the generated test result data to a load balancer. The method further includes distributing, by the load balancer, the transmitted test result data to at least one server of a plurality of servers. The method also includes streaming, by the at least one server of a plurality of servers, the distributed test result data into a distributed event streaming platform. The method further includes retrieving, by a processing module, the streamed test result data from the distributed event streaming platform. The method also includes processing, by the processing module, the retrieved test result data to generate the processed data. The method further includes storing, by the processing module, the processed test result data in one or more databases.

[0035] In some embodiments, further comprising transmitting, by a test execution module, a web performance work order including one or more attributes to the web performance testing software module, wherein the one or more attributes include a specific time and a random time interval.

[0036] In some embodiments, the random time interval is used to distribute network load and prevent simultaneous data transmissions from a plurality of user equipments.

[0037] In some embodiments, the method includes extracting, by the web performance testing software module, the one or more attributes from the web performance work order and initiating the web performance test based on the extracted one or more attributes to generate the test result data upon completion of the web performance test.

[0038] In some embodiments, the method includes generating, by the web performance testing software module, a sync request to sync the test result data with the data stored in the one or more databases after establishing a connection between the system or completion of the web performance work order.

[0039] In some embodiments, executing the web performance test further includes parsing, by the web performance testing software module, one or more Uniform Resource Locators (URLs) to retrieve at least one of a protocol, a host, a port, or a path. [0040] In some embodiments, processing the retrieved test result data includes decrypting the retrieved test result data.

[0041] In some embodiments, transmitting the generated test result data further includes delaying the transmission of the test result data by the extracted random time interval. Transmitting the generated test result data further includes transmitting the test result data after the delay.

[0042] In some embodiments, the processing the retrieved test result data further includes mapping, by the processing module, the processed test result data with location data before storage. The location data includes at least one of latitude, longitude, Cell ID, Mobile Country Code (MCC), or Mobile Network Code (MNC).

[0043] In some embodiments, the method further includes receiving, by a gateway server, the processed test result data from the processing module. The method further includes managing data flow between the processing module and the one or more databases based on a set of predefined criteria.

[0044] In another exemplary embodiment, the present disclosure discloses a non-transitory computer-readable medium storing instructions that, when executed by one or more processors of a system for web performance testing. The instructions cause the one or more processors to perform one or more operations including receiving, by an input module, a test result data from a web performance testing software module installed on a user equipment. The one or more operations further include transmitting, by a synchronization module, the generated test result data to a load balancer. The one or more operations further include distributing, by the load balancer, the transmitted test result data to at least one server of a plurality of servers. The one or more operations further include streaming, by the at least one server of the plurality of servers, the distributed test result data into a distributed event streaming platform. The one or more operations further include retrieving, by a processing module, the streamed test result data from the distributed event streaming platform. The one or more operations further include processing, by the processing module, the retrieved test result data to generate a processed test result data. The one or more operations further include storing, by the processing module, the processed test result data in one or more databases.

[0045] In yet another exemplary embodiment, a user equipment communicatively coupled to a system for web performance testing via a network is described. The coupling comprises steps of receiving a connection request, sending an acknowledgment of the connection request to the system, and transmitting a plurality of signals in response to the connection request. The user equipment is configured to initiate, by a web performance testing software module, a web performance test to generate test result data upon completion of the web performance test. The user equipment is configured to transmit the test result data from the web performance testing software module to the system. The system is configured to transmit, by a synchronization module, the generated test result data to a load balancer. The system is configured to distribute, by the load balancer, the transmitted test result data to at least one server of a plurality of servers. The system is configured to stream, by the at least one server of the plurality of servers, the distributed test result data into a distributed event streaming platform. The system is configured to retrieve, by a processing module, the streamed test result data from the distributed event streaming platform. The system is configured to process, by the processing module, the retrieved test result data to generate a processed test result data. The system is configured to store, by the processing module, the processed test result data in one or more databases.

[0046] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.

OBJECTIVES OF THE DISCLOSURE

[0047] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies are as listed herein below. [0048] An objective of the present disclosure is to provide a system and a method for web performance testing (WPT).

[0049] An objective of the present disclosure is to provide the system and the method for the WPT data collection that synchronizes the data collected from the user equipment and performs the data synchronization without data leakage.

[0050] An objective of the present disclosure is to provide the system and the method for the WPT data collection that captures data on a plurality of servers so that the data can be used for further analysis and reporting.

[0051] An objective of the present disclosure is to provide the system and the method for web performance testing that ensures the transmission of test result data from the user equipment to the load balancer.

[0052] An objective of the present disclosure is to provide the system and the method for web performance testing that distributes test result data across the plurality of servers to enhance processing efficiency.

[0053] An objective of the present disclosure is to provide the system and the method for web performance testing that utilizes the distributed event streaming platform for handling the test result data.

[0054] An objective of the present disclosure is to provide the system and the method for web performance testing that optimizes network load by implementing random time intervals for data transmission from multiple user equipments.

[0055] An objective of the present disclosure is to provide the system and the method for web performance testing that enhances data analysis by mapping the processed test result data with location data. [0056] An objective of the present disclosure is to provide the system and the method for web performance testing that ensures data security through encryption and decryption of the test result data.

[0057] An objective of the present disclosure is to provide the system and the method for web performance testing that can be implemented on the user equipment.

BRIEF DESCRIPTION OF DRAWINGS

[0058] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes the disclosure of electrical components, electronic components or circuitry commonly used to implement such components.

[0059] FIG. 1 illustrates an exemplary network architecture of a system for web performance testing, in accordance with embodiments of the present disclosure.

[0060] FIG. 2 illustrates a system architecture for web performance testing, in accordance with embodiments of the present disclosure.

[0061] FIG. 3 illustrates an exemplary flow diagram of a method for web performance testing, in accordance with embodiments of the present disclosure.

[0062] FIG. 4 illustrates an exemplary block diagram of the system, in accordance with embodiments of the present disclosure. [0063] FIG. 5 illustrates another exemplary flowchart of the method for web performance testing, in accordance with embodiments of the present disclosure.

[0064] FIG. 6 illustrates an exemplary computer system in which or with which embodiments of the present disclosure may be implemented.

[0065] The foregoing shall be more apparent from the following more detailed description of the disclosure.

LIST OF REFERENCE NUMERALS

100 - Network architecture

102 - System

104- Network

106 - Centralized server

108-1, 108-2... 108-N - User equipment(s)

110-1, 110-2...110-N - Users

200 - Block diagram

202 - web performance testing software module

204 - Load balancer

206 - A plurality of servers

208 - Distributed event streaming platform

210 - Gateway server

212a, 212b - One or more databases

300 - Flow diagram

402 - One or more processor(s)

404 - Memory

406 - I/O interface(s)

408 - Processing component(s)

412 - Input module

414 - Test execution module

416 - Synchronization module

418 - Processing module 420 - Other modules

500 - Flowchart

610 - External Storage Device

620 - Bus

630 - Main Memory

640 - Read Only Memory

650 - Mass Storage Device

660 - Communication Port

670 - Processor

DETAILED DESCRIPTION OF THE DISCLOSURE

[0066] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address all of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein.

[0067] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.

[0068] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0069] Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0070] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising” as an open transition word without precluding any additional or other elements.

[0071] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0072] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.

[0073] As mobile applications, which are software programs designed to run on smartphones and other mobile devices, grow in complexity and scale, measuring and monitoring their performance in complex distributed systems becomes increasingly difficult, requiring allocation of more resources. These mobile applications often rely heavily on web technologies and services, blurring the line between traditional websites and mobile apps. Consequently, web performance testing (WPT) has become a critical aspect of mobile application development and maintenance. The performance of web components within mobile apps, such as API calls, content loading, and data synchronization, directly impacts the overall user experience and functionality of these applications.

[0074] Traditional techniques for web performance testing fail to provide an adequate solution for the unique challenges posed by mobile applications. These techniques are often designed for desktop-centric web environments and struggle to account for the diverse and dynamic nature of mobile app ecosystems. They are particularly inefficient in synchronizing large amounts of performance data from numerous mobile devices to backend servers, a crucial requirement for comprehensive mobile app performance analysis. Moreover, these conventional methods often lack the ability to simulate real-world mobile network conditions, device-specific rendering issues, and the impact of background processes on app performance. As a result, they fall short in providing accurate and actionable insights for optimizing the web components of mobile applications.

[0075] Therefore, there is a pressing need for an advanced WPT solution that can effectively address the complexities of mobile application environments, ensure efficient data synchronization, and provide comprehensive performance insights across various devices, networks, and usage scenarios.

[0076] The present disclosure aims to overcome the above-mentioned and other existing problems by providing an improved system and method for WPT. The present disclosure provides an improved system and method for WPT data collection that efficiently synchronizes data collected from user equipment and performs data synchronization without leakage, ensuring maximum data capture at the servers for further analysis and reporting. The present disclosure helps different teams of telecom service providers to evaluate network performance. It enables real-time network optimization based on evaluated performance. The WPT data collection may be performed through scripts executed in the background, collecting data without user interference. The WPT provided by the present disclosure allows for continuous monitoring and improvement, ensuring that a website maintains its speed and reliability over time.

[0077] The aspects of the present disclosure are directed to a system and method for web performance testing that enables efficient data collection, secure transmission, and distributed processing of test result data. The system includes a synchronization module for secure data transmission, a load balancer for distributing test data across multiple servers, and a distributed event streaming platform for efficient data handling and processing. These elements work together to improve data synchronization, enhance security, and enable real-time analysis of mobile application performance.

[0078] The various embodiments throughout the disclosure will be explained in more detail with reference to FIGS. 1-6.

[0079] FIG. 1 illustrates an exemplary network architecture (100) of a system (102) for web performance testing (WPT), in accordance with embodiments of the present disclosure.

[0080] As illustrated in FIG. 1, one or more user equipments (108-1, 108- 2...108-N) may be connected to the system (102) for web performance testing in a network environment through a network (104). A person of ordinary skill in the art will understand that the one or more user equipments (108-1, 108-2...108-N) may be collectively referred to as user equipments (108) and individually referred to as a user equipment (108). The user equipments (108) are operated by users (110-1, 110-2...110-N).

[0081] In an embodiment, the user equipment (108) may include, but not be limited to, a mobile phone, a tablet, a smartphone, a desktop computer, a laptop computer, or any other device capable of interacting with the system (102) for web performance testing. Additionally, in some embodiments, the UE (108) may include, but is not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication capabilities, and the like. A person of ordinary skill in the art will appreciate that the UE (108) may not be restricted to the mentioned devices and various other devices may be used. [0082] Referring to FIG. 1, the UE (108) may communicate with the system (102) through a network (104) for sending or receiving various types of data. In an embodiment, the network (104) may include at least one of a fifth generation (5G) network, sixth generation (6G) network, or the like. The network (104) may enable the UE (108) to communicate with other devices in the network architecture (100) and/or with the system (102). The network (104) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (104) may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like. The system (102) may be connected to a centralized server (106).

[0083] In an embodiment, the UE (108) is communicatively coupled with the network (104). The network (104) may receive a connection request from the UE (108). The network (104) may send an acknowledgment of the connection request to the UE (108). The UE (108) may transmit a plurality of signals in response to the connection request.

[0084] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100).

[0085] FIG. 2 illustrates an exemplary system architecture (200) for the system (102) for web performance testing (WPT), in accordance with an embodiment of the present disclosure.

[0086] The system architecture (200) includes a web performance testing software module (“also referred to as software module”) (202) that initiates a WPT process. The software module (202) may be a specialized application or program installed on the user equipment (108). The software module may provide a user interface for initiating web performance tests, configuring test parameters, and viewing test results.

[0087] The user equipment (108) on which the software module (202) is installed may encompass a wide range of devices capable of accessing web content and running performance tests. The wide range of devices may include mobile devices such as smartphones and tablets, which are particularly useful for testing web performance in various network conditions and locations. For example, a field technician might use a smartphone with the testing software installed to conduct performance tests at different geographic locations within a cellular network. Laptops and desktop computers may also serve as user equipment (108) for web performance testing. These devices typically offer more processing power and larger screens, which can be advantageous for running more complex tests or analyzing detailed results. For instance, a web developer might use a laptop with the testing software to conduct thorough performance audits of a website during development and optimization phases. The key requirement for any device serving as user equipment (108) is the ability to install and run the software module (202), as well as to connect to the internet and access the web resources being tested.

[0088] In an aspect, the system may include a web performance server that may be configured to generate a web performance work order (“also referred to as work order”) for each UE in the network. In an aspect, the server may be communicated with at least one network management system which is configured to receive the test result data from each UE and is further configured to analyze the data to detect at least one problem associated with the network. In an example, the web performance work order may include a UE identifier, a specific time or a random time. In an example, the random time interval is used to distribute network load and prevent simultaneous data transmissions from a plurality of user equipments (108). [0089] In an operative aspect, to conduct the WPT on the user equipment, the user may install the software module (202) by establishing a connection with the server. After establishing the connection, the server may instruct the software module to conduct or initiate the connection WPT on real-time basis by sending a WPT request.

[0090] When the software module (202) conducts the WPT, the software module (202) generates the test result data. Before transmission, the web performance testing software module (202) may encrypt the test result data. This encryption process is a crucial security measure designed to protect the confidentiality and integrity of the performance measurements as they are transmitted over the network. Encryption may involve using advanced cryptographic algorithms to convert the plain text data into ciphertext that can only be decrypted by authorized parties with the appropriate decryption keys.

[0091] In an example, the software module (202) installed in each UE is configured to transmit the test result data towards the server. The test result data is received by a load balancer (204). The load balancer (204) is a shared component that distributes incoming test result data from the plurality of test result data, received from the plurality of UEs, across multiple servers to ensure optimal resource utilization and high availability. Upon receiving the test result data, the load balancer (204) redirects the received test result data to a plurality of servers (206), denoted as DI, D2,. . ., D4, and so on. These servers (206) are responsible for handling the test result data and processing the test results. In one embodiment, the servers (206) are implemented as Drop wizard servers, lightweight, high- performance web servers designed to build RESTful web services and microservices.

[0092] The servers (206) implement a RESTful microservice architecture, which means they expose a set of well-defined, stateless, and scalable web services that can be consumed by the software module (202) and other components of the system. RESTful services use HTTP methods such as GET, POST, PUT, and DELETE to perform operations on Uniform Resource Locator (URL)-identified resources. GET is used to retrieve data from the server, allowing clients to access a resource or collection of resources without modifying them. POST is employed to create new resources, sending data to the server for storage. PUT is used to update an existing resource, replacing its current state with the new data provided, while DELETE removes a resource from the server. These HTTP methods, in conjunction with other principles of REST like statelessness and a uniform interface, enable the development of scalable, efficient, and easily understandable APIs for web applications.

[0093] To distribute the test result data evenly across the servers (206), the load balancer (204) employs a round-robin load-balancing technique. In this technique, the load balancer (204) forwards each incoming test result data to the next server in a circular order. For example, if there are four servers (DI, D2, D3, D4), the first test result data goes to DI, the second test result data goes to D2, and so on. When the load balancer reaches the end of the server list, it starts again from the beginning, ensuring that each server receives an equal number of test result data over time.

[0094] After processing the test result data, the servers (206) insert the test result data into a distributed event streaming platform (208). The distributed event streaming platform (208) is a scalable and fault-tolerant system that allows for realtime processing, storage, and analysis of large volumes of data. The distributed event streaming platform (208) acts as a message queue where the WPT results (test result data) are published and consumed by other system components.

[0095] The WPT results stored in the distributed event streaming platform (208) are then forwarded to a gateway server (210). The gateway server (210) processes the WPT results based on the specific test type and requirements. The gateway server (210) uses various tools and techniques to analyze and transform the test result data into a format suitable for storage and further analysis. After processing, the gateway server (210) forwards the WPT results to one or more databases or a database management system for persistent storage. In one example, the database management system used may be an Apache HBase, a distributed, column-oriented NoSQL database designed for handling large-scale structured data.

[0096] The process of conducting the WPT process using this system architecture involves several steps. First, the software module (202) opens a web interface to perform the WPT. In an example, the web interface may be a browser or an application. The browser may be opened in the background if the WPT request is triggered at the specific time as included in the work order, allowing the test to run without user intervention. To initiate the WPT, the browser parses one or more Uniform Resource Locators (URLs) of the web page or application being tested to extract the information such as protocol (e.g., HTTP, HTTPS), host, port, and path. This information is necessary to construct the complete test result data for the WPT.

[0097] Once the WPT is completed, the test result data is generated. To ensure the security and confidentiality of the test results, the data is encrypted using a custom encryption technique. The encrypted test results are stored in a file, for example, in a comma-separated values (CSV) format. The CSV file contains rows of test result data, with each value separated by a comma and each record on a new line.

[0098] The synchronization of the WPT result files between the software module (202) and the backend system (may be the server also) is performed periodically based on a time event. This synchronization is facilitated by a RESTful Application Programming Interface (API), which allows the application to transmit the test result files to the backend system securely.

[0099] During the synchronization process, the RESTful API authenticates the WPT result data using a security key to ensure the integrity and authenticity of the data. Once authenticated, the WPT result data is stored in the distributed event streaming platform (208) for further processing. [00100] The WPT result data stored in the distributed event streaming platform (208) is then read and decrypted using various custom techniques. The decrypted data is enriched with location information, such as latitude, longitude, cell identifier (cell-id), mobile country codes (MCC), or mobile network codes (MNC), which are obtained from the mobile application. MCC identifies the country of the mobile network operator, allowing the system to recognize which country the user is in. MNC identifies the specific mobile network operator within the country, which helps distinguish between different carriers in the same country. Finally, the mapped and enriched WPT result data is stored in one or more databases or a database management system for future analysis and reporting purposes.

[00101] The system architecture described in the present disclosure leverages a combination of mobile application calls and background API calls to facilitate efficient data synchronization and processing. The mobile application initiates the data synchronization call, which triggers the corresponding API call to the backend system. This architecture allows for seamless integration between the mobile application, the backend API, and the backend batch job processing components.

[00102] To ensure the security of the WPT result data, the system employs custom encryption and decryption methods. The data is encrypted before transmission and decrypted securely in the backend system. Additionally, the synchronized API uses key-based authentication to verify the authenticity of the data and prevent unauthorized access.

[00103] Using a distributed event streaming platform (208) for data synchronization provides a robust and fault-tolerant mechanism for handling WPT result data. If the parsing service encounters an issue and cannot parse the user's data, the data is not lost. Instead, it is retained in the distributed event streaming platform topics, which have a retention time of approximately 7 days. This ensures that the data remains available for reprocessing and analysis even if temporary failures occur in the parsing pipeline. [00104] FIG. 3 illustrates an exemplary flow diagram for a method (300) of the WPT, in accordance with an embodiment of the present disclosure.

[00105] At step 302, data capturing is performed at a device end, such as a mobile device. Data capturing involves collecting various performance metrics and data points during the execution of the web performance test. This data may include information such as page load times, resource loading times, network latency, and other relevant metrics. The web performance testing software module running on the device typically captures the data. For example, suppose the user initiates the web performance test for a particular website using the testing application on his smartphone. As the test runs, the web performance testing software module captures data points such as the time taken for the website's HTML document to load, the time to load each resource (images, scripts, stylesheets), and the total time taken for the page to become fully interactive.

[00106] At step 304, data synchronization is performed. Data synchronization involves transmitting the captured performance data (test result data) from the mobile device to the backend servers for further processing and analysis. The data synchronization process is typically triggered by specific application events, such as completing a test run or reaching a certain data volume threshold. The data synchronization call is made when an application event associated with the WPT occurs. The hits (requests) for the data synchronization call, which represent individual data transmission requests, are passed to the load balancer. The load balancer is responsible for distributing these hits across the plurality of servers, such as a cluster of Drop wizard servers. This distribution ensures that the data processing load is evenly spread and that no single server becomes a bottleneck. For instance, the web performance testing software module on the user's smartphone has completed the test run and captured 50 KB of performance data. The web performance testing software module initiates a data synchronization call when the test completion event is detected. The data is sent as a "hit" to the load balancer, which then routes it to one of the available Drop wizard servers for processing. [00107] At step 306, the captured data undergoes processing. The raw data captured by the web performance testing software module is often unstructured or semi-structured. To make this data suitable for analysis and storage, it needs to be processed and transformed into a more organized and manageable format. During the data processing step, the format of the captured data is changed from an unorganized format to an organized format. This may involve parsing the raw data, extracting relevant metrics, and converting them into a structured format. The processed data is then typically stored in the distributed event streaming platform, which enables real-time processing and analysis of the performance data.

[00108] At step 308, the processed data is stored in at least one database or the database management system for persistence and further analysis. The choice of database depends on factors such as data volume, query patterns, and scalability requirements. In one example, the database management system used could be Apache HBase, a distributed, column-oriented database well-suited for handling large volumes of structured data. The stored performance data can then be used for various purposes, such as generating reports, identifying performance bottlenecks, and guiding optimization efforts. Developers and stakeholders may query the database to gain insights into the web application's performance characteristics over time and across different devices and network conditions.

[00109] The WPT process described in the present disclosure encompasses various aspects of web application performance evaluation. By capturing performance data on the device, synchronizing it with the server through a load- balanced architecture, and processing and storing the data using distributed systems and databases, the WPT process enables comprehensive and scalable performance testing. The use of load generators, test scenarios, and monitoring tools helps simulate real-world conditions and identify performance bottlenecks. The efficient handling of test result data on the device ensures optimal storage utilization and reliable synchronization with the server. Ultimately, the WPT process empowers developers and organizations to gain actionable insights into their web applications' performance and optimize them for better user experiences. [00110] In an experimental aspect, the present disclosure is configured to perform the following steps:

• Generating a random sync time generated for every user equipment. In an aspect, the number of sync attempts is restricted to only ONCE in APP Launch (for any event).

• Enabling the Load Generators responsible for simulating the load on the web application, representing a real-time network setup.

• Defining various scripts or scenarios that simulate different user interactions with the web application.

• Employing various monitoring and profiling tools to monitor various aspects of the system during testing, including network performance and database performance.

• Employing the Load Balancers: In scenarios where a web application uses load balancing, the testing should include load balancing configurations to ensure that the system distributes the load effectively among servers.

• Collecting the data that has been stored in the internal storage of the user equipment. For example, the data has a file size limit of 300 KB. After data is synced to the server, the existing file is deleted.

[00111] FIG. 4 illustrates an exemplary block diagram (400) of the system (102) for web performance testing in a network environment, in accordance with an embodiment of the present disclosure. In an aspect, the system (102) may include the backend system (server) and is connected to the plurality of user equipments (108). In an embodiment, FIG. 4 shows an exemplary block diagram of the backend system (server). Web performance testing refers to a comprehensive evaluation and measurement of a web application's speed, responsiveness, and stability under various conditions. This testing process is crucial for ensuring optimal user experience and identifying potential performance bottlenecks before they impact end-users.

[00112] Referring to FIG. 4, in an embodiment, the system (102) may include one or more processors (402). The one or more processors (402) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processors (402) may be configured to fetch and execute computer-readable instructions stored in a memory (404) of the system (102). The memory (404) may be configured to store one or more computer- readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to perform web performance testing in the network environment. The one or more processors (402) may be configured to execute a set of instructions stored in the memory (404) to perform various operations related to web performance testing.

[00113] In an embodiment, the system (102) may include I/O interface(s) (406). The I/O interface(s) (406) may comprise a variety of interfaces, for example, interfaces for data input and output devices, storage devices, and the like. The I/O interface(s) (406) may facilitate communication through the system (102). The I/O interface(s) (406) may also provide a communication pathway for one or more components of the system (102). Examples of such components include, but are not limited to, the one or more processors (402), a processing component(s) (408), and one or more databases (212a, 212b) for storing web performance test data.

[00114] The processing component(s) (408) may include an input module (412), a test execution module (414), a synchronization module (416), a processing module (418), and other modules (420).

[00115] The input module (412) is configured to receive the test result data or a WPT request (sync request) for syncing/storing the test result data with the backend system from the software module (202) installed on the user equipment (108). The input module (412) may be a software component or subsystem specifically designed to handle incoming requests from the plurality of UEs. The input module (412) may utilize various communication protocols and interfaces to accept requests from external sources, such as user equipments or automated testing systems. In an aspect, the input module (412) may receive a web performance test request received by the input module (412). The web performance test request may be received by an operator for initiating the WPT on the plurality of UEs of a specific area to get insights about the network. The web performance test request received by the input module (412) may comprise a set of parameters related to specific aspects of web performance that are to be tested. By specifying the set of parameters in the test request, users or automated systems may customize the focus of each performance test to align with their specific concerns or optimization goals.

[00116] In an aspect, the test execution module (414) may be configured to generate the web performance work order. For example, the web performance work order may include one or more attributes. In an example, the one or the specific time and the random time interval. For example, the specific time may represent a time at which the WPT is initiated at the user end on the web performance testing software module. The random time interval is used by the web performance testing software module to delay the transmission of the test result data. The random time interval is used to distribute network load and prevent simultaneous data transmissions from the plurality of user equipments (UEs).

[00117] In an example, the web performance testing software module may be configured to receive the web performance work order from the system. The web performance testing software module may be configured to extract the one or more attributes from the web performance work order. Based on the extracted specific time, the web performance testing software module installed on the UE is configured to initiate the web performance test. In an example, the user may manually trigger a test through the interface of the web performance testing software module, perhaps by entering a specific URL and selecting desired test parameters. Alternatively, the trigger may be generated automatically as part of a scheduled testing routine, where the web performance testing software module is programmed to conduct regular performance checks on a set of predefined web resources.

[00118] The web performance testing software module is further configured to generate the test result data upon completion of the web performance test. In an example, the test result data includes a set of parameters related to at least one of a page load time, a time to first byte, a time to interactive, or a network latency. In an aspect, the web performance testing software module is configured to generate a sync request to sync the test result data with the data stored in the one or more databases after establishing a connection between the system or completion of the web performance work order. The sync request prompts the system to send the test result data to the main server or database, where it is merged or updated with existing data. The synchronization process ensures that all collected data, whether obtained online or offline, is consistent and up-to-date in the centralized database for further analysis or reporting. The web performance testing software is designed to continue collecting critical data, such as test results, logs, and performance metrics, even when offline. This data is temporarily stored in local storage, which could be the device's hard drive, a local database (e.g., SQLite), or in cache, ensuring that no valuable data is lost during periods of no internet connection.

[00119] The data is usually stored in structured formats like JSON, CSV, or in a local database, making it easy to organize and retrieve later for analysis or synchronization with the central server. Storing the data in such structured formats also ensures that the data can be processed or converted into the required format when it’s time to upload it.

[00120] The software module is equipped with the functionality to detect an appropriate moment to sync the test result data. In an example, the appropriate moment may include a launch of the specialized application by the user. This detection process typically involves checking if the device is back online (i.e., it has a stable network connection), or if the testing session (work order) has been completed. Once these conditions are met, the software triggers a sync process, which involves uploading the collected data to the central database or server for further analysis, storage, or reporting.

[00121] The web performance work order may include a set of parameters such as page load time, Time to first byte (TTFB), time to interactive, and network latency. The page load time measures the duration for a web page to fully load, from the moment the user initiates the request to the point where all content, including text, images, scripts, and other resources, has been downloaded and rendered in the browser. Page load time is critical to overall web performance and user experience. For example, an e-commerce website might set a target page load time of under 3 seconds for its product pages, as research has shown that longer load times can significantly increase bounce rates and reduce conversions. The TTFB measures the duration between the browser sending an HTTP request and receiving the first byte of data from the server in response. TTFB is a valuable indicator of server responsiveness and network conditions. A high TTFB could suggest issues with server processing, database queries, or network latency. The time to interactive measures the duration for a web page to become fully interactive for the user, meaning all visual elements are rendered and event handlers are attached, allowing users to interact with the page elements. For example, a social media platform might prioritize a low time to interactive to ensure that users can start scrolling, clicking, and interacting with content as soon as possible after navigating to a new page. The network latency measures delay in data transmission over the network, reflecting the time it takes for data packets to travel from the source to the destination. Network latency can significantly impact user experience, especially for applications requiring real-time interactions. For example, an online gaming platform might include network latency as a critical parameter in its performance tests to ensure smooth gameplay and responsiveness across different network conditions.

[00122] Upon receiving the web performance test request from the network operator, the test execution module (414) of the system (102) may transmit the web performance work order towards the web performance testing software module. On receiving the web performance work order, the web performance test will be initiated within the web performance testing software module on the user equipment (108). The test execution module (414) is responsible for coordinating and managing the actual execution of performance tests based on the received web performance test requests. The test execution module (414) may interface with the web performance testing software module installed on the user equipment (108) through a predefined API or communication protocol. This interaction allows the system (102) to trigger remotely and control test executions on various user equipments, enabling a distributed testing approach to capture performance data across different hardware configurations and network environments.

[00123] When initiating the test, the test execution module may first parse and validate the parameters specified in the test request. For instance, if the test request specifies the URL to be tested but omits essential parameters like the target page load time, the test execution module (414) may either apply default values or return an error message requesting additional information.

[00124] In an example, the test execution module (414) may then translate the validated parameters into a set of instructions or configuration settings that the web performance testing software module can understand and execute. This translation process may involve mapping high-level test requirements to specific testing actions or scripts. For example, a web performance work order to measure page load time might be translated into a series of steps, including clearing the browser cache, navigating to the specified URL, and recording various timing events during the page load process.

[00125] Once the test parameters have been processed and translated, the test execution module (414) may trigger the software module (202) to execute the requested web performance test. This triggering mechanism may involve sending a start signal or command to the software module (202) along with the necessary configuration data derived from the original test request. [00126] The test execution module (414) may also be responsible for managing concurrent test executions across multiple user equipments (108). This capability allows the system (102) to conduct large-scale performance testing campaigns, simulating real-world traffic patterns and load conditions. For instance, an e-commerce platform preparing for a major sale event might use the system to simultaneously initiate performance tests from hundreds or thousands of user equipments, providing insights into how their website performs under high concurrent user loads.

[00127] The software module (202), upon receiving the trigger from the test execution module (414), may then initiate the test procedures (a set of work orders) on the user equipment (108). To initiate the web performance test, the software module (202) may open a browser on the user equipment (108). The browser serves as a primary tool for interacting with web resources and collecting performance metrics during the test execution. The browser opened by the test execution module (414) may be a standard web browser installed on the user equipment (108).

[00128] The software module (202)may open the browser in different modes depending on how the test was initiated, allowing for flexibility in test execution and user experience. This adaptive approach caters to various testing scenarios and user preferences, enhancing the versatility of the system (102).

[00129] For a user-initiated web performance test request, the browser may be opened in the foreground on the user equipment (108). This mode allows the user to observe the test execution in real-time. In contrast, the browser may be opened in the background without requiring user interaction for a test request triggered by a pre-scheduled work order. This background mode enables automated testing to occur seamlessly without disrupting the user's current activities on the device.

[00130] The work order may comprise a set of automated testing tasks that are scheduled to be performed at specified intervals without manual intervention. This automation capability is a key feature of the system (102), allowing for consistent, regular performance monitoring with minimal human oversight. Work orders may be configured to run the WPT tests at various frequencies, such as hourly, daily, or weekly, depending on the specific monitoring requirements. By utilizing work orders, organizations can establish a systematic approach to web performance monitoring, ensuring that critical web resources are regularly tested under consistent conditions.

[00131] The software module (202) may parse the URL specified in the test request to determine key components needed to access the web resource being tested. The URL parsing performed by the software module (202) may typically identify several key components. The protocol component specifies the communication protocol to be used for accessing the web resource. Common protocols include "http" for unsecured connections and "https" for secured, encrypted connections. The protocol determination is crucial for establishing the correct type of connection to the web server. The host component identifies the domain name or IP address of the server hosting the web resource. For example, in the URL "https://www.example.com/page", the host would be "www.example.com". Accurate identification of the host is essential for directing the test request to the correct server.

[00132] While often omitted in URLs (defaulting to standard ports like 80 for HTTP or 443 for HTTPS), some web resources may specify a non-standard port number. If present, the port number is crucial for connecting to the correct service on the web server. The path component specifies the location of the particular resource on the web server. In "https://www.example.com/products/iteml23", the path would be "/products/iteml23". Correct path identification ensures that the test targets the specific intended page or resource.

[00133] For instance, consider the test request for the URL "https://api.example.com:8443/data/user?id=12345". The software module (202) may parse this into its constituent parts: the protocol as https, the host as api.example.com, the port as 8443, the path as /data/user, and the query parameter as id= 12345. This parsed information allows the software module (202)to correctly configure the browser or HTTP client used in the test, ensuring that the HTTP client connects to the right server, on the right port, using the correct protocol, and requests the specific resource path with the appropriate parameters.

[00134] Upon completion of the web performance test, the software module (202) may generate test result data containing measurements and metrics collected during the test execution. This test result data serves as a comprehensive record of the web resource's performance under the specific conditions of the test. The generated test result data may include values for the various parameters that were specified in the original test request.

[00135] The input module is configured to receive the test result data from the web performance testing software module.

[00136] The synchronization module (416) is configured to transmit the received test result data to the load balancer (204). The synchronization module (416) plays a critical role in ensuring that the valuable performance data collected during the test is securely and efficiently transferred from the user's device to the central system for analysis and storage. To help distribute network load and prevent simultaneous data transmissions from multiple user equipments (108), the synchronization module (416) may implement a randomized transmission delay. This feature is designed to optimize the data transmission process and prevent network congestion that could occur if numerous devices attempt to send their test results simultaneously. The randomized delay mechanism introduces a controlled level of unpredictability into the timing of data transmissions, which can significantly improve the overall efficiency and reliability of the data collection process.

[00137] The synchronization module (416) may generate the random time interval within a predetermined range. This range could be configured based on various factors such as the expected volume of test results, the capacity of the receiving infrastructure, and the desired balance between timely data transmission and network load distribution. For example, the system might be configured to generate random delays between 0 and 300 seconds (5 minutes). Using a predetermined range ensures that while transmissions are randomized, they still occur within an acceptable timeframe for data freshness and system responsiveness.

[00138] After generating the random time interval, the synchronization module (416) may be configured to transmit the generated random time interval to the test execution module. The test execution module is configured to include the generated random time interval in the work order such that the software module (202) delays the transmission of the test result data by the generated random interval. During this delay period, the test result data is stored in a queue or temporarily on the user equipment (108). This holding period allows other processes on the device to continue uninterrupted and provides an opportunity for any ongoing network activities to complete before initiating the data transmission.

[00139] Once the delay period has elapsed, the software module (202) transmits the data. This transmission occurs at a time that is offset from the test completion by the randomly generated interval. By staggering the transmissions from different user equipments in this manner, the system can achieve a more even distribution of network traffic over time.

[00140] The randomization helps smooth out traffic to the load balancer (204) by reducing the likelihood of traffic spikes caused by simultaneous transmissions. In a scenario without this randomization, if multiple tests were scheduled to be completed at the same time (for example, on the hour), all devices might attempt to transmit their results simultaneously, potentially overwhelming the receiving infrastructure or causing network congestion. The randomized delay mitigates this risk by spreading out these transmissions over a broader time window.

[00141] The load balancer (204) may receive the encrypted test result data transmitted by the synchronization module (416). The load balancer (204) is the entry point for incoming test result data from numerous user equipments. Its primary function is efficiently managing and distributing this incoming traffic across the system's backend infrastructure. Upon receiving the encrypted test result data, the load balancer (204) may then distribute the transmitted test result data to at least one server selected from the plurality of servers (206).

[00142] The selection of servers for data distribution may be based on various factors. These could include the current load on each server, the geographic location of the data source and available servers, the type or size of the incoming data, and any specific routing rules or policies configured in the system. By intelligently distributing incoming data across multiple servers, the load balancer (204) ensures that no single server becomes a bottleneck in the data processing pipeline.

[00143] The servers (206) that receive the distributed test result data from the load balancer (204) are responsible for streaming that data into the distributed event streaming platform (208). The distributed event streaming platform allows the realtime processing of large streams of data across multiple computers. The distributed event streaming platform provides a way to ingest data from many sources, store the data durably, and make it available for processing by multiple consumers. The distributed event streaming platform (208) is used to ingest the stream of test result data coming from the load balancer (204) via the servers (206). The platform buffers this data and makes it available for the processing module (418) to retrieve and process.

[00144] The processing module (418) is configured to retrieve the test result data that has been streamed into the distributed event streaming platform (208) by the servers (206). Once the processing module (418) has retrieved this data, it performs various processing operations on it to prepare it for analysis and storage. One of the first steps in processing the retrieved data is decryption. If the software module (202) had previously encrypted the test result data before transmitting it to the load balancer (204), the processing module (418) is required to decrypt it. The processing module (418) would use the appropriate decryption algorithm and key to convert the encrypted data into its original form. [00145] In an aspect, the system (102) utilizes a hybrid encryption approach, combining the strengths of symmetric and asymmetric encryption algorithms to provide both security and efficiency. For the symmetric encryption component, the system (102) employs the Advanced Encryption Standard (AES) with a 256-bit key length (AES-256). AES-256 is chosen for its robust security and relatively fast encryption and decryption speeds, making it suitable for encrypting large volumes of test result data. The symmetric key is generated uniquely for each transmission session using a cryptographically secure random number generator.

[00146] The asymmetric encryption component utilizes the RSA (Rivest- Shamir-Adleman) algorithm with a 2048-bit key length. The RSA algorithm is used to transmit the AES symmetric key to the receiving end securely. The public key of the receiving server is used to encrypt the AES key, ensuring that only the intended recipient with the corresponding private key can decrypt and access the symmetric key.

[00147] The processing module (418) is responsible for retrieving the test result data from the distributed event streaming platform (208), decrypting it if necessary, parsing and transforming it into a standardized format, and storing the processed data in databases. This processing is a crucial step in the web performance testing workflow, preparing the data for effective analysis and longterm storage.

[00148] After processing the data, the processing module (418) typically stores the processed data in one or more databases (212a, 212b). These databases serve as the central repository for the test result data, allowing it to be queried and analyzed further.

[00149] As part of the processing, the processing module (418) may be configured to process the retrieved test result data by mapping the retrieved test result data with location data before storage. This location data may include information such as latitude, longitude, Cell ID, Mobile Country Code (MCC), or Mobile Network Code (MNC). Mapping location data allows the system (102) to associate web performance metrics with specific geographic areas or cellular network cells where the tests were conducted.

[00150] The processing module (418) retrieves location data associated with each web performance test through several methods. For tests conducted on mobile devices with GPS capabilities, the software module (202) captures latitude and longitude data directly from the device's GPS sensor. In cases where devices lack GPS or when GPS data is unavailable, the software module (202) may use networkbased location services to estimate the device's position based on nearby cell towers or Wi-Fi access points. For tests conducted on non-mobile devices or when other location data is unavailable, the software module (202) may use the device's IP address to estimate its geographic location. Additionally, for tests conducted on mobile devices, the software module (202) captures the Cell ID, Mobile Country Code (MCC), and Mobile Network Code (MNC) directly from the device's cellular modem.

[00151] The mapping process is performed by the processing module (418) in several steps. First, the processing module (418) receives the test result data along with the associated location data from the software module (202). It then cross- references the location data with a database of geographic and network information to verify and enhance the location data if possible. Next, the processing module (418) creates a data structure that links each set of test results with its corresponding location data. Finally, this combined data structure is stored in the database, allowing for geographic analysis of web performance test results.

[00152] This mapping process enables organizations to analyze web performance trends across different geographic locations and cellular networks, providing valuable insights into regional performance variations and networkspecific issues.

[00153] The ability of the processing module (418) to map test result data with location information is a powerful feature of the web performance testing system (102). By associating geographic coordinates, Cell IDs, and mobile network codes with the performance metrics, the system provides a comprehensive, location-aware view of web performance.

[00154] The first step in the analysis process is to examine the key performance metrics captured in the test result data. These metrics provide a quantitative measure of different aspects of web performance. Some of the primary metrics analyzed by the processing module (418) include: i. Page Load Time: The total time it takes for a web page to load completely, from the initial request to the final rendering of all content. This is a high-level indicator of overall performance. ii. Time to First Byte (TTFB): The time between sending the initial request and receiving the first byte of the response from the server. TTFB is a measure of server responsiveness and can help identify issues with server-side processing or network latency. iii. Time to Interactive (TTI): The point at which a web page becomes fully interactive and responsive to user input. TTI is important for user experience, as it indicates when a user can actually start interacting with the page. iv. Network Latency: The time it takes for data to travel between the user equipment (108) and the web server. High network latency can significantly impact overall performance. v. Server Response Time: The time the web server takes to process a request and generate a response. Slow server response times can be caused by inefficient server-side code, database queries, or resource constraints. vi. Resource Loading Time: The time it takes to load individual page resources, such as images, scripts, and stylesheets. Slow resource loading can be due to large file sizes, inefficient caching, or suboptimal resource placement. vii. Client-Side Rendering Time: The time it takes for the user's browser to render and display the web page content. Slow client-side rendering can be caused by complex DOM structures, inefficient JavaScript code, or styling issues. viii. Bandwidth Utilization: The amount of network bandwidth consumed during the web performance test. High bandwidth utilization can indicate opportunities for optimization, such as compressing resources or lazy-loading non-critical content.

[00155] The processing module (418) analyses these metrics and looks for values that deviate from established baselines or industry benchmarks. For example, if the page load time consistently exceeds 3 seconds (a common threshold for acceptable performance), the processing module (418) would flag this as a potential bottleneck.

[00156] However, identifying a slow page load time is just the first step. To provide actionable insights, the processing module (418) may need to dig deeper and correlate the identified bottleneck with the other performance metrics. This correlation analysis helps pinpoint the root causes of the performance issue.

[00157] For instance, if the processing module (418) identifies a high page load time and also observes a correspondingly high TTFB value, it may indicate that the bottleneck is related to server-side processing or network latency. On the other hand, if the page load time is high but the TTFB is relatively low, the issue might be on the client-side, such as slow resource loading or inefficient rendering.

[00158] Based on these correlations and the specific performance patterns identified, the processing module (418) can generate targeted optimization recommendations. These recommendations are actionable suggestions for improving web performance. Some examples of optimization recommendations could include:

■ Implement caching mechanisms on the server-side to reduce response times

■ Optimize database queries to minimize server processing delays

■ Compress and minify static resources (CSS, JavaScript) to reduce file sizes and improve loading times ■ Minimize the use of render-blocking JavaScript and CSS to allow progressive rendering of the page

■ Leverage browser caching by setting appropriate cache headers on the server

[00159] The processing module (418) employs a combination of rule-based heuristics and data-driven models to identify performance bottlenecks and suggest targeted improvements. Initially, the processing module (418) applies a set of predefined rules based on industry best practices and established performance thresholds. For example, if the page load time exceeds 3 seconds, the system flags this as a potential issue.

[00160] To generate more recommendations, the system may utilize machine learning models trained on historical performance data. These models, which include decision trees and random forests, may identify complex patterns and relationships between different performance metrics.

[00161] The system may also employ anomaly detection algorithms to identify unusual patterns or outliers in the performance data. These anomalies often point to specific issues that require attention, such as a sudden increase in database query times or unexpected spikes in network latency.

[00162] To make the insights more accessible and actionable for stakeholders, the processing module (418) generates a comprehensive report summarizing the test results, highlighting the identified performance bottlenecks, and presenting the optimization recommendations. This report serves as a valuable artifact for developers, site owners, and operations teams, helping them understand the current state of web performance and prioritize improvements.

[00163] The report typically includes visualizations, such as charts and graphs, to make the data more easily digestible. For example, a waterfall chart can show the timeline of resource loading, making it easy to spot slow-loading resources. A pie chart can break down the contribution of different factors (e.g., server time, network time, rendering time) to the overall page load time.

[00164] The system may be configured to evaluate the network performance, and database performance based on the analysis of the test result data. The system analyzes test result data to assess the network performance by considering factors e.g. bandwidth, packet loss, and network latency. Additionally, the system evaluates database performance, focusing on metrics such as query response time and database throughput. By analyzing these parameters, the system provides a comprehensive view of both network and database performance, helping to identify performance bottlenecks and optimize web application efficiency. In an example, consider a scenario where a mobile user in New York, using a 4G network, runs a web performance test to access an e-commerce website. The test result data collected includes key performance metrics such as page load time, server response time, and network latency. Additionally, geographic coordinates (latitude and longitude) and network information (Cell ID and mobile network code) are mapped to the data. The system analyzes these metrics, providing a quantitative measure of performance, such as a page load time of 3 seconds, a server response time of 1 second, and network latency of 100 milliseconds. By mapping this data with the user’s location, the system generates insights like "Users in the 10001 zip code experience a 10% slower load time compared to other regions." This location- aware view helps identify performance issues tied to specific geographic areas or network configurations.

[00165] To manage the flow of processed test result data between the processing module (418) and the databases (212a, 212b), the system (102) includes the gateway server (210). The gateway server acts as an intermediary, receiving the processed data from the processing module and determining the appropriate storage location for each piece of data. Upon receiving the data from the processing module (418), the gateway server (210) determines the appropriate storage locations within the one or more databases (212a, 212b) based on the characteristics of the processed test result data. The gateway server (210) defines and applies a set of predefined criteria for data routing and retention, ensuring that data is stored efficiently and can be easily accessed when needed. The set of predefined criteria may be based on various factors, such as the type of test, the location of the test, the date and time of the test, or any other relevant metadata. For example, the gateway server might route all performance test results for a particular web application to a specific database, while test results for another application might be routed to a different database. The gateway server (210) also implements data retention policies, which may include archiving or deleting older data based on predefined rules. This approach optimizes storage utilization while maintaining data integrity and accessibility.

[00166] For example, the user might request a report on the average page load times for a particular web application over the past month. The gateway server would translate this request into the appropriate database queries, retrieve the necessary data from the relevant databases, and then aggregate and format the results to be returned to the user. The gateway server can help ensure fast and efficient data retrieval by optimizing these query paths, even as the volume of stored data grows over time.

[00167] The combination of the distributed event streaming platform (208), the processing module (418), and the flexible database (212a, 212b), all managed by the gateway server (210), creates a powerful and scalable architecture for the web performance testing system (102). This architecture allows the system to handle high volumes of test result data, process and enrich that data in real-time, and store the processed data in a manner that is optimized for analysis and reporting.

[00168] The other modules (420) may include additional components that support and enhance the web performance testing process. These may include an encryption module for securing test result data during transmission, a decryption module for processing encrypted data at the server side, a random interval generator for optimizing data transmission timing, a mapping module for associating test results with location data, and an analysis module for identifying performance bottlenecks and generating optimization recommendations. These other modules (420) work in conjunction with the main processing modules to ensure comprehensive, secure, and efficient web performance testing across various network conditions and user equipment types.

[00169] In an embodiment, the processing component(s) (408) may be implemented as a combination of hardware and programming to implement one or more functionalities of the processing component(s) (408). For example, the programming for the processing component(s) (408) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing component(s) (408) may comprise a processing resource (for example, one or more processors), to execute such instructions.

[00170] Although FIG. 4 shows exemplary components of the system (102), in other embodiments, the system (102) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 4.

[00171] FIG. 5 illustrates an exemplary flow diagram of a method (500) for web performance testing, in accordance with embodiments of the present disclosure.

[00172] At step (502), the method (500) includes receiving, by an input module (412), the test result data from the web performance testing software module (202) installed on the user equipment (108). The test result data comprises a set of parameters related to at least one of: page load time, time to first byte, time to interactive, or network latency. These parameters define the specific performance metrics to be measured during the test. In an example, the method (500) includes initiating, by the web performance testing software module (202), the web performance test on the user equipment (108) to generate the test result data upon completion of the web performance test. The initiating step involves opening the web interface (for example browser) by the web performance testing software module on the user equipment (108). The browser is opened in the foreground for a user-initiated web performance test request, allowing the user to observe the test execution in real-time. On the other hand, the browser is opened in the background when the web performance test request is triggered by a pre-scheduled work order. A work order is a set of automated testing tasks that are performed at specified intervals without requiring user intervention. This enables the system to run tests automatically based on predefined schedules.

[00173] Before transmission, the web performance testing software module (202) encrypts the test result data to ensure its security during transit. The transmission process also involves generating a random time interval within a predetermined range and delaying the transmission of the test result data by the generated random time interval.

[00174] At step (504), the method (500) includes transmitting, by a synchronization module (416), the generated test result data to a load balancer (204). The test result data is then transmitted after the delay. This randomized delay helps distribute the network load and prevents simultaneous data transmissions from multiple user equipments, which could potentially overload the system.

[00175] At step (506), the method (500) includes distributing, by the load balancer (204), the transmitted test result data to at least one server of a plurality of servers (206). The load balancer (204) acts as a central point that receives the incoming test result data and distributes it across the available servers to ensure optimal resource utilization and high availability.

[00176] At step (508), the method (500) includes streaming, by the at least one server of a plurality of servers (206), the distributed test result data into a distributed event streaming platform (208). The distributed event streaming platform (208) is a system that allows for real-time processing, storage, and analysis of large volumes of data. The distributed event streaming platform (208) provides scalable and fault-tolerant data ingestion and processing capabilities. [00177] At step (510), the method (500) includes retrieving, by the processing module (418), the streamed test result data from the distributed event streaming platform (208). The processing module (418) fetches the test result data from the event streaming platform for further processing and analysis.

[00178] At step (512), the method (500) includes processing, by the processing module (418), the retrieved test result data. The processing step involves decrypting the test result data that was previously encrypted by the web performance testing software module (202). Additionally, the processing module (418) may perform various data manipulation and transformation tasks to prepare the data for analysis. This may include parsing the data, extracting relevant metrics, and converting the data into a structured format.

[00179] As part of the processing step, the processing module (418) also maps the processed test result data with location data before storage. The location data can include information such as latitude, longitude, Cell ID, Mobile Country Code (MCC), or Mobile Network Code (MNC). This mapping allows the system to associate the test results with specific geographic locations or mobile network cells, providing valuable context for performance analysis.

[00180] At step (514), the method (500) includes storing, by the processing module (418), the processed test result data in one or more databases (212a, 212b). The databases are managed by a database management system.

[00181] To facilitate efficient data management and retrieval, a gateway server (210) is employed. The gateway server (210) receives the processed test result data from the processing module (418) and manages the data flow between the processing module (418) and the databases (212a, 212b). It determines the appropriate storage locations within the databases based on the characteristics of the processed test result data. The gateway server (210) also defines a set of criteria for data routing and retention, ensuring that the data is stored in the most suitable database and retained for the necessary duration. It applies data retention policies to the stored test result data based on the defined criteria, optimizing storage utilization and data accessibility. Furthermore, the gateway server (210) facilitates the retrieval of stored test result data for reporting and further analysis, providing efficient querying and data access mechanisms.

[00182] In addition to the storage and retrieval of test result data, the processing module (418) performs advanced analysis of the processed data. It analyzes the test result data to identify performance bottlenecks in the web performance test. The identified bottlenecks are correlated with various performance metrics such as page load time, time to first byte, time to interactive, network latency, server response time, resource loading time, client-side rendering time, and bandwidth utilization. By examining these metrics and their relationships, the processing module (418) can pinpoint the specific factors contributing to performance issues.

[00183] Based on the analysis and correlation of performance data, the processing module (418) generates performance optimization recommendations. These recommendations provide actionable insights and suggestions for improving the web application's performance. The processing module (418) also generates a comprehensive report summarizing the test results, identified bottlenecks, and optimization recommendations.

[00184] In another exemplary embodiment, a user equipment (108) communicatively coupled to a system (102) for web performance testing via the network (104) is described. The user equipment is configured to initiate, by a web performance testing software module, a web performance test to generate test result data upon completion of the web performance test. The user equipment is configured to transmit the test result data from the web performance testing software module to the system. The system is configured to transmit, by a synchronization module, the generated test result data to a load balancer. The system is configured to distribute, by the load balancer, the transmitted test result data to at least one server of a plurality of servers. The system is configured to stream, by the at least one server of the plurality of servers, the distributed test result data into a distributed event streaming platform. The system is configured to retrieve, by a processing module, the streamed test result data from the distributed event streaming platform. The system is configured to process, by the processing module, the retrieved test result data to generate a processed test result data. The system is configured to store, by the processing module, the processed test result data in one or more databases.

[00185] The present disclosure provides technical advancements in the field of web performance testing and optimization. It addresses the limitations of existing solutions by introducing a scalable and distributed architecture that can handle large volumes of test data in real-time. The disclosed method involves innovative techniques such as randomized data transmission delays, distributed event streaming, and advanced data processing and analysis. These techniques significantly improve performance, efficiency, and scalability compared to traditional web performance testing approaches.

[00186] FIG. 6 illustrates an exemplary computer system (600) in which or with which the embodiments of the present disclosure may be implemented.

[00187] As shown in FIG. 6, the computer system (600) may include an external storage device (610), a bus (620), a main memory (630), a read-only memory (640), a mass storage device (650), a communication port(s) (660), and a processor (670). A person skilled in the art will appreciate that the computer system (600) may include more than one processor and communication ports. The processor (670) may include various modules associated with embodiments of the present disclosure. The communication port(s) (660) may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fibre, a serial port, a parallel port, or other existing or future ports. The communication ports(s) (660) may be chosen depending on a network, such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (600) connects. [00188] In an embodiment, the main memory (630) may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory (640) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chip for storing static information e.g., start-up or basic input/output system (BIOS) instructions for the processor (670). The mass storage device (650) may be any current or future mass storage solution, which can be used to store information and/or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces).

[00189] In an embodiment, the bus (620) may communicatively couple the processor(s) (670) with the other memory, storage, and communication blocks. The bus (620) may be, e.g. a Peripheral Component Interconnect PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (670) to the computer system (600).

[00190] In another embodiment, operator and administrative interfaces, e.g., a display, keyboard, and cursor control device may also be coupled to the bus (620) to support direct operator interaction with the computer system (600). Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) (660). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system (600) limit the scope of the present disclosure.

[00191] In another exemplary embodiment, the computer system (600) includes a non-transitory computer-readable medium storing instructions that, when executed by one or more processors of a system for web performance testing. The instructions cause the one or more processors to perform one or more operations including receiving, by an input module, a test result data from a web performance testing software module installed on a user equipment. The one or more operations further include transmitting, by a synchronization module, the generated test result data to a load balancer. The one or more operations further include distributing, by the load balancer, the transmitted test result data to at least one server of a plurality of servers. The one or more operations further include streaming, by the at least one server of the plurality of servers, the distributed test result data into a distributed event streaming platform. The one or more operations further include retrieving, by a processing module, the streamed test result data from the distributed event streaming platform. The one or more operations further include processing, by the processing module, the retrieved test result data to generate a processed test result data. The one or more operations further include storing, by the processing module, the processed test result data in one or more databases.

[00192] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.

[00193] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter to be implemented merely as illustrative of the disclosure and not as limitation.

TECHNICAL ADVANTAGES OF THE PRESENT DISCLOSURE

[00194] The present disclosure provides a scalable and distributed architecture for web performance testing that can handle large volumes of test data in real-time. This architecture ensures efficient data processing and analysis, enabling organizations to gain valuable insights into their web application's performance.

[00195] The present disclosure introduces techniques such as randomized data transmission delays, distributed event streaming, and advanced data processing and analysis. These techniques enhance performance, efficiency, and scalability compared to traditional web performance testing approaches. The randomized transmission delays help distribute network load and prevent system overload, ensuring reliable and consistent testing results.

[00196] The present disclosure leverages a distributed event streaming platform for seamless ingestion and processing of test result data from multiple user equipments. This enables real-time analysis and identification of performance bottlenecks, empowering developers and system administrators to take proactive measures to optimize web application performance.

[00197] The present disclosure generates actionable optimization recommendations and comprehensive performance reports. These reports assist in identifying and resolving performance bottlenecks, leading to improved user experience and increased efficiency of web applications. The detailed insights and suggestions provided by the reports empower development teams to make data- driven decisions and prioritize optimization efforts effectively. [00198] The present disclosure offers a user-friendly and intuitive interface for initiating web performance tests and accessing test results. The user equipment communicates seamlessly with the web performance testing system, allowing users to easily configure test parameters, trigger tests, and view performance reports. This streamlined user experience encourages widespread adoption of the testing solution and empowers users to actively participate in the performance optimization process.

[00199] The present disclosure incorporates advanced security measures to protect the confidentiality and integrity of the test result data. The use of encryption techniques ensures that sensitive data remains secure during transmission and storage. Additionally, the disclosed method implements access control mechanisms and data retention policies to prevent unauthorized access and ensure compliance with data privacy regulations.

Claims

1. A system (102) for web performance testing, comprising: a memory (404); one or more processors (402) coupled to the memory (404) and configured to execute a set of instructions stored therein to: receive, by an input module (412), a test result data from a web performance testing software module (202) installed on a user equipment (108); transmit, by a synchronization module (416), the generated test result data to a load balancer (204); distribute, by the load balancer (204), the transmitted test result data to at least one server of a plurality of servers (206); stream, by the at least one server of the plurality of servers (206), the distributed test result data into a distributed event streaming platform (208); retrieve, by a processing module (418), the streamed test result data from the distributed event streaming platform (208); process, by the processing module (418), the retrieved test result data to generate a processed test result data; and store, by the processing module (418), the processed test result data in one or more databases (212a, 212b).

2. The system (102) of claim 1, wherein the test result data comprises a set of parameters related to at least one of a page load time, a time to first byte, a time to interactive, or a network latency.

3. The system (102) of claim 1, wherein a test execution module is configured to transmit a web performance work order comprising one or more attributes to the web performance testing software module (202).

4. The system (102) of claim 3, wherein the web performance testing software module (202) is configured to extract the one or more attributes from the web performance work order and initiate the web performance test based on the extracted one or more attributes to generate the test result data upon completion of the web performance test, wherein the one or more attributes include a specific time and a random time interval.

5. The system (102) of claim 1, wherein the web performance testing software module (202) is configured to generate a sync request to sync the test result data with the data stored in the one or more databases (212a, 212b).

6. The system (102) of claim 1, wherein the web performance testing software module (202) is further configured to initiate the web performance test by opening a web interface by the web performance testing software module (202) on the user equipment (108).

7. The system (102) of claim 1, wherein the web performance testing software module (202) is further configured to execute the web performance test by parsing one or more Uniform Resource Locators (URLs) to retrieve at least one of a protocol, a host, a port, or a path.

8. The system (102) of claim 1, wherein the web performance testing software module (202) is further configured to encrypt the generated test result data before transmission to the synchronization module (416).

9. The system (102) of claim 1, wherein the processing module (418) is configured to process the retrieved test result data by decrypting the retrieved test result data.

10. The system (102) of claim 1, wherein the processing module (418) is configured to process the retrieved test result data by mapping the retrieved test result data with location data before storage, wherein the location data comprises at least one of: latitude, longitude, Cell ID, Mobile Country Code (MCC), or Mobile Network Code (MNC).

11. The system (102) of claim 1, further comprising a gateway server (210) configured to receive the processed test result data from the processing module (418) and manage data flow between the processing module (418) and the one or more databases (212a, 212b) based on a set of predefined criteria.

12. The system (102) of claim 4, wherein the web performance testing software module (202) is configured to transmit the generated test result data by performing steps comprising of: delaying the transmission of the test result data by the extracted random time interval; and transmitting the test result data after the delay.

13. A method (500) for web performance testing, comprising: receiving (502), by an input module (412), a test result data from a web performance testing software module (202) installed on a user equipment (108); transmitting (504), by a synchronization module (416), the generated test result data to a load balancer (204); distributing (506), by the load balancer (204), the transmitted test result data to at least one server of a plurality of servers (206); streaming (508), by the at least one server of the plurality of servers (206), the distributed test result data into a distributed event streaming platform (208); retrieving (510), by a processing module (418), the streamed test result data from the distributed event streaming platform (208); processing (512), by the processing module (418), the retrieved test result data to generate the processed data; and storing (514), by the processing module (418), the processed test result data in one or more databases (212a, 212b).

14. The method (500) of claim 13, wherein the test result data comprises a set of parameters related to at least one of a page load time, a time to first byte, a time to interactive, or a network latency.

15. The method (500) of claim 13, further comprising transmitting, by a test execution module, a web performance work order comprising one or more attributes to the web performance testing software module (202).

16. The method (500) of claim 13, further comprising, extracting, by the web performance testing software module (202), the one or more attributes from the web performance work order and initiating the web performance test based on the extracted one or more attributes to generate the test result data upon completion of the web performance test, wherein the one or more attributes include a specific time and a random time interval.

17. The method (500) of claim 13, further comprising, generating, by the web performance testing software module (202), a sync request to sync the test result data with the data stored in the one or more databases (212a, 212b).

18. The method (500) of claim 16, wherein the initiating the web performance test comprises: opening a web interface by the web performance testing software module (202) on the user equipment (108).

19. The method (500) of claim 13, wherein executing the web performance test further comprises: parsing, by the web performance testing software module (202), one or more Uniform Resource Locators (URLs) to retrieve at least one of a protocol, a host, a port, or a path.

20. The method (500) of claim 13, further comprising encrypting, by the web performance testing software module (202), the generated test result data before transmission to the synchronization module (416).

21. The method (500) of claim 13, wherein the processing (512) the retrieved test result data comprises decrypting the retrieved test result data.

22. The method (500) of claim 16, wherein transmitting the generated test result data further comprises: delaying the transmission of the test result data by the extracted random time interval; and transmitting the test result data after the delay.

23. The method (500) of claim 13, wherein the processing (512) the retrieved test result data further comprising mapping, by the processing module (418), the retrieved test result data with location data before storage, wherein the location data comprises at least one of: latitude, longitude, Cell ID, Mobile Country Code (MCC), or Mobile Network Code (MNC).

24. The method (500) of claim 13, further comprising: receiving, by a gateway server (210), the processed test result data from the processing module (418) and managing data flow between the processing module (418) and the one or more databases (212a, 212b) based on a set of predefined criteria.

25. A user equipment (108) communicatively coupled with a system (102) for web performance testing via a network, the coupling comprises steps of: receiving, from the system (102), a connection request; sending an acknowledgment of the connection request to the system (102); and transmitting a plurality of signals in response to the connection request, wherein the user equipment (108) is configured to: initiate, by a web performance testing software module (202), a web performance test to generate test result data upon completion of the web performance test; and transmit the test result data from the web performance testing software module (202) to the system (102); and wherein the system (102) is configured to: transmit, by a synchronization module (416), the generated test result data to a load balancer (204); distribute, by the load balancer (204), the transmitted test result data to at least one server of a plurality of servers (206); stream, by the at least one server of the plurality of servers (206), the distributed test result data into a distributed event streaming platform (208); retrieve, by a processing module (418), the streamed test result data from the distributed event streaming platform (208); process, by the processing module (418), the retrieved test result data to generate a processed test result data; and store, by the processing module (418), the processed test result data in one or more databases (212a, 212b).

26. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors (402) of a system (102) for web performance testing, cause the one or more processors (402) to perform one or more operations comprising: receiving, by an input module (412), a test result data from a web performance testing software module (202) installed on a user equipment (108); transmitting, by a synchronization module (416), the generated test result data to a load balancer (204); distributing, by the load balancer (204), the transmitted test result data to at least one server of a plurality of servers (206); streaming, by the at least one server of the plurality of servers (206), the distributed test result data into a distributed event streaming platform (208); retrieving, by a processing module (418), the streamed test result data from the distributed event streaming platform (208); processing, by the processing module (418), the retrieved test result data to generate a processed test result data; and storing, by the processing module (418), the processed test result data in one or more databases (212a, 212b).