A Deployment Method and System for Compute-Intensive Applications Based on Openresty

Abstract

The present invention provides a method and system for deploying compute-intensive applications based on Openresty. The system is implemented based on the Openresty system. In the initialization stage, the system creates a global Lua buffer for sharing resources among child processes. The system includes a child process management module for creating child processes, managing idle child processes, recycling abnormal child processes, and protecting against overload; LuaSocket is introduced in the child processes for bidirectional communication between the parent and child processes based on the TCP protocol; an Nginx worker process is configured to be responsible for the entry and exit of the system network and serve as the parent process of the child processes; TCP communication is established between the child processes and the parent process; in the content processing stage, the child processes are responsible for processing user requests, forwarding, and outputting responses. This solution can solve the problem that compute-intensive processes block the Openresty system. Static data is loaded by the global Lua virtual machine to avoid multiple compute processes from loading a large amount of static resource data multiple times; a standard C interface module is provided and can be directly loaded without additional encapsulation and development.

Description

Technical Field

[0001] The present invention relates to the field of computer system deployment and calling, and in particular to a method and system for deploying computing-intensive applications based on Openresty. Background Art

[0002] Nginx, like Apache and Tomcat, is an open-source server. It is a high-performance HTTP and reverse proxy server with high concurrency, good performance, and low memory usage.

[0003] OpenResty is a high-performance web platform based on Nginx and Lua. It integrates a large number of sophisticated Lua libraries and third-party modules, effectively transforming Nginx into a powerful general-purpose web application platform. This allows web developers and system engineers to use the Lua scripting language to leverage the various C and Lua modules supported by Nginx, quickly building high-performance web applications.

[0004] There are currently two main types of OpenResty-based web application systems: IO-intensive and CPU-intensive.

[0005] (1) IO-intensive tasks: tasks involving network and disk IO are IO-intensive tasks. The characteristics of such tasks are that the CPU consumption is very low, and most of the task time is spent waiting for IO operations to complete;

[0006] (2) Computationally intensive tasks are characterized by the need to perform a large amount of calculations and consume CPU resources, such as calculating pi and decoding high-definition videos.

[0007] Openresty is an event-driven, non-blocking system suitable for I / O-intensive services but not for CPU-intensive ones. Therefore, compute-intensive applications should be avoided within the Openresty framework. If we want to reuse Openresty's excellent framework while also running compute-intensive applications, the existing Openresty framework is no longer sufficient and we need to find alternatives.

[0008] In the prior art, there are mainly two ways to implement the deployment based on the Openresty service application framework: (1) Using Openresty / Nginx + gunicorn / uwsgi to deploy the Python http service application framework is a common way. Due to the language limitations of Python, the access to shared memory is not friendly. Therefore, generally, databases such as Redis are used to share static resource data. However, this method requires additional development of services, increasing the development, debugging, and operation costs. If the Redis service crashes, it will cause errors in the entire system, and the stability is not high. Since Reids data has a specific data access and storage format, it must be converted according to the Redis protocol before and after data transmission, increasing the overhead. (2) Using languages such as C++ / Java / C# to implement http services and tcp services that support data sharing. Static resource data can be loaded in shared memory to achieve sharing, and Openresty / Nginx is mainly used for traffic proxy. This method requires additional development of services, increasing the development, debugging, and operation costs. Moreover, in order to support shared memory to share data, http / tcp services need to be developed using high-level languages such as C++ / Java / C#. The development difficulty is higher than that of Python and Lua languages. Algorithm modules are generally developed using C / C++. If C# / Java is used to develop services, the algorithm modules must be repackaged into C# / Java modules, which requires additional costs. Summary of the Invention

[0009] Aiming at the deficiencies of the prior art, the present invention proposes a system framework based on Openresty and designs a computationally intensive application framework. Specifically, the present invention provides the following technical solutions:

[0010] First of all, the present invention provides a method for deploying a computationally intensive application based on Openresty, and the method includes:

[0011] In the initialization stage of the Openresty system, a global buffer is created; in the Openresty system, an Nginx sub-process management module is set, and the sub-process management module is used for the creation of sub-processes, the management of idle sub-processes, the recovery of abnormal sub-processes, and overload protection.

[0012] Configure an Nginx worker process to be responsible for the in and out of the system network and serve as the parent process of the sub-processes.

[0013] Establish tcp communication between the sub-processes and the parent process.

[0014] In the content processing stage, the sub-processes are responsible for the processing, forwarding, and output response of user requests.

[0015] Preferably, during the initialization phase of the Openresty system, a global Lua buffer that can be shared by all Nginx processes is created, and static data resources are stored in the Lua buffer; all child processes share the static data resources in the Lua buffer instead of sharing the Nginx parent process resources.

[0016] Preferably, the child processes are responsible for blocking calculations.

[0017] Preferably, the creation and exit of the child process management module are implemented by Openresty calling the luaposix module.

[0018] Preferably, the algorithms involved in the method are written in Lua or C / C++.

[0019] Preferably, in the child processes, LuaSocket is introduced to establish two-way communication based on the TCP protocol between the child processes and the parent process.

[0020] Preferably, the workflow of the child processes in the content processing stage is as follows:

[0021] Step 1: When the received user request is a calculation request, check whether there is an idle child process in the queue. If there is, execute Step 2; if not, create a new child process by the child process management module and execute Step 2.

[0022] Step 2: Initialize the child process and establish TCP communication between the parent process and the child process. The parent process sends the calculation request to the child process.

[0023] Step 3: The child process strips and processes the received calculation data, calls the corresponding algorithm module to process the calculation data, and pushes the returned result to the parent process.

[0024] Step 4: Check whether the parent process has received the calculation request. If it has, return to Step 3; if not, go to Step 5.

[0025] Step 5: Report the calculation result to the user. After the child process finishes the calculation, the parent process actively disconnects the TCP connection; the child process management module marks the child process as idle.

[0026] Preferably, Step 2 further includes:

[0027] When initializing the child process, load the algorithm module and create a blocking TCP service. The parent process connects to the TCP service as a TCP client. After the parent process successfully connects, push the calculation request to the TCP service to enable the child process to receive the calculation request.

[0028] Preferably, after establishing TCP communication between the child process and the parent process, the child process serves as the TCP server.

[0029] Preferably, the Lua buffer can be accessed by all parent processes and child processes.

[0030] Preferably, the different stages executed by the OpenResty system include: initialization stage, forwarding / redirecting logic stage, content processing stage, and log processing stage.

[0031] On the other hand, the present invention also provides a computing-intensive application deployment system based on OpenResty. The computing-intensive application deployment system is implemented based on the OpenResty system. The computing-intensive application deployment system includes a child process management module, and the child process management module is used for creating child processes, managing idle child processes, recycling abnormal child processes, and protecting against overload.

[0032] The computing-intensive application deployment system executes a computing-intensive application deployment method based on OpenResty as described above.

[0033] Compared with the prior art, the solution proposed by the present invention can solve the problem that computing-intensive processes block the OpenResty system. The global Lua virtual machine loads static data, thus avoiding the problem of multiple computing processes loading a large amount of static resource data multiple times. The algorithm module provides a standard C interface module, which can be directly loaded without additional encapsulation and development, and can well meet the current application requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 It is a schematic diagram of the system deployment architecture of an embodiment of the present invention;

[0035] Figure 2 It is a system data processing flow chart of an embodiment of the present invention;

[0036] Figure 3 It is a child process management flow chart of an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0037] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0038] The solution of the present invention mainly involves two aspects. One is the overall design of the child process management module, and the other is the execution process of the overall algorithm under the cooperation of the child process management module.

[0039] Sub - process Management Design

[0040] Since the Openresty system is composed of the Nginx system and the Lua virtual machine and is deployed in the Linux environment, in a specific implementation, in this solution, it is preferred to design the sub - process management module based on the fork technology, combined with the characteristics of the Lua virtual machine included in Openresty. Fork is a system - call function in Linux that can assist in creating sub - processes.

[0041] In the initialization stage of the Openresty system, preferably, a global Lua cache area that can be shared by all Nginx processes is created, and static data resources are stored in the Lua cache area; all sub - processes share the static data resources in the Lua cache area, rather than sharing the Nginx parent - process resources.

[0042] Combined with Figure 1 As shown in

[0043] 1. Create an Nginx sub - process management module. Since the execution of Lua code in Openresty is in the Nginx event loop, there should be no complex calculations or other code that may block the main loop in the Lua code. Therefore, for compute - intensive services based on the Openresty framework, it is necessary to design an Nginx sub - process management module; the sub - process is responsible for blocking calculations, and this module provides functions such as Nginx sub - process creation, idle sub - process management, abnormal sub - process recovery, and anti - overload load protection.

[0044] The creation of the Nginx sub - process management module can be achieved by Openresty calling the luaposix module, and the exit of the sub - process management module can also be achieved by Openresty calling the luaposix module.

[0045] 2. Only configure one Nginx worker process

[0046] Generally, a server is limited by the CPU capacity, and the concurrent computing request capacity is limited. And an Nginx process under the Openresty framework can easily handle more than 1K network I / Os. Therefore, only one Nginx worker needs to be configured in nginx.conf to undertake network in - and - out. At the same time, preferably, this worker process can be used as the parent process of other Nginx sub - processes, as Figure 1 shown in

[0047] 3. Establish communication between the Nginx parent and child processes through TCP.

[0048] 1) The Openresty system does not have a good Nginx parent-child process IPC communication module, so other inter-process communication methods are needed to meet process management requirements;

[0049] 2) Since the Openresty system code supports coroutines, such as Figure 1 In the process, the Nginx parent process can establish TCP connections with multiple Nginx child processes without blocking. Since TCP transmission is socket communication between single-machine processes, by optimizing TCP / IP kernel parameters, such as adjusting the TCP read and write buffer sizes, the efficiency of a single machine can be comparable to that of an IPC pipeline.

[0050] 3) LuaSocket is a network module library of Lua language, not a module of Openresty. Because the Nginx child process created by luaposix no longer has network communication function, in this embodiment, the LuaSocket module is introduced as Figure 1 Add tcp service function to the Nginx child process.

[0051] 4. Share global static resource data

[0052] Some service applications, such as AI deep learning applications, need to load a large amount of static resources into memory; therefore, the present invention is based on the Openresty system to load a large amount of data at one time during the initialization phase to facilitate the call of static data. It should be noted that through the preferred setting method in this solution, the static resources loaded into the memory are managed by the Lua virtual machine and do not occupy the memory in the Nginx system, but all processes in the Nginx system can access them.

[0053] Figure 2 This is a diagram of the execution phases of the Openresty system. The four phases of the Openresty system are as follows: (1) The main phase is to initialize Nginx and preload the Lua virtual machine, as well as to initialize the work process related work, such as starting some scheduled tasks; (2) The main phase is to perform internal URL rewriting or external request redirection; (3) The main phase is to execute business logic and generate responses; (4) The main phase is logging.

[0054] The Openresty system creates and defines a global Lua buffer in the (1) initialization phase of init_worker_by_lua*. Data loaded during this phase is stored in this global Lua buffer and accessed by all Nginx parent and child processes. This way, we only need to load static resource data into memory once during the system initialization phase, avoiding multiple copies of large amounts of data in memory.

[0055] 5. Subprocess working stage

[0056] like Figure 2 In the (3) content processing phase, Nginx receives user requests, processes, forwards, and outputs responses; all Nginx child processes created by the Nginx parent process fork also work in this phase.

[0057] 6. Algorithm module writing

[0058] The overall solution is based on the Openresty framework, which can directly call Lua modules. At the same time, the framework supports ffi to call C modules, so the algorithm module can be a module written in Lua or a C module written in C / C++.

[0059] 2. Calculation Execution Process

[0060] The following combination Figure 3 As shown in the figure, the execution process of the overall calculation is described in detail. The specific process is as follows:

[0061] 1) After Nginx receives and processes a user request, if it finds that it is a request that needs to be calculated, it first checks whether there is an idle Nginx child process in the queue. If not, it forks a new child process;

[0062] 2) Initialize the Nginx child process. When the Nginx child process initializes, it loads the algorithm module and creates a blocking TCP service. The parent process then connects to the TCP service as a TCP client and, upon successful connection, pushes the computation request to the TCP service.

[0063] 3) The Nginx child process strips and processes the received calculation data, calls the algorithm module for calculation, and blocks waiting for the calculation result; when the result is returned, it pushes the result to the parent process;

[0064] 4) Continue to determine whether the Nginx parent process receives the calculation request. If so, jump to step 3); if not, continue to step 5);

[0065] Here, it is necessary to set this loop judgment mode because some calculation request data is not transmitted to the child process at one time. Figure 3 The process (5)(7)(8) may occur multiple times and loop until the calculation of the parent process is completed;

[0066] 5) After all the user requests have been received and sent by the parent process to the child processes, the Nginx parent process analyzes the multiple calculation results and returns the analysis results to the user. At this time, the calculation tasks of the child processes have been completed, the Nginx parent process will actively disconnect the TCP connection, and the child process management module will mark the child process as idle, waiting to be called again next time.

[0067] In another embodiment, the solution of the present invention can also be implemented through a system mode based on the Openresty framework, specifically as follows:

[0068] The present invention also provides a computing-intensive application deployment system based on Openresty. The computing-intensive application deployment system is implemented based on the Openresty system. The computing-intensive application deployment system includes a child process management module, and the child process management module is used for the creation of child processes, the management of idle child processes, the recovery of abnormal child processes, and overload protection.

[0069] In the system initialization stage, a global Lua buffer is created; a Nginx worker process is configured to be responsible for the entry and exit of the system network and serve as the parent process of the child processes; the TCP communication between the child processes and the parent process is established; in the content processing stage, the child processes are responsible for the processing, forwarding, and output of user requests.

[0070] The different stages executed by the Openresty system include: the initialization stage, the forwarding / redirecting logic stage, the content processing stage, and the log processing stage. The child processes and the newly created child processes all run in the content processing stage.

[0071] The workflow of the child processes in the content processing stage is as follows:

[0072] Step 1: When the received user request is a calculation request, determine whether there is an idle child process in the queue. If there is, execute Step 2; if not, the child process management module creates a new child process and executes Step 2;

[0073] Step 2: Initialize the child process and establish the TCP communication between the parent process and the child process. The parent process sends the calculation request to the child process;

[0074] Step 3: The child process strips and processes the received calculation data, calls the corresponding algorithm module to process the calculation data, and pushes the returned result to the parent process;

[0075] Step 4: Determine whether the parent process has received the calculation request. If so, return to Step 3; if not, go to Step 5;

[0076] Step 5: Report the calculation results to the user. After the child process has completed the calculation, the parent process actively disconnects the TCP connection; the child process management module marks the child process as idle. In the specific execution of this step, when all the user requests have been received and sent by the parent process to the child process, the Nginx parent process analyzes the multiple calculation results and returns the analysis results to the user. At this time, the calculation task of the child process has been completed. The Nginx parent process will actively disconnect the TCP connection, and the child process management module will mark the child process as idle, waiting to be called again next time.

[0077] In addition, the above-mentioned calculation-intensive application deployment system can execute other contents of the calculation-intensive application deployment method, such as creating a child process management module and establishing a TCP connection between the child process and the parent process.

[0078] As can be seen from the description of the above specific embodiments, compared with the prior art, the solution proposed by the present invention can avoid the problem of calculation processes blocking the Openresty framework; it can avoid the problem of multiple calculation processes simultaneously loading a large amount of static resource data; the algorithm module provides a standard C interface module, without the need for additional encapsulation development, and can well meet the current application requirements.

[0079] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the above embodiments of the methods. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM), etc.

[0080] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A deployment method for compute-intensive applications based on Openresty, characterized in that, The method includes: In the initialization stage of the Openresty system, a global Lua buffer is created, and static data resources are stored in the Lua buffer. During the initialization stage, the Lua buffer is accessed by all parent and child processes. All child processes share the static data resources in the Lua buffer instead of sharing the parent process resources. The child processes are responsible for blocking calculations; An Nginx child process management module is set in the Openresty system. The Nginx child process management module is used for the creation of child processes, the management of idle child processes, the recovery of abnormal child processes, and overload protection. The creation and exit of the Nginx child process management module are implemented by Openresty calling the luaposix module; Configure an Nginx worker process, which is responsible for the in and out of the system network and serves as the parent process of the child processes to establish tcp communication between the child processes and the parent process; The different stages executed by the Openresty system include: the initialization stage, the forwarding or redirection logic stage, the content processing stage, and the log processing stage. In the content processing stage, the child processes are responsible for the processing, forwarding, and output of user requests; The workflow of the child processes in the content processing stage is as follows: Step 1: When the received user request is a calculation request, check whether there is an idle child process in the queue. If there is, execute Step 2; if not, the child process management module creates a new child process and executes Step 2; Step 2: When the child process is initialized, load the algorithm module and create a blocking tcp service. The parent process connects to the tcp service as a tcp client. After the parent process connects successfully, push the calculation request to the tcp service to enable the child process to receive the calculation request; Step 3: The child process strips and processes the received calculation data, calls the corresponding algorithm module, and blocks waiting for the calculation result. When the calculation result is returned, it is pushed to the parent process; Step 4: Check whether the parent process has received the calculation request. If it has, return to Step 3; if not, go to Step 5; Step 5: When all requests have been received and the parent process notifies the child process, the parent process analyzes the multiple calculation results and reports the analysis results to the user. After the child process completes the calculation, the parent process actively disconnects the tcp connection. The Nginx child process management module marks the child process as idle.

2. The method according to claim 1, characterized in that The creation and exit of the Nginx child process management module are implemented by Openresty calling the luaposix module.

3. The method according to claim 1, wherein In the child process, LuaSocket is introduced to establish two-way communication based on the tcp protocol between the child process and the parent process.

4. The method according to claim 1, wherein After establishing tcp communication between the child process and the parent process, the child process acts as a tcp server.

5. A computing-intensive application deployment system based on Openresty, characterized in that, The calculation-intensive application deployment system based on Openresty executes a calculation-intensive application deployment method based on Openresty as described in any one of claims 1-4.

Images