Front-end complex calculation acceleration method and system based on webassembly and edge cache

Abstract

The application discloses a front-end complex calculation acceleration method and system based on WebAssembly and edge cache, and belongs to the field of web audio and video playing. The method comprises the following steps: a user end detects a browser environment, outputs a unique browser environment identifier, and collects task core information; input parameters are standardized, and associated calculation is performed in combination with a task type and a BEID to generate a unique CTID, and a resource request is sent to an edge node; the edge node first searches a calculation result cache library with the CTID as an index, and if the calculation result is hit, the calculation result is sent to the user end; if the calculation result is not hit, a WASM module cache library is searched with the BEID and the task type as joint indexes, a WASM module file is output, and is sent to the user end; the user end receives the sent resource, and if the resource is the calculation result, the resource is directly used; if the resource is the WASM module file, a WebWorker thread is started, and a final result is obtained; and the user end reports the final result in batches, and the edge node stores the final result into the calculation result cache library with a calculation task identifier as an index.

Description

Technical Field

[0001] This invention belongs to the field of web audio and video playback, specifically involving a method and system for accelerating complex front-end computing based on WebAssembly and edge caching. Background Technology

[0002] In today's rapidly evolving digital technology landscape, the functional boundaries of front-end applications continue to expand, with computationally intensive tasks such as 3D rendering, audio and video encoding / decoding, and complex data visualization becoming core requirements. However, JavaScript, the core front-end development language, has inherent limitations in single-threaded execution and interpreted operation. When handling such complex calculations, it is highly susceptible to problems such as main thread blocking, sudden drops in page frame rates, and delayed interactive responses, creating serious performance bottlenecks and directly degrading the user experience.

[0003] To address this pain point, two related solutions have emerged in the industry: WebAssembly (WASM) local acceleration technology and edge caching technology. However, both have significant drawbacks: 1) WebAssembly (WASM) local acceleration technology: Although it can significantly improve computing efficiency through compiled execution, it does not solve the problem of redundant resource consumption. When multiple users execute the same computing task, they need to repeatedly download the WASM module and repeatedly execute the computing process, resulting in wasted bandwidth resources and redundant computing power; 2) Edge caching technology: Existing solutions only cache static resources such as HTML, images, and scripts, and cannot effectively reuse calculation results. Users still need to re-execute the entire calculation process every time they make a request, which does not fundamentally reduce the calculation time. 3) Adaptation and timing coordination issues: The WASM module has significant compatibility differences across different browsers (such as Chrome, Firefox, Safari) and different kernel versions. Furthermore, the module loading timing is not coordinated with the front-end application lifecycle, which can easily lead to abnormal situations such as module loading failure and computation interruption errors. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the present invention aims to provide a method and system for accelerating complex front-end computing based on WebAssembly and edge caching, thereby solving the problems in existing technologies.

[0005] The objective of this invention can be achieved through the following technical solutions: A method for accelerating complex front-end computations based on WebAssembly and edge caching includes the following steps: The client detects the browser environment, outputs a unique browser environment identifier, and collects core task information to initialize the task. The input parameters are standardized and combined with the task type and browser environment identifier to perform related calculations, generate a unique calculation task identifier, and send a resource request to the edge node; After receiving a resource request, the edge node first searches the computation result cache library using the computation task identifier as the index. If the computation result is found, the computation result is sent to the user terminal. If the computation result is not found, the WASM module cache library is searched using the browser environment identifier and task type as a combined index, the WASM module file is output, and it is sent to the user terminal. The client receives the resources sent out. If it is a calculation result, it uses it directly. If it is a WASM module file, it starts a WebWorker thread, passes the standardized input parameters to the thread to perform calculations, and obtains the final result. The user end reports the final results in batches, and the edge nodes store the results in the calculation result cache library using the calculation task identifier as an index.

[0006] Furthermore, the steps for detecting the browser environment include: Identify browser type and kernel version; Check the browser's support for WASM; A unique browser environment identifier is generated based on the detection results.

[0007] Furthermore, the core information of the task includes: task type and input parameters.

[0008] Furthermore, the content of the resource request includes: CTID, BEID, and task type.

[0009] Furthermore, when retrieving the WASM module cache library, if the WASM module is not found, the latest module is requested from the origin server and synchronized to the edge cache before being distributed.

[0010] Furthermore, the steps for obtaining the final result include: Module loading is performed using an on-demand loading strategy: preloading is triggered before user interaction, the module loading status is monitored in real time, and a fallback mechanism is triggered if loading fails to avoid timing errors. If the edge node does not return a valid calculation result, start the WebWorker thread, pass the WASM module and the standardized input parameters to the WebWorker thread to perform the calculation. During the calculation, the WebWorker thread pushes progress information to the main thread in real time, and the main thread updates the UI display.

[0011] Furthermore, the batch reporting strategy is as follows: the user terminal caches the calculation results locally, and after accumulating 10 results or after an interval of 5 minutes, reports them to the edge node all at once.

[0012] A front-end complex computing acceleration system based on WebAssembly and edge caching, executing the above method, is characterized by including: Task initialization module: The client detects the browser environment, outputs a unique browser environment identifier, and collects core task information to achieve task initialization; The computation task identifier generation module standardizes the input parameters, combines them with the task type and browser environment identifier to perform related calculations, generates a unique computation task identifier, and sends a resource request to the edge node. Resource distribution module: After receiving a resource request, the edge node first searches the computation result cache library using the computation task identifier as the index. If the computation result is found, the computation result is sent to the user terminal. If the computation result is not found, the WASM module cache library is searched using the browser environment identifier and task type as a combined index, the WASM module file is output, and it is sent to the user terminal. Asynchronous computation module: The client receives the resources sent down. If it is a computation result, it is used directly; if it is a WASM module file, a WebWorker thread is started, and the standardized input parameters are passed to the thread to perform the computation and obtain the final result. Cache update module: The user end reports the final results in batches, and the edge nodes store them in the calculation result cache library with the calculation task identifier as the index.

[0013] An electronic device includes: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; The memory is used to store at least one executable instruction that causes the processor to perform operations corresponding to the aforementioned front-end complex computing acceleration method based on WebAssembly and edge caching.

[0014] A computer program product includes computer instructions that instruct a computing device to perform operations corresponding to the aforementioned front-end complex computing acceleration method based on WebAssembly and edge caching.

[0015] The beneficial effects of this invention are: 1. This invention constructs a two-level collaborative acceleration architecture of "edge node-user terminal". By combining the computing task analysis and cache management capabilities of the edge node with the WASM adaptation scheduling and computing result reuse mechanism of the user terminal, it realizes the efficient reuse of resources and computing results throughout the entire process.

[0016] 2. This invention deploys a dedicated caching system at edge nodes to uniformly store WASM modules and reusable computation results. The user end integrates environment adaptation, task scheduling, and asynchronous computation modules, automatically completing browser environment adaptation, on-demand module loading, and computation task distribution. From a technical principle perspective, the edge caching mechanism avoids multiple users repeatedly downloading the WASM module, thus significantly reducing module download latency; the unified storage and retrieval of reusable computation results greatly reduces the computational power loss caused by repeated computations; and the precise browser environment adaptation logic and module loading timing design effectively improve the adaptation reliability of the WASM module; simultaneously, the asynchronous computation and task distribution mechanism avoids main thread blocking, ensuring stable page frame rates. In summary, this invention can significantly improve the performance and user experience of complex front-end computation scenarios, possessing outstanding technical advantages and application value. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of the front-end complex computing acceleration method of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Example 1: The core architecture of this invention is a two-level collaborative architecture of "edge node-user terminal", in which the two achieve data interaction and command coordination through network communication; Edge nodes: As the core cache and computing scheduling hub, they deploy "computing task analysis and cache management", and are responsible for WASM module storage, computing result caching, task reusability judgment and resource distribution; User-side: Integrates "WASM module adaptation and loading" and "computation task scheduling and result reuse", runs in the user's browser environment, and is responsible for environment detection, module adaptation, task preprocessing and asynchronous computation execution.

[0021] like Figure 1 As shown, a method for accelerating complex front-end computations based on WebAssembly and edge caching includes the following steps: S1, the client detects the browser environment, outputs a unique browser environment identifier (BEID), and collects core task information to achieve task initialization; In S1, after the client loads the front-end application, environment checks are automatically performed via the JavaScript API. The specific process is as follows: 1) Identify browser type (such as Chrome, Safari) and kernel version (such as Blink, WebKit); 2) Check the browser's support for WebAssembl (WASM) (e.g., whether the WASM engine is enabled, and the supported WASM versions). 3) Generate a unique "Browser Environment Identifier (BEID)" based on the detection results for subsequent module adaptation; specifically: Based on the detection results of browser type, kernel version, and WASM support, BEID is generated using a "layered encoding + hash verification" method to ensure uniqueness, traceability, and simplicity. The specific steps are as follows: Step 1: Basic Information Extraction and Standardized Coding Three types of core information are extracted from the test results and standardized in a uniform format to avoid duplicate labels due to differences in information expression: Browser type encoding: Use 2-letter abbreviations, such as "CH" for Chrome, "SA" for Safari, "FF" for Firefox, and "ED" for Edge. Unrecognized browsers are uniformly represented by "UN". Kernel version encoding: First, extract the 3-letter abbreviation of the kernel type (Blink / WebKit / Gecko, etc.) (e.g., Blink corresponds to "BLK", WebKit corresponds to "WEB"), then concatenate the kernel version number (keeping the major version number + minor version number, in the format "XY"). Example: Blink kernel version 98.0 corresponds to "BLK98.0". WASM supports status coding: It adopts a combination format of "feature identifier + version identifier", where the feature identifier is represented by a 1-digit number (0 = WASM not supported, 1 = basic WASM engine supported, 2 = advanced WASM features supported), and the version identifier is the specific version of WASM supported (such as "1.0" "2.0"). For example, supporting the WASM 1.0 basic engine corresponds to "1_1.0", and supporting the WASM 2.0 advanced features corresponds to "2_2.0".

[0022] Step 2: Core Information Assembly The three standardized encodings are concatenated in the order of "browser type encoding - kernel version encoding - WASM support status encoding" to form the original information string. For example: Chrome browser (CH) + Blink98.0 kernel + support for WASM1.0 basic engine (1_1.0) will be concatenated as "CH-BLK98.0-1_1.0".

[0023] Step 3: Hash Compression and Uniqueness Verification The original information string is hashed to generate a fixed-length, concise identifier while ensuring uniqueness. The original information string is encrypted using the MD5 hash algorithm to obtain a 32-bit hash value; Extract the first 16 bits of the hash value as the base BEID (balancing simplicity and uniqueness), and add a check bit (taking the last bit of the 32-bit hash value) to form a 17-bit BEID, which is in the format of "first 16 bits of hash value + check bit".

[0024] Step 4: Conflict Detection and Correction (Optional) If duplicate BEIDs exist in extreme scenarios (verified by the edge node's identifier management module), then "browser rendering engine details version" (e.g., "Blink98.0.4758.102") is added to the original information string, and steps 2-3 are executed again to generate a new BEID, ensuring global uniqueness.

[0025] Meanwhile, when a user triggers a computation task (such as clicking the audio / video decoding button or starting 3D rendering), the front-end application collects core information such as task type (e.g., "MP4 decoding" or "3D model rendering") and input parameters (e.g., video file address and model data) to complete task initialization.

[0026] This step provides an environmental basis for subsequent module adaptation and basic data for task reuse, and is a prerequisite for ensuring the compatibility of WASM modules and the reusability of calculation results.

[0027] S2 standardizes the input parameters and performs correlation calculations with the task type and BEID to generate a unique computation task identifier (CTID), and sends a resource request to the edge node; The steps to generate a unique computation task identifier include: 1) Standardize the input parameters (e.g., unify the data format and verify the integrity of the parameters) to avoid reuse failure due to differences in parameter format; 2) A unique "Computation Task Identifier (CTID)" is generated by combining the task type, standardized input parameters, and BEID. The CTID serves as the core index for caching and reusing computation results. The CTID is generated using a "concatenation + hash digest" method: First, the original information string is formed by concatenating the "task type code - standardized input parameters - BEID" in the order of task type code, using a preset 2-bit fixed code (e.g., "AV" for audio / video encoding / decoding, "3D" for 3D rendering). Then, the original information string is encrypted using the SHA-256 hash algorithm, and the first 20 bits of the hash value are used as the final CTID. Using the SHA-256 algorithm ensures the uniqueness and security of the CTID, while the fixed-length hash digest reduces storage and indexing overhead, ensuring efficient edge node cache lookups.

[0028] 3) Send resource requests to edge nodes. The request content includes CTID (used to query the calculation result cache), BEID and task type (used to query the adapted WASM module).

[0029] This step follows the environmental detection and task initialization results from S1. Through standardized processing and unique identifier generation, it establishes a cache query association between the user end and the edge node, serving as a crucial bridge for realizing the reuse of calculation results and modules.

[0030] S3. After receiving a resource request, the edge node first searches the calculation result cache library using CTID as the index. If the calculation result is found, the calculation result is sent to the user terminal. If the calculation result is not found, the WASM module cache library is searched using BEID and task type as the combined index, the WASM module file is output, and it is sent to the user terminal. When retrieving the WASM module cache library, if the WASM module is not found, the latest module is requested from the origin server and synchronized to the edge cache before being distributed.

[0031] After receiving a request from the client, the edge node performs a cache query in the order of "first check the calculation results → then check the WASM module": 1) Calculation result cache query: Use CTID as the index to query the cache library to determine if the calculation result exists and is within its validity period (5 minutes for real-time tasks, 24 hours for non-real-time tasks): If the cache is hit (the result is valid): the calculation result is returned directly to the user, skipping subsequent calculation steps; If the cache is not hit (result does not exist or has expired): Proceed to the WASM module cache query process; 2) WASM module cache query: Query the cache library using "module ID-browser type" as a composite index (WASM modules are cached for 7 days by default): If the cache is hit: return the adapted WASM module to the user. If the cache misses: Request the corresponding WASM module from the origin server, receive it, synchronously store it in the edge cache, and then distribute it to the user client; If the origin server has WASM module updates (such as fixing compatibility issues or optimizing computation logic), the edge nodes will synchronously update the cached modules to ensure that users get the latest version.

[0032] This step performs precise queries based on the CTID and BEID generated by S2, minimizes computation time through a "result reuse priority" strategy, and reduces download latency through module caching, making it the core link for achieving full-process acceleration. S4: The user receives the resources sent by S3. If it is a calculation result, it is used directly; if it is a WASM module file, a WebWorker thread is started, and the standardized input parameters are passed to the thread to perform calculations and obtain the final result. After the user receives the resources returned by the edge node, it executes the process according to "module loading → asynchronous computation", as follows: 1) Module loading is performed using an on-demand loading strategy: Preload the core modules necessary for initialization, and trigger the preloading before the user may trigger an interaction (such as 500ms after the mouse hovers over the target button); Real-time monitoring of module loading status (loading, loading complete, loading failed). If loading fails, a fallback mechanism is triggered (such as switching to JavaScript fallback calculation) to avoid timing errors. 2) Asynchronous computation: If the edge node does not return a valid calculation result, start a WebWorker thread, pass the WASM module and standardized input parameters to the thread to perform the calculation: Worker threads run independently of the main thread, focusing on processing computational tasks and avoiding blocking the main thread's interactive rendering logic. During computation, worker threads push progress information to the main thread in real time (such as "decoding progress 30%)", and the main thread updates the UI (user interface) display to improve the user experience.

[0033] This step serves as a fallback solution when the S3 cache misses. It ensures module loading stability through on-demand loading and timing control, and protects the main thread through WebWorker thread isolation. It is a key step that balances compatibility and page smoothness.

[0034] S5, the user end will report the final results obtained in S4 in batches, and the edge node will store the calculation result cache library with the CTID determined in S2 as the index to generate cache data for subsequent reuse. After the user completes the calculation, the result is returned to the front-end application for page rendering or function triggering. Simultaneously, the result is reported. The specific process includes: 1) A batch reporting strategy is adopted: the calculation results are cached locally on the user end, and after accumulating 10 results or after an interval of 5 minutes, they are reported to the edge node at once; 2) After receiving the reported results, the edge nodes store them in the calculation result cache library with CTID as the index, update the cache validity period, and make them available for subsequent users to reuse.

[0035] This step follows the calculation results from S4, reduces network request overhead by batch reporting, and supplements edge node cache resources to complete the closed loop of "request-computation-caching-reuse" and continuously improve the acceleration effect for subsequent users.

[0036] Based on a similar inventive concept, embodiments of the present invention also provide a computer storage medium storing a readable program that, when run by a processor, can execute the aforementioned method for accelerating complex front-end computations based on WebAssembly and edge caching.

[0037] Based on a similar inventive concept, this invention provides an electronic device, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; The memory is used to store at least one executable instruction, which causes the processor to perform the operation corresponding to the aforementioned front-end complex computing acceleration method based on WebAssembly and edge caching.

[0038] Based on a similar inventive concept, embodiments of the present invention also provide a computer program product, including computer instructions, which instruct a computing device to perform the operations corresponding to the aforementioned front-end complex computing acceleration method based on WebAssembly and edge caching.

[0039] Example 2: A front-end complex computing acceleration system based on WebAssembly and edge caching, specifically including: Task initialization module: The client detects the browser environment, outputs a unique browser environment identifier, and collects core task information to achieve task initialization; The computation task identifier generation module standardizes the input parameters, combines them with the task type and browser environment identifier to perform related calculations, generates a unique computation task identifier, and sends a resource request to the edge node. Resource distribution module: After receiving a resource request, the edge node first searches the computation result cache library using the computation task identifier as the index. If the computation result is found, the computation result is sent to the user terminal. If the computation result is not found, the WASM module cache library is searched using the browser environment identifier and task type as a combined index, the WASM module file is output, and it is sent to the user terminal. Asynchronous computation module: The client receives the resources sent down. If it is a computation result, it is used directly; if it is a WASM module file, a WebWorker thread is started, and the standardized input parameters are passed to the thread to perform the computation and obtain the final computation result. Cache update module: The user end reports the final results in batches, and the edge nodes store them in the calculation result cache library with the calculation task identifier as the index.

[0040] The methods of the present invention can be implemented in hardware, firmware, or as software or computer code that can be stored in a recording medium (such as a CD-ROM, RAM, floppy disk, hard disk, or magneto-optical disk), or as computer code originally stored on a remote recording medium or a non-transitory machine-readable medium and subsequently stored on a local recording medium, downloaded via a network. Thus, the methods described herein can be processed by software stored on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an ASIC or FPGA). It is understood that the computer, processor, microprocessor controller, or programmable hardware includes storage components (e.g., RAM, ROM, flash memory, etc.) capable of storing or receiving software or computer code that, when accessed and executed by the computer, processor, or hardware, implements the methods described herein. Furthermore, when a general-purpose computer accesses the code used to implement the methods shown herein, the execution of the code transforms the general-purpose computer into a dedicated computer for performing the methods shown herein.

[0041] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention.

Claims

1. A method for accelerating complex front-end computations based on WebAssembly and edge caching, characterized in that, Includes the following steps: The client detects the browser environment, outputs a unique browser environment identifier, and collects core task information to initialize the task. The input parameters are standardized and combined with the task type and browser environment identifier to perform related calculations, generate a unique calculation task identifier, and send a resource request to the edge node; After receiving a resource request, the edge node first searches the computation result cache library using the computation task identifier as the index. If the computation result is found, the computation result is sent to the user terminal. If the computation result is not found, the WASM module cache library is searched using the browser environment identifier and task type as a combined index, the WASM module file is output, and it is sent to the user terminal. The client receives the resources sent out. If it is a calculation result, it uses it directly. If it is a WASM module file, it starts a WebWorker thread, passes the standardized input parameters to the thread to perform calculations, and obtains the final result. The user end reports the final results in batches, and the edge nodes store the results in the calculation result cache library using the calculation task identifier as an index.

2. The method for accelerating complex front-end computations based on WebAssembly and edge caching according to claim 1, characterized in that, The steps to detect the browser environment include: Identify browser type and kernel version; Check the browser's support for WASM; A unique browser environment identifier is generated based on the detection results.

3. The method for accelerating complex front-end computations based on WebAssembly and edge caching according to claim 1, characterized in that, The core information of a task includes: task type and input parameters.

4. The method for accelerating complex front-end computations based on WebAssembly and edge caching according to claim 3, characterized in that, The resource request includes: CTID, BEID, and task type.

5. The method for accelerating complex front-end computations based on WebAssembly and edge caching according to claim 1, characterized in that, When retrieving the WASM module cache library, if the WASM module is not found, the latest module is requested from the origin server and synchronized to the edge cache before being distributed.

6. The method for accelerating complex front-end computations based on WebAssembly and edge caching according to claim 1, characterized in that, The steps to obtain the final result include: Module loading is performed using an on-demand loading strategy: preloading is triggered before user interaction, the module loading status is monitored in real time, and a fallback mechanism is triggered if loading fails to avoid timing errors. If the edge node does not return a valid calculation result, start the WebWorker thread, pass the WASM module and the standardized input parameters to the WebWorker thread to perform the calculation. During the calculation, the WebWorker thread pushes progress information to the main thread in real time, and the main thread updates the UI display.

7. The method for accelerating complex front-end computations based on WebAssembly and edge caching according to claim 1, characterized in that, The batch reporting strategy is as follows: the user caches the calculation results locally, and after accumulating 10 results or after an interval of 5 minutes, reports them to the edge node all at once.

8. A front-end complex computing acceleration system based on WebAssembly and edge caching, comprising the method described in any one of claims 1-7, characterized in that, include: Task initialization module: The client detects the browser environment, outputs a unique browser environment identifier, and collects core task information to achieve task initialization; The computation task identifier generation module standardizes the input parameters, combines them with the task type and browser environment identifier to perform related calculations, generates a unique computation task identifier, and sends a resource request to the edge node. Resource distribution module: After receiving a resource request, the edge node first searches the computation result cache library using the computation task identifier as the index. If the computation result is found, the computation result is sent to the user terminal. If the computation result is not found, the WASM module cache library is searched using the browser environment identifier and task type as a combined index, the WASM module file is output, and it is sent to the user terminal. Asynchronous computation module: The client receives the resources sent down. If it is a computation result, it is used directly; if it is a WASM module file, a WebWorker thread is started, and the standardized input parameters are passed to the thread to perform the computation and obtain the final result. Cache update module: The user end reports the final results in batches, and the edge nodes store them in the calculation result cache library with the calculation task identifier as the index.

9. An electronic device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation corresponding to the front-end complex computing acceleration method based on WebAssembly and edge caching as described in any one of claims 1-7.

10. A computer program product comprising computer instructions, characterized in that, The computer instructions instruct the computing device to perform the operations corresponding to the front-end complex computing acceleration method based on WebAssembly and edge caching as described in any one of claims 1-7.

Images