Method of managing performance in distributed system with publish-subscribe architecture

Abstract

The invention relates to a method (100) for managing performance in a distributed system (1) having a proxy-based publish-subscribe architecture, the method comprising the steps of:-determining (101) at least one performance requirement of the distributed system (1) on the basis of a network state of the distributed system (1), the network state is specific to the traffic and / or execution performance of the distributed system (1); -identifying (102) important events, where the important events describe changes to the distributed system (1); -changing (103) the distributed system (1) on the basis of the important events; determining (104) a new network state of the changed distributed system (1); -analysing (105) the new network state with respect to at least one performance requirement of the distributed system (1); and performing (106) at least one countermeasure as a function of a result of the analysis (105). The invention also relates to a computer program, a device and a storage medium for this purpose.

Description

Technical Field

[0001] The present invention relates to a method for managing performance in a distributed system having a publish-subscribe architecture based on a broker. The present invention also relates to a computer program, a device and a storage medium for this purpose. Background Art

[0002] Message-oriented communication and RPC (Remote Procedure Call) can be commonly used communication patterns in distributed systems. However, there may be some important differences between the two, through which message-oriented communication can be better used for distributed applications.

[0003] The first difference may be that message-oriented communication is asynchronous, which means that the sender may not have to wait for the response of the receiver. In contrast, RPC may be synchronous, which means that the sender may have to wait for the response of the receiver before he continues his operation. The second difference may be stability. If the receiver is temporarily unavailable, the message can be queued in accordance with message-oriented communication and delivered later, thereby ensuring that the message is not lost. In contrast, RPC may fail when the receiver is unavailable or when there are network problems. The third difference may be scalability. In a message-oriented architecture, messages can be distributed across multiple edge devices, thereby allowing horizontal expansion, while RPC may be limited to a single edge device. The fourth difference may be loose coupling. In a message-oriented architecture, the sender and receiver may not need to know the implementation details of each other, and messages can be sent between different platforms and programming languages. In contrast, RPC may require that the sender and receiver share a common interface and may be limited to a specific programming language. Accordingly, in modern distributed systems, message-oriented architectures such as message buses can be used to support various messaging platforms, ensure message delivery guarantees, and simplify communication. A common communication pattern called Pub-Sub (Publish-Subscribe) can facilitate the exchange of information between data producers (publishers) and consumers (subscribers). Pub-Sub may be implemented by allowing publishers to forward their data through a message broker (or a collection of message brokers). In a Pub-Sub system, publishers can send messages to brokers without knowing who will consume the messages, and subscribers can express their interest in messages of a specific topic or type without knowing who published the message. The broker can act as an intermediary that receives messages from publishers and forwards them to subscribers based on their interests.

[0004] The Pub-Sub mechanism is very popular due to its flexibility and the possibility of decoupling senders from receivers, where communication endpoints can communicate without knowing each other's addresses and performing asynchronous message delivery. In addition, in a distributed Pub-Sub architecture, users and data can be load-distributed across distributed edge devices to support the scalability and fault tolerance of large-scale networks. Proxy-based Pub-Sub can be a standard implementation of Pub-Sub, which can use technologies and standard components such as agents, libraries, and application frameworks, which can be widely used in the Internet of Things or IoT and cloud services. This may be important within the edge cloud orchestration framework, where distributed applications can be managed across different IP networks. Pub-Sub can also allow interoperability with other applications that communicate over the same protocol. Pub-Sub can also avoid addressing and naming issues, and can facilitate transparent deployment of application components across the edge and cloud. Since the proxy can act as a centralized control point for the messaging system, the proxy can allow easier management and monitoring of the system.

[0005] Most Pub-Sub architectures and implementations can work on a best-effort basis. They may not have precautions to handle time-critical traffic in a certain way: the broker may treat all messages similarly, with no traffic differentiation and no guaranteed service principles. The quality of service in existing Pub-Sub systems may be limited to delivery guarantees, such as messages being delivered at least once or at most once. Even considering time-critical traffic, existing approaches tend to shift the responsibility for timely message delivery to the communication infrastructure, and subscriber interests may be mapped to multicast groups. In this solution, standard Pub-Sub implementations using brokers may lack flexibility, as multicast groups may not be accurately mapped to interest management mechanisms in traditional Pub-Sub that can handle complex filtering in terms of topics and data content. They may also be difficult to set up across different subnets, especially when these subnets are managed by separate entities or organizational units. Summary of the invention

[0006] According to aspects of the invention, a method having the features of claim 1, a computer program having the features of claim 10, a data processing device having the features of claim 11 and a computer-readable storage medium having the features of claim 12 are provided. Further features and details of the invention are disclosed in the respective dependent claims, in the description and in the drawings. Features and details described in the context of the method according to the invention also correspond to the computer program according to the invention, the data processing device according to the invention and the computer-readable storage medium according to the invention, and vice versa, respectively.

[0007] According to one aspect of the present invention, there is provided a method for managing performance in a distributed system having a proxy-based publish-subscribe architecture, the method comprising the following steps, wherein the steps are preferably performed continuously and / or repeatedly:

[0008] -determining at least one performance requirement of the distributed system based on a network state of the distributed system, wherein the network state is specific to a flow and / or an execution performance of the distributed system;

[0009] - identifying significant events, wherein the significant events describe changes to the distributed system;

[0010] - Based on the significant event, change the distributed system;

[0011] -determine the new network state of the changed distributed system;

[0012] - Analyze the new network state with respect to at least one performance requirement of the distributed system;

[0013] -Based on the results of this analysis, implement at least one response action.

[0014] A broker-based publish-subscribe architecture may be a type of distributed system in which messages are produced by some parts of the distributed system ("publishers") and consumed by other parts of the system ("subscribers"). This type of distributed system involves, among other things, an intermediary called a broker, which may handle the routing of messages. A "publisher" may generate messages and send them to a broker without knowing who will receive them, which may be referred to as "publishing". A "subscriber" may express interest in certain types of messages by means of a process referred to as "subscription". To this end, these subscribers may report their interest to the broker, usually with the aid of some type of filtering mechanism. This may be achieved through named topics. Then, these subscribers may have a general idea of ​​the topics they are interested in. Then, the broker may receive the published messages and distribute them to all interested subscribers based on their subscriptions. In one example of the present invention, a commodity or COTS broker that does not provide differentiated services is used. This type of broker may not be able to change the internal behavior of the broker itself because it is closed source and only binary files are available. This type of architecture may decouple publishers from subscribers, which means, among other things, that publishers do not need to know who their subscribers are, and vice versa. Thus, the distributed system can advantageously become very scalable because publishers or subscribers can be added or removed without affecting other publishers or subscribers. The distributed system may also include an orchestrator that can be designed to provide deployment and management of various runtime modules across edge devices of the distributed system in accordance with at least one performance requirement of the distributed system. In other words, the important event describing the change can indicate that the important event is specific to the changes that the distributed system may need to perform due to the important event. The at least one performance requirement can be, for example, the corresponding end-to-end delay of at least one application of the distributed system, especially each application, or can be the defined end-to-end delay of the at least one application, especially each application. The defined end-to-end delay of the at least one application can be a characteristic of the at least one application, which can be defined by a user or by the specification of the at least one application. The end-to-end delay may be affected by the execution time of the module components of the application, the transmission delay in the network of the distributed system, and the delay within the agent of the distributed system. Another example of a performance requirement is the throughput of the agent. The analysis of the new network state can be performed by a specified module, which can be called an auxiliary module. For applications already deployed in a distributed system, analysis of the new network state may include examining whether the additional traffic load due to the significant event (eg, a new application) may negatively impact the performance of existing applications already running in the distributed system.The analysis may take into account the current traffic being processed by the proxy, its processing rate, and may also perform a permission check as to whether any incoming applications will adversely affect the performance of existing applications. In addition, the applications, edge devices, and connections involved may be identified and reported so that at least one countermeasure may be taken accordingly. A method including at least the above steps may be advantageous so as to enable management and optimization of the performance of a distributed system.

[0015] It is possible that the significant event is a requirement to deploy a new application in a distributed system, wherein at least one characteristic of the new application is defined. The at least one characteristic may be appended as an additional performance requirement to the at least one performance requirement of the distributed system. The at least one characteristic may for example be: the application topology, details on how the new application may be divided into modules, the communication between the module components of the new application, such as corresponding messages published and subscribed. Furthermore, the at least one characteristic may include the location and resources such as network, computing or input / output required for the modules of the new application, and the end-to-end latency of the new application.

[0016] The method may further comprise the steps of:

[0017] -Deploy at least one module of a new application on at least one edge device of the distributed system taking into account at least one performance requirement of the distributed system.

[0018] Deploying the at least one module on the at least one edge device may indicate that the module is deployed on a runtime of the at least one edge device. An application may typically include various modules, which for their part may be deployed on various edge devices of a distributed system. The at least one performance requirement preferably includes at least one characteristic of a new application, such that the deployment of the at least one module is also performed taking into account the at least one characteristic of the new application.

[0019] The at least one countermeasure may include the following steps:

[0020] -Deploying the at least one module of the new application on another edge device of the distributed system taking into account at least one performance requirement of the distributed system.

[0021] Deploying the at least one module of the new application on another edge device of the distributed system can be advantageous because various configurations of the module components of the new application can be examined to find a configuration of the distributed system that meets at least one performance requirement of the distributed system.

[0022] In another example, the at least one countermeasure comprises the following steps:

[0023] -Deploy at least one module of an existing application of the distributed system on another edge device of the distributed system while taking into account at least one performance requirement of the distributed system.

[0024] At least one characteristic may also be defined for the existing application. The at least one characteristic of the existing application may be, for example, application topology, details on how the existing application may be divided into modules, communications between module components of the existing application, such as corresponding messages published and subscribed. In addition, the at least one characteristic may include the location and resources such as network, computing, or input / output required for the module of the existing application, and the end-to-end latency of the existing application. It may also be advantageous to deploy the at least one module of the existing application on another edge device of the distributed system, because various configurations of the module components of the existing application may be examined in order to find a configuration of the distributed system that meets at least one performance requirement of the distributed system.

[0025] It is possible that the method further comprises the following steps:

[0026] - calculating an end-to-end delay of the new application, in particular a resolved end-to-end delay, and an available margin, wherein the available margin is specific to a difference between the end-to-end delay of the new application and a required end-to-end delay of the new application, wherein the required end-to-end delay is defined by at least one characteristic of the new application;

[0027] - Modify the rate of outgoing messages of the module component of the new application according to the calculated available margin.

[0028] These steps, i.e., calculating the end-to-end delay and modifying the rate of outgoing messages, can be performed by at least one corresponding runtime of the corresponding edge device on which these module components are deployed. By modifying the rate of outgoing messages, the traffic of the distributed system can be advantageously shaped in an accurate and differentiated manner. As a result, the at least one performance requirement can be met due to the shaping of the traffic by modifying the rate of outgoing messages. Modifying the rate of outgoing messages can include: applying a rate limiting parameter. Some examples of such rate limiting parameters are the number of messages transmitted within a time window or the maximum input / output bandwidth or utilization of a module. In addition, the message delivery or transmission of a given module can be offset by a preset number of time units. Outgoing messages can also be reordered according to priority. Different traffic priorities can be assigned to modules in the same runtime, for example, in a manner that always places best-effort traffic after any real-time traffic.

[0029] In another example, the at least one countermeasure comprises the following steps:

[0030] - Introducing an output of a notification, wherein the notification indicates that the at least one performance requirement of the distributed system is not met.

[0031] This notification can be output to a user interface so that the user can advantageously initiate corresponding countermeasures.

[0032] The network status may include at least one of the following factors:

[0033] - the current flow injected in the distributed system through the module components;

[0034] - Network topology of distributed systems;

[0035] -Network service rate of distributed systems;

[0036] -The throughput of the agents in the distributed system.

[0037] The network topology may include a description of the connections between modules in the distributed system. The network service rate may be the bandwidth available in the distributed system. The throughput of the agent may also be referred to as the service rate of the agent. The network status may also include: individual execution times of module components of the distributed system; and individual transmission times between corresponding module components of the distributed system. Other factors are: the cumulative execution time of all module components of the distributed system; and the cumulative transmission time between all module components of the distributed system. If the at least one performance requirement can be met, then evaluating these factors may be advantageous.

[0038] Determining the network status of a distributed system may include the following steps:

[0039] - Performing an analysis of the throughput of a proxy of a distributed system, wherein the minimum, average and worst-case throughput of the proxy is determined under various combinations of settings.

[0040] The various settings may include: a change in packet injection rate, the size of the message, the message delivery settings, or the number of subscribers. This may advantageously allow for a more differentiated analysis of the network state. As a result, it may advantageously be more accurately determined whether the at least one performance requirement of the distributed system is met.

[0041] The distributed system may include at least two proxies. Providing more than one proxy may advantageously improve the performance of the distributed system.

[0042] The method may further comprise the steps of:

[0043] - clustering application components of the distributed system to a respective one of the at least two proxies, wherein the clustering is performed with respect to the at least one performance requirement of the distributed system.

[0044] It is possible that a respective one of the at least two agents is designated to take precautions for a respective requirement of the distributed system. For example, one of the at least two agents may provide for enabling real-time execution of an application as a respective performance requirement of the distributed system.

[0045] In another aspect of the invention, a computer program, in particular a computer program product, may be provided, the computer program comprising instructions which, when executed by a computer, cause the computer to perform the method according to the invention. Thus, the computer program according to the invention may have the same advantages as those described in detail with reference to the method according to the invention.

[0046] In another aspect of the invention, a data processing device may be provided, which is designed to perform the method according to the invention. For example, a computer may be provided as the device, which executes the computer program according to the invention. The computer may include at least one processor, which may be used to execute the computer program. A non-volatile data memory may also be provided, in which the computer program may be stored and from which the computer program may be read by the processor for execution.

[0047] According to another aspect of the present invention, a computer-readable storage medium may be provided, the computer-readable storage medium comprising a computer program and / or instructions according to the present invention, which, when executed by a computer, cause the computer to perform the steps of the method according to the present invention. The storage medium may be formed as a data storage device, such as a hard disk and / or a non-volatile memory and / or a memory card and / or a semiconductor drive. The storage medium may, for example, be integrated into the computer.

[0048] Furthermore, the method according to the invention may be realized as a computer-implemented method. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Other advantages, features and details of the present invention are apparent from the following description, in which embodiments of the present invention are described in detail with reference to the accompanying drawings. In this context, the features mentioned in the claims and in the description may reflect the essence of the present invention individually or in any combination. Among them:

[0050] Figure 1 Methods, computer programs, storage media and devices according to embodiments of the present invention are shown;

[0051] Figure 2 A distributed system with one agent according to an embodiment of the present invention is shown;

[0052] Figure 3 A distributed system with two brokers according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0053] Figure 1 A computer program 20, a storage medium 15 and a device 10 according to an embodiment of the invention are shown.

[0054] Figure 1 Also shown is a method 100 for managing performance in a distributed system 1 having a proxy-based publish-subscribe architecture according to an embodiment of the present invention. In a first step 101, at least one performance requirement of the distributed system 1 is determined based on a network state of the distributed system 1. The network state may be specific to the traffic and / or execution performance of the distributed system 1. In a second step 102, an important event is identified. The important event may describe a change in the distributed system 1. In a third step 103, the distributed system 1 is changed based on the important event. In a fourth step 104, a new network state of the changed distributed system 1 is determined. In a fifth step 105, the new network state is analyzed with respect to at least one performance requirement of the distributed system 1. In a sixth step 106, at least one countermeasure is performed based on the result of the analysis 105.

[0055] Figure 2 A distributed system 1 with a proxy 4 according to an embodiment of the present invention is shown. Figure 2 In the embodiment, the distributed system 1 further comprises an edge device 3 and another edge device 3 ′, which have corresponding runtimes 6 and corresponding modules 2 deployed thereon. Figure 2 The distributed system 1 also includes an orchestrator 5. Figure 2 It is also schematically shown that input from a user 7 may be provided to the orchestrator 5 .

[0056] Figure 3 A distributed system 1 with two proxies 4 according to an embodiment of the invention is shown. For each of these proxies 4, Figure 3 The distributed system 1 in also includes an edge device 3 and another edge device 3 ′, which have corresponding runtimes 6 and corresponding modules 2 deployed thereon. Figure 3 The distributed system 1 in further comprises an orchestrator 5. According to an embodiment of the present invention, one of these proxies 4 may be provided for real-time traffic flows and another proxy 5 may be provided for best-effort traffic flows.

[0057] In a distributed environment, the end-to-end latency of an application may be affected by a variety of factors. These factors include: the execution time of the module component 2 on the host edge device 3; the transmission delay in the network; and the delay in the agent 4. Since the agent 4 can act as an intermediary for all applications, the agent may become an important bottleneck and have a negative impact on the application latency. However, the implementation of extended QoS (quality of service) in the commodity agent 4 may be problematic. This may be because: the implementation may require the agent 4 to track the QoS requirements of the application flow, distinguish between traffic flows, and prioritize these traffic flows. Therefore, agent-based solutions can usually use a simple First-In-First-Out or FIFO mechanism to handle requirements and limit its ability to publish data packets to interested subscribers.

[0058] The present invention can provide a mechanism for a proxy-based Pub-Sub network that can provide quality of service or QoS guarantees involving end-to-end timing by shaping the traffic sent in the direction of the proxy 4, and may not require any modification to the proxy 4.

[0059] One aspect in the context of the present invention may be a mechanism that ensures specific timing guarantees for a set of applications that communicate using Pub-Sub with the help of a standard agent 4 (commodity / standard). The mechanism may be implemented with the help of an application management framework, which may include: a runtime component deployable on a distributed edge device 3; and a dedicated orchestrator 5. Each runtime component may be responsible for: executing and hosting application executables, which may be referred to as modules 2, on the edge device 3 on which the runtime is deployed; and implementing the allocation of computing resources of the edge device 3 to the various modules 2. In contrast, the orchestrator 5 may be responsible for: performing licensing checks for new applications to be deployed; and finding a mapping of modules to runtimes and system configurations (edge ​​devices 3 and networks), which may ensure that: they meet the QoS requirements of all applications. In addition, the orchestrator 5 may be responsible for reconfiguring the system to react to dynamic events, such as the deployment of new applications or the termination of running applications.

[0060] The orchestrator 5 may have a global view of the distributed system 1 and may know where the various modules 2 are deployed, the topics that these modules publish and subscribe to, and the data that flows between these modules. In addition, the orchestrator 5 may understand the real-time requirements of the application. With this information, the orchestrator 5 can make intelligent decisions about how resources should be allocated and traffic flows shaped to ensure that the system meets its real-time requirements.

[0061] In the proposed method, the dedicated orchestrator 5 can ensure timing guarantees by, first, profiling the service rates of commodity standard proxies 4, monitoring network conditions, intelligently deploying applications, and controlling outgoing traffic (i.e., traffic shaping) from each of the runtimes to ensure that the end-to-end requirements of the application can be guaranteed. If multiple proxies 4 are used, the orchestrator 5 can also map messages (topics or content) to specific proxies 4 to thereby optimally influence network traffic and application performance.

[0062] The proposed edge orchestration 5 framework includes the following components, such as Figure 2 as shown in .

[0063] An orchestrator 5, which can play a role in deploying and managing modules 2 across different runtimes according to the specific requirements of the application. To collect information about the application, the orchestrator 5 can read: the application manifest, in which the user can specify the application topology; and details about how the application can be divided into different modules 2; and the communication that occurs between these modules, such as published and subscribed messages. Additionally, the application manifest can include: other requirements, such as the location and resources (network, compute, E / A (input / output)) required for the application module 2; end-to-end timing requirements; the number of replicas required; and availability requirements. The orchestrator 5 can fully understand the network topology, including edge devices 3 and connections, and the available runtimes on which the application modules 2 can be deployed. By reading the application manifest, the orchestrator 5 can deploy various application modules 2 on suitable runtimes to meet the timing requirements of the application.

[0064] Each of the edge devices 3 can be equipped with a runtime that can generate a secure and isolated execution environment that can include built-in security checks. The runtime can also manage internal resource reservations for the edge device 3 and can abstract the operating system and hardware. Initially, all runtimes can register at the orchestrator 5 and send regular updates about the available resources on the edge device 3 and the deployed modules 2 and their current life cycle status. In addition, the runtime can implement any instructions sent by the orchestrator 5, such as the startup or deletion of a module 2. At startup, the runtime can register at the proxy 4, and all applications hosted on the same runtime can inherit the same proxy 4. This means, in particular, that the entire message communication can be redirected via the proxy 4. In addition, the runtime can be responsible for implementing the traffic shaping parameters sent by the orchestrator 5.

[0065] A message broker 4 may act as an intermediary, thereby decoupling senders and receivers and the publisher and subscriber lists registered for each topic. The broker 4 may send published messages to interested subscribers. A standard or COTS broker (Commodity Off-The-Shelf) 4 may be assumed, thereby ensuring delivery guarantees according to the required QoS, but the standard or COTS broker may not have mechanisms for differentiated services for specific flows or any timing-related guarantees.

[0066] In the following, a method according to an embodiment of the present invention is described. In a first step, an offline analysis of the service rate of the proxy 4 may be performed. The first step in the process may be to analyze and experimentally profile the service rate of the proxy 4. This may be performed to determine the minimum, average, and worst case throughput of the proxy 4 under various combinations of settings. These settings may include: changes in the packet injection rate, the size of the message, the message delivery settings, or the number of subscribers.

[0067] Experiments can be performed to synthetically generate traffic patterns to exercise all of the above scenarios. Ultimately, the maximum latency that the proxy 4 can have in fulfilling a request can be calculated, depending on various factors, including, among others: the characteristics of the request itself, such as publishing rate, message size, and number of subscribers involved; the processing method used by the proxy 4, such as single-threaded or multi-threaded; the size of the buffer in the proxy 4; and / or the number of outstanding requests already in the proxy 4 when the relevant request arrives.

[0068] In the following, it is described in more detail which steps the orchestrator 5 may perform for each significant event. A significant event may be: the arrival of a new deployment request for an application; an event reporting a change in network load (exceeding a defined threshold); the completion of an application deployment request; the registration of a new runtime; when a runtime is disconnected; or a modification of the frequency of a periodic message.

[0069] An application may specify its deployment requirements via an application manifest as described above. The goal of the orchestrator 5 may be to place the application module 2 on a suitable edge device so as to satisfy the placement and timing constraints of the incoming application while also preserving the timing guarantees provided to other existing applications. To this end, the orchestrator 5 may perform the following steps.

[0070] In a first step, orchestrator 5 may check end-to-end application timing requirements, module 2 dependencies, and message communication requirements, such as publishing rate, message size, and number of subscribers.

[0071] In a second step, the orchestrator 5 may perform a permission check. The check may essentially answer questions such as: whether the module 2 of the application is deployed on a particular edge device 3; what the additional network load imposed is; and whether the network load will adversely affect the timing behavior of the existing application. The orchestrator 5 may attempt to find an initial deployment or initial mapping strategy so that the basic application constraints are met, and may then run the permission check. The permission check may attempt to map the module 2 with the available network resources while taking into account the constraints specified in the application manifest, such as the inputs and / or outputs of the module 2.

[0072] If it is determined that no adverse performance is produced for existing applications, the existing deployment strategy can be maintained. If it is determined that adverse performance is produced for existing applications, that is, if the additional network load adversely affects the timing behavior of existing applications, the orchestrator 5 can use a combination of various countermeasures or strategies described below.

[0073] According to a first countermeasure, the orchestrator 5 may map the application module 2 to a different edge device 3 and rerun the permission check.

[0074] The permission check may also return network load information on a connection-by-connection basis, so that according to the second policy, the orchestrator 5 may use this information to make alternative mapping decisions.

[0075] If a module 2 of an existing application can be migrated to a different edge device 3 while still always respecting the deadlines specified in the application manifest, the arriving application module 2 can instead be placed there.

[0076] For a given arriving application and a given deployment strategy, the resolved end-to-end latency of the application and the available margin can be calculated, i.e., the difference between the required end-to-end latency of the application and the current end-to-end latency. If the margin is positive, the runtime can shape the outgoing rate of messages of the application traffic6 so that the messages are sent at a slower rate to provide a possible second response. With this new setting, the license check can be rerun. For runtimes hosting applications that do not have strict timing requirements, the outgoing traffic parameters can be limited, i.e., the number of messages outgoing within the time interval can be reduced in successive steps, and the license check can be rerun. Thereby, the network load on the network can be reduced.

[0077] If the application cannot be deployed within a predefined time limit after trying multiple of the above countermeasures, orchestrator 5 may send a corresponding notification.

[0078] The above process can be implemented in various scenarios that affect the entire traffic flow in the network or the network topology itself. These scenarios may include: registration of a new runtime, connection failure, crash of the runtime or edge device 3, changes in the set of deployed applications, etc.

[0079] This permission check can be used in order to assess the suitability of an arriving application for deployment. This permission check can effectively use an auxiliary module 2, which provides information about the load status of different network segments and connections and the current service rate of the proxy 4. This check can calculate the end-to-end delay of new applications as well as the end-to-end delay of already deployed, i.e. existing applications. This calculation can be performed using formal timing analysis methods. For example, tools can be used to model the network, traffic flows and perform combined network analysis, reporting statistics such as network delays to the auxiliary module 2.

[0080] For applications that are already deployed and have strict timing requirements, i.e., existing applications, the permission check can check whether the additional traffic load from the new application may have a negative impact on the performance of existing applications that are already running in the system. The permission check can identify any applications, edge devices 3, and connections involved, and this information can be reported back to the orchestrator 5. The orchestrator 5 can then choose to continue with the application deployment or to redeploy the module 2 on a less loaded edge device 3 to mitigate the degradation. The load and performance of the proxy 4 can also be calculated, and if the functional capacity threshold is exceeded, the orchestrator 5 can send instructions to implement a traffic shaping policy for applications with positive margins.

[0081] In addition to the managed sandbox execution environment, the runtime as described above can be responsible for implementing traffic shaping parameters. All modules 2 deployed on the edge device 3 can run within the runtime of the edge device 3, and the runtime can provide controlled access to resources such as files, CPUs, or networks of the edge device 3. All outgoing messages can be intercepted by the runtime. In addition, the runtime can apply rate limiting parameters to outgoing traffic. Some examples are presented below. The number of messages transmitted within a time window can be limited. Module 2X of application Y can be allowed to set k messages within a time period of y ms. The maximum input / output bandwidth or utilization of module 2 can be limited. The message delivery or transmission of a given module 2 can be offset by a specified number of time units. Outgoing messages can be reordered according to priority. Within the same runtime, different traffic priorities can be assigned to these modules 2, for example, in a way that best-effort traffic is always placed after any real-time traffic leaving the runtime.

[0082] In addition to traffic shaping, the orchestrator 5, if available, may also request that the runtime use link layer mechanisms to prioritize and / or enforce guarantees. This may be performed as follows.

[0083] In a standard Ethernet-based network, the orchestrator 5 may output instructions to the runtime to assign a service label class to outgoing messages. This may require that all network devices support IEEE 802.1P, which may be very common and may allow the orchestrator 5 to implement traffic differentiation at the runtime level, which, for example, allows isolation between applications running on different edge devices 3. In an Ethernet network with TSN (Time-Sensitive Networking), the orchestrator 5 may design the runtime to utilize TSN, a set of standards that allow time-sensitive communications via Ethernet networks. TSN is particularly designed to ensure guaranteed delivery of time-critical data and reduce network latency and jitter. This can be achieved by defining a set of required features, such as time synchronization, traffic shaping, and priority-based queuing to ensure that time-sensitive traffic is delivered within a specified time range and without interference from other non-time-sensitive traffic. In this case, TSN parameters may be dynamically configured by the orchestrator 5 to help shape traffic with the COTS agent 4.

[0084] To expand the capacity of the system, the agents 4 can be clustered together using various configurations. In a first configuration, computing edge devices 3 in a local edge network can communicate through an edge agent 4, which in turn communicates with a central agent 4. These agents 4 can be assigned to handle different classes of traffic in a single local network. The runtime can then be registered at the appropriate agent 4 by the orchestrator 5, which can statically assign the runtime to the agent 4, or the orchestrator can dynamically decide which agent 4 should be used based on the modules 2 deployed thereon and the timing guarantees that must be met. The method for runtime traffic shaping can also be applied in devices with multiple agents 4 to achieve more complex traffic management and control.

[0085] In a possible first configuration, the central agent 4 may be responsible for allocating network resources based on the specific needs of each computing edge device 3, such as available bandwidth, latency requirements, and the amount of traffic. The auxiliary module 2 may be responsible for identifying and resolving network congestion or failures by adjusting traffic flows and directing traffic on alternative network paths.

[0086] In the case of a single local edge network according to a possible second configuration, there may be two countermeasures or strategies. According to the first countermeasure, the network can be statically partitioned. In this case, the orchestrator 5 can be responsible for partitioning the network into multiple subnets, which are optimized for specific types of traffic. For example, one subnet may be optimized for real-time traffic, while another subnet may be optimized for best-effort traffic. Each subnet can be assigned to a specific agent 4, which is responsible for handling the corresponding type of traffic. The orchestrator 5 can route traffic to a suitable agent 4 based on the traffic type and the defined criteria or rules. For real-time traffic, the orchestrator 5 can also deploy real-time applications on specific edge devices 3 or runtimes optimized for low latency and high reliability. This ensures that critical data is processed quickly and correctly without delays or interruptions due to other non-real-time traffic.

[0087] According to the second strategy, the network can be dynamically partitioned. Therefore, module 2 is dynamically migrated to a runtime registered at a specific proxy 4. This can be useful if module 2 requires specific resources or capabilities that are only available on a specific runtime, or if module 2 must be deployed in a subnet optimized for a specific type of traffic. Another strategy can be to keep the runtime on the edge device 3 and replace the proxy 4 where the runtime is registered. This can be useful if network conditions or traffic patterns change and the module's traffic needs to be routed to another proxy 4 that can better handle the traffic load or can provide better performance.

[0088] The above description of the embodiments describes the present invention in the context of examples. Of course, the individual features of these embodiments can be freely combined with each other as long as it is technically reasonable without departing from the scope of protection of the present invention.

Claims

1. A method (100) for managing performance in a distributed system (1) having a proxy-based publish-subscribe architecture, the method comprising the following steps: - based on the network status of the distributed system (1), determining (101) at least one performance requirement of the distributed system (1), wherein: The network state is specific to the traffic and / or execution performance of the distributed system (1); - identifying (102) significant events, wherein the significant events describe changes in the distributed system (1); - based on the significant event, changing (103) the distributed system (1); - determining (104) a new network state of the changed distributed system (1); - analyzing (105) the new network state with respect to the at least one performance requirement of the distributed system (1); - Based on the result of said analysis (105), at least one countermeasure is executed (106).

2. The method (100) according to claim 1, characterized in that: The significant event is a requirement for deploying a new application in the distributed system (1), wherein at least one characteristic of the new application is defined, wherein the at least one characteristic is added as an additional performance requirement to the at least one performance requirement of the distributed system (1), wherein the method (100) further comprises the steps of: - Deploying at least one module (2) of the new application on at least one edge device (3) of the distributed system (1) taking into account the at least one performance requirement of the distributed system (1).

3. The method (100) according to claim 2, characterized in that: The at least one countermeasure comprises the following steps: - Deploying the at least one module (2) of the new application on another edge device (3') of the distributed system (1) taking into account the at least one performance requirement of the distributed system (1).

4. The method (100) according to claim 2 or 3, characterized in that: The at least one countermeasure comprises the following steps: - Deploy at least one module (2) of an existing application of the distributed system (1) on another edge device (3') of the distributed system (1) taking into account the at least one performance requirement of the distributed system (1).

5. The method (100) according to any one of claims 2 to 4, characterized in that The method (100) further comprises the following steps: - calculating the end-to-end delay of the new application and an available margin, wherein the available margin is specific to the difference between the end-to-end delay of the new application and a required end-to-end delay of the new application, wherein the required end-to-end delay is defined by the at least one characteristic of the new application; - modifying the rate of outgoing messages of the module component (2) of the new application according to the calculated available margin.

6. The method (100) according to any one of the preceding claims, characterized in that The at least one countermeasure comprises the following steps: - outputting of an initiation notification, wherein the notification indicates that the at least one performance requirement of the distributed system (1) is not met.

7. The method (100) according to any one of the preceding claims, characterized in that The network status includes at least one of the following factors: - the current flow rate injected into the distributed system (1) through the module assembly (2); - the network topology of the distributed system (1); - the network service rate of the distributed system (1); - The throughput of the agents (4) of the distributed system (1).

8. The method (100) according to any one of the preceding claims, characterized in that Determining the network status of the distributed system (1) comprises the following steps: - performing an analysis of the throughput of the agents (4) of the distributed system (1), wherein the minimum, average and worst case throughput of the agents (4) are determined under various combinations of settings.

9. The method (100) according to any one of the preceding claims, characterized in that The distributed system (1) comprises at least two agents (4), and the method (100) further comprises the following steps: - clustering application components of the distributed system (1) to a respective one of the at least two proxies (4), wherein the clustering is performed with respect to the at least one performance requirement of the distributed system (1).

10. A computer program (20), comprising instructions which, when executed by a computer (10), cause the computer (10) to perform the method (100) according to any one of the preceding claims.

11. A data processing device (10) comprising means for executing the method (100) according to any one of claims 1 to 9.

12. A computer-readable storage medium (15), comprising instructions which, when executed by a computer (10), cause the computer (10) to perform the steps of the method (100) according to any one of claims 1 to 9.

Images