120 in place of using individual instances of task 115c and/or 115d. For example, in response to an indication of acceptance by a particular user associated with user account 250b, computer system 101 may modify service instance 110b of networked service 205 to call global process 120 in place of calling an individual instance of task 115c that was initiated for the particular user. Computer system 101 may further modify user account 250b of the particular user while service instance 110b is active. In such cases, service instance 110b may be initiated prior to the creating of global process 120. In response to the modifying of user account 250b, the instance of task 115c associated with active service instance 110c is terminated, thereby reducing processing overhead for box 210b.

To replace a given one of tasks 115, computer system 101 may be operable to generate an application interface for global process 120, e.g., GP API 225c and GP API 225d. Each of GP API 225c and GP API 225d, as depicted, correspond to task 115c and task 115d, respectively. A call to GP API 225c causes global process 120 to perform operations associated with task 115c and, likewise, a call to GP API 225d causes global process 120 to perform operations associated with task 115d. Accordingly, modifying user account 250b in the above example includes replacing a respective instance of task 115c with an instance of GP API 225c.

As shown, computer system 101 identifies a plurality of instances for both task 115c and 115d being performed by service instances 110. Computer system 101 may, therefore, request ones of the plurality of users that are using both tasks 115c and 115d to indicate which of the respective global processes are approved for use by the particular user. As seen in FIG. 2, a user of user account 250a agrees to use GP API 225c to replace task 115c as well as to use GP API 225d to replace task 115d. A user of user account 250c, however, agrees only to use GP API 225d to replace task 115d, and retains use of task 115c. Such flexibility may ease a user's concerns with using a global process in place of using an individual instance of a task, thereby potentially increasing a number of users willing to adopt use of global processes to reduce processing bandwidth.

After global process 120 has been generated and executed for a first time, global data set 122 is generated and access to the global data set is provided to respective accounts of the users agreeing to use of global process 120. As described above in regards to FIG. 1, a first access to global process 120 by any of service instances 110 may trigger global process 120 to generate global data set 122. In cases, such as shown, in which a single global process 120 is capable of replacing multiple tasks 115 (e.g., task 115c and 115d) a first call to GP API 225c may generate a portion of global data set 122, while a first call to GP API 225d may generate a second portion of global data set 122. Subsequent calls to either GP APIs 225c or 225d provide access to the respective generated portions.

It is noted that the embodiment of FIG. 2 is merely an example to demonstrate the disclosed concepts. Although three user accounts are shown, any suitable number of user accounts may be supported in other embodiments. As described, in other embodiments, a respective global process may be generated for each of tasks 115c and 115d rather than the single illustrated global process 120. Although tasks 115c and 115d are shown as being replaceable by global process 120, in other embodiments, one or more of tasks 115a, 115b, and 115g may also be replaceable.

The descriptions of FIGS. 1 and 2 disclose generation of a global process from an identified common computation task. Such a global process may be generated in a variety of manners. FIG. 3 shows one such example for generating a global process.

Turning to FIG. 3, an example is shown of a system generating a global process from two identified common computation tasks. System 100 includes examples of task 115c, task 115d, global process 120, and GP API 225 from FIGS. 1 and 2. The examples are illustrated using pseudocode to demonstrate how global process 120 and GP API 225 may be created from the identified common tasks 115c and 115d.

As disclosed above, a computer system may be operable to identify common tasks performed by a plurality of instances of a networked service, and then use the identified tasks to create a global process that is performed in place of the plurality of instances of the common tasks. In FIG. 2, computer system 101 is described as identifying tasks 115c and 115d as being performed by a plurality of service instances 110. As shown in FIG. 3, generating global process 120 includes taking code from tasks 115c and 115d and including similar code in global process 120.

In the illustrated example, task 115c includes operations such as filtering a data set based on provided filter criteria to generate a filtered data set. This filtered data set may then be analyzed to determine an average value and a minimum value. In a similar manner, task 115d includes operations such as filtering the data set based on different filter criteria to generate a different filtered data set. This different filtered data is analyzed to determine an average value and a maximum value.

To generate global process 120, the code from each of tasks 115c and 115d is included in global process 120. As shown, a single performance of global process 120 may generate a data set that includes data that would be generated by respective performances of tasks 115c and 115d. To replace tasks 115c and 115d in a plurality of instances of a networked service, computer system 101 may generate an application interface for global process 120, e.g., GP API 225. GP API 225 is generated to call global process 120. As shown, GP API 225 is written such that a single performance of GP API 225 may cause global process 120 to generate all data in place of tasks 115c and 115d. In other embodiments, GP API 225 may be created in a manner that requires a first call to GP API 225 to generate data corresponding to task 115c and a different call to GP API 225 to generate data corresponding to task 115d.

As illustrated, modifying respective accounts of users (e.g., user accounts 250 in FIG. 2) includes replacing a respective instance of task 115c or task 115d with an instance of GP API 225. In response to the modifying ones of user accounts 250, computer system 101 may be operable to terminate an individual instance of task 115c and/or task 115d associated with an active service instance 110 of the networked service. Referring to FIG. 2, respective instances of task 115c and 115d may be terminated in service instance 110a after user account 250a has been modified to use GP API 225.

It is noted that FIG. 3 is only an example to demonstrate the disclosed concepts. Only elements needed to illustrate these concepts are shown. Pseudocode used in these examples demonstrates a simple example for clarity. Actual tasks performed by other embodiments of a networked service may include more complex operations that may require significant amounts of processor bandwidth.

FIGS. 1-3 describe various techniques identifying and replacing computation tasks used across a plurality of instances of a networked service. FIGS. 4-7 demonstrate four such methods.

Moving now to FIG. 4, a flow diagram for an embodiment of a method for training and operating a retrieval model as part of a semantic search is shown. Method 400 may be performed by a computer system such as computer system 101 in FIGS. 1-2. For example, computer system 101 may include (or have access to) a non-transient, computer-readable memory having program instructions stored thereon that are executable by computer system 101 to cause the operations described with reference to FIG. 4. Method 400 is described below using computer system 101 of FIG. 1 as an example. References to elements in FIG. 1 are included as non-limiting examples.

Method 400 begins at 410 with a computer system identifying usage of a plurality of individual instances of a common computation task by a plurality of users of a networked service. For example, computer system 101 may monitor activity associated with service instances 110 of FIG. 1. During this monitoring, an individual instance of task 115c may be observed to be performed by a respective one of service instances 110. Each instance of task 115c may, when performed, generate a respective one of data sets 118.

At 420, method 400 continues with the computer system creating a global process to perform the common computation task. As shown at time t1 in FIG. 1, computer system 101 may generate global process 120 to perform task 115c. Generation of global process 120 may include copying at least a portion of code from task 115c into global process 120. Once generated, executing global process 120 may generate global data set 122 that includes at least portions of the respective data sets 118.

Method 400 proceeds to 430 with the computer system modifying respective accounts of a subset of the plurality of users to use the global process in place of using a respective instance of the common computation task. A user account associated with a given one of service instances 110 may include indications of which tasks 115 are usable by a user associated with the user account. To enable a particular user to make use of global process 120 in place of task 115c, computer system 101 may modify the particular user's account to indicate that global process 120 is to be used rather than launching an individual instance of task 115c. After one or more user accounts have been modified to use global process 120, when a first service instance 110 associated with one of the modified user accounts calls global process 120, global process 120 may generate global data set 122.

At 440, method 400 further continues with the computer system providing the global data set generated by the global process to the respective accounts of the subset of users. After global data set 122 has been generated, computer system 101 may make global data set 122 accessible to other service instances 110 associated with the other modified user accounts.

It is noted that the method of FIG. 4 includes elements 410-440. Method 400 may end in 440 or may repeat some or all elements of the method. For example, method 400 may repeat, e.g., periodically and/or in response to launch of a new instance of the networked service in order to determine if currently active instances of the networked service are performing individual instances of other tasks that may be replaceable by a global process. In some cases, method 400 may be performed concurrently with other instances of the method. For example, multiple instances of method 400 may be performed concurrently to identify multiple instances of different sets of tasks. One instance of method 400 may look for multiple instances of tasks 115a though 115d while a different instance of method 400 looks for multiple instances of tasks 115e though 115g.

Proceeding now to FIG. 5, a flow diagram for an embodiment of a method for modifying a respective account of a user to use a global process in place of an individual instance is shown. Method 500 may be performed by a computer system such as computer system 101 in FIGS. 1 and 2. In some embodiments, method 500 may be performed as a part of method 400. For example, method 500 may be included as a part of operation 430. Method 500 is described below using computer system 101 of FIG. 2 as an example. References to elements in FIG. 2 are included as non-limiting examples.

Method 500 begins at 510 with a computer system modifying one of the respective accounts of the subset of users while the corresponding user has an active instance of the networked service. Method 400 may begin after operation of 420 of method 400 has been performed, thereby creating a global process (e.g., global process 120) for replacing one or more individual instances of tasks 115. Referring to FIG. 2, a particular user associated with user account 250b has a corresponding active service instance 110b of networked service 205 that was initiated prior to the creating of global process 120. Global process 120 is operable to replace individual instances of task 115c. In response to approval from the particular user, user account 250b is modified to call global process 120 (using GP API 225c) rather than use an individual instance of task 115c.

At 520, method 500 continues by, in response to the modifying of the one respective account, terminating an individual instance of the common computation task associated with the active instance of the networked service. For example, in response to modifying user account 250b to call global process 120 in place of task 115c, a currently active instance of task 115c may be terminated within service instance 110b. In some embodiments, task 115c may be allowed to complete or otherwise reach a stable state before being terminated in order to avoid leaving an orphaned sub-task active. For example, an active instance of task 115c may generate a request to data repository 130 for which there may be a delay before the request is fulfilled. Such a request may be allowed to complete rather than leaving an open request to data repository 130 due to terminating task 115c prior to the fulfilment of the request.

It is noted that the method of FIG. 5 includes elements 510 and 520. Method 500 may end in 520 or may repeat one or both elements of the method. For example, method 500 may repeat for each user account that has approved a replacement of a given task with a call to global process 120. In some cases, method 500 may be performed concurrently with other instances of the method to modify multiple user accounts in parallel.

Moving to FIG. 6, a flow diagram for an embodiment of a method for identifying and replacing a plurality of tasks performed by a plurality of instances of a networked service is shown. Method 600 may be performed by a computer system such as computer system 101 in FIGS. 1-2. In some embodiments, method 600 may be performed as a part of operations 410 and 420 of method 400. Method 600 is described below using elements of FIG. 2 as a non-limiting example.

Method 600 begins at 610 by identifying, by the computer system, a plurality of instances of a set of different common computation tasks performed by the plurality of users. For example, computer system 101 may determine that tasks 115c and 115d of network service 205 have multiple instances used across service instances 110, as shown in FIG. 2. Task 115c is used by all three of service instances 110, while task 115d is used by service instances 110a and 110c. Computer system 101 may make this determination by monitoring log records stored in service logs 240 by service instances 110.

At 620, method 600 continues by creating, by the computer system, respective global processes to perform corresponding ones of the set of different common computation tasks. In some embodiments, such as described above, computer system 101 may be operable to generate a single global process 120 capable of performing operations for both of tasks 115c and 115d. In other embodiments, computer system 101 may be operable to generate independent processes, e.g., global process 120c and global process 120d (not shown), to replace task 115c and task 115d, respectively.

Method 600 proceeds in 630 with requesting, by the computer system, a particular one of the plurality of users to indicate which of the respective global processes are approved for use by the particular user. For example, after global processes 120c and 120d are available, computer system 101 may notify users associated with service instances 110a and 110c that a global process is available for one or more of the tasks 115 that they are utilizing. The user of service instance 110a may agree to using both global processes 120c and 120d, while the user of service instance 110c may agree to using global process 120d, but not to using global process 120c. In some cases, a user may not agree to using any available global process to replace an individual instance of a task. As described above, computer system 101 may be operable to modify respective user accounts for the users of service instances 110a and 110c in order to replace the individual instances tasks 115c and/or 115d with the respective global processes. Such flexibility may encourage user agreement to replace individual instances of common computation tasks with available global processes, thereby increasing processing bandwidth that is available for other tasks.

It is noted that the method of FIG. 6 includes elements 610-630. Method 600 may end in 630 or may repeat some or all elements of the method. For example, method 600 may repeat operation 630 for each service instance that includes one or more of the identified common computation tasks. In some cases, method 600 may be performed concurrently with other methods disclosed herein. For example, one or more instances of method 600 may be performed while an instance of method 500 is performed to terminate an active task that is being replaced by a global process.

Turning to FIG. 7, a flow diagram for an embodiment of a method for generating and user a global data set is depicted. In a similar manner as described for methods 400-600, method 700 may be performed by a computer system, e.g., computer system 101 in FIGS. 1-2, to cause the operations described with reference to FIG. 7. Method 700 is described below using elements of computer system 101 of FIG. 1 as a non-limiting example.

Method 700 begins at 710 at a first point in time with the global process generating the global data set in response to a call from a first instance of the networked service, wherein the first instance is associated with a particular account of a particular user of the subset of users. For example, referring to FIG. 1 at time t1, global process 120 may be triggered in response to a call from service instance 110b. This triggering causes global process to generate global data set 122, from which data set 118b may be extracted and provided to service instance 110b.

At 720, method 700 proceeds after a second point in time, subsequent to the first point in time, with subsequent instances of the networked service accessing the generated global data set. Services instance 110a and 110c, for example, may make calls to global process 120 after global data set 122 has been generated. Rather than performing global process 120 two additional times, the already generated global data set 122 is used to provide data sets 118a and 118c to service instances 110a and 110c, respectively, thereby reducing an overall processing bandwidth needed to generate all three data sets 118 as compared to using respective instances of task 115c to generate each of data sets 118 independently.

It is noted that method 700 of FIG. 7 includes elements 710 and 720. Method 700 may end in 720. In some embodiments, one or both operations of method 700 may be included within method 400, such as within operation 440. Method 700 may repeat some or all elements of the method. For example, method 700 may repeat operation 720 for a plurality of subsequent calls to global process 120. In some embodiments, method 700 may be repeated after a particular amount of time and/or after a particular number of calls to global process 120.

In the descriptions of FIGS. 1-7, various embodiments of a computer system for implementing the disclosed techniques have been disclosed, such as computer system 101 in FIGS. 1 and 2 and or as one or more computer systems for implementing system 100 in FIGS. 1-3. The computer system may be implemented in a variety of manners. FIG. 8 provides an example of a computer system that may correspond to one or more of the disclosed systems.

Referring now to FIG. 8, a block diagram of an example computer system 800 is depicted. Computer system 800 may, in various embodiments, implement one or more disclosed computer systems, such as computer system 101. Computer system 800 includes a processor subsystem 820 that is coupled to a system memory 840 and I/O interfaces(s) 860 via an interconnect 880 (e.g., a system bus). I/O interface(s) 860 is coupled to one or more I/O devices 870. Computer system 800 may be any of various types of devices, including, but not limited to, a server computer system, personal computer system, desktop computer, laptop or notebook computer, mainframe computer system, server computer system operating in a datacenter facility, tablet computer, handheld computer, smartphone, workstation, network computer, connected vehicle, etc. Although a single computer system 800 is shown in FIG. 8 for convenience, computer system 800 may also be implemented as two or more computer systems operating together, e.g., as a virtual computer system.

Processor subsystem 820 may include one or more processor circuits. In various embodiments of computer system 800, multiple instances of processor subsystem 820 may be coupled to interconnect 880. In various embodiments, processor subsystem 820 (or each processor unit within 820) may contain a cache or other form of on-board memory.

System memory 840 is usable to store program instructions executable by processor subsystem 820 to cause computer system 800 perform various operations described herein, including, for example, any of methods 400 to 700. System memory 840 may be implemented using any suitable type of memory circuits including, for example, different physical, non-transitory, computer-readable media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, LPDDR SDRAM, etc.), read-only memory (PROM, EEPROM, etc.), and so on. Memory circuits in computer system 800 are not limited to primary storage such as system memory 840. Rather, computer system 800 may also include other forms of storage such as cache memory in processor subsystem 820 and secondary storage in I/O devices 870 (e.g., a hard drive, storage array, etc.). In some embodiments, these other forms of storage may also store program instructions executable by processor subsystem 820.

I/O interfaces 860 may be any of various types of interfaces configured to couple to and communicate with other devices, according to various embodiments. In one embodiment, I/O interface 860 is a bridge chip (e.g., Southbridge) from a front-side to one or more back-side buses. I/O interfaces 860 may be coupled to one or more I/O devices 870 via one or more corresponding buses or other interfaces. Examples of I/O devices 870 include storage devices (hard drive, optical drive, removable flash drive, storage array, SAN, or their associated controller), network interface devices (e.g., to a local or wide-area network), or other devices (e.g., graphics, user interface devices, etc.). In some embodiments, I/O devices 870 includes a network interface device (e.g., configured to communicate over Wi-Fi®, Bluetooth®, Ethernet, etc.), and computer system 800 is coupled to a network via the network interface device.

The various techniques described herein may be performed by one or more computer programs. The term “program” is to be construed broadly to cover a sequence of instructions in a programming language that a computing device can execute. These programs may be written in any suitable computer language, including lower-level languages such as assembly and higher-level languages such as Python. The program may be written in a compiled language such as C or C++, or an interpreted language such as JavaScript.

Program instructions may be stored on a “computer-readable storage medium” or a “computer-readable medium” in order to facilitate execution of the program instructions by a computer system. Generally speaking, these phrases include any tangible or non-transitory storage or memory medium. The terms “tangible” and “non-transitory” are intended to exclude propagating electromagnetic signals, but not to otherwise limit the type of storage medium. Accordingly, the phrases “computer-readable storage medium” or a “computer-readable medium” are intended to cover types of storage devices that do not necessarily store information permanently (e.g., random access memory (RAM)). The term “non-transitory,” accordingly, is a limitation on the nature of the medium itself (i.e., the medium cannot be a signal) as opposed to a limitation on data storage persistency of the medium (e.g., RAM vs. ROM).

The phrases “computer-readable storage medium” and “computer-readable medium” are intended to refer to both a storage medium within a computer system as well as a removable medium such as a CD-ROM, memory stick, or portable hard drive. The phrases cover any type of volatile memory within a computer system including DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc., as well as non-volatile memory such as magnetic media, e.g., a hard drive, or optical storage. The phrases are explicitly intended to cover the memory of a server that facilitates downloading of program instructions, the memories within any intermediate computer system involved in the download, as well as the memories of all destination computing devices. Still further, the phrases are intended to cover combinations of different types of memories.

In addition, a computer-readable medium or storage medium may be located in a first set of one or more computer systems in which the programs are executed, as well as in a second set of one or more computer systems which connect to the first set over a network. In the latter instance, the second set of computer systems may provide program instructions to the first set of computer systems for execution. In short, the phrases “computer-readable storage medium” and “computer-readable medium” may include two or more media that may reside in different locations, e.g., in different computers that are connected over a network.

Note that in some cases, program instructions may be stored on a storage medium but not enabled to execute in a particular computing environment. For example, a particular computing environment (e.g., a first computer system) may have a parameter set that disables program instructions that are nonetheless resident on a storage medium of the first computer system. The recitation that these stored program instructions are “capable” of being executed is intended to account for and cover this possibility. Stated another way, program instructions stored on a computer-readable medium can be said to “executable” to perform certain functionality, whether or not current software configuration parameters permit such execution. Executability means that when and if the instructions are executed, they perform the functionality in question.

The present disclosure refers to various operations that are performed in the context of instructions executed by one or more computer systems. For example, methods 400-700 are described as, in some embodiments, being performed by computer system 101 as shown in various ones of FIGS. 1-2. In addition, various processes (e.g., global process 120 FIGS. 1-3) are described as being performed by a computer system such as computer system 101). Computer system 101 may include one or more computer systems included, for example, in one or more data centers (physical facilities that store data that drives enterprise computing applications and provides online services to users via, e.g., the Internet). These components, therefore, are implemented on physical structures (i.e., on computer hardware).

In general, any of the services or functionalities of a software development environment described in this disclosure can be performed by a host computing device, which is any computer system that is capable of connecting to a computer network. A given host computing device can be configured according to any known configuration of computer hardware. A typical hardware configuration includes a processor subsystem, memory, and one or more I/O devices coupled via an interconnect. A given host computing device may also be implemented as two or more computer systems operating together.

The processor subsystem of the host computing device may include one or more processor circuits or processing units. In some embodiments of the host computing device, multiple instances of a processor subsystem may be coupled to the system interconnect. The processor subsystem (or each processor unit within a processor subsystem) may contain any of various processor features known in the art, such as a cache, hardware accelerator, etc.

The system memory of the host computing device is usable to store program instructions executable by the processor subsystem to cause the host computing device to perform various operations described herein. The system memory may be implemented using different physical, non-transitory memory media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read-only memory (PROM, EEPROM, etc.), and so on. Memory in the host computing device is not limited to primary storage. Rather, the host computing device may also include other forms of storage such as cache memory in the processor subsystem and secondary storage in the I/O devices (e.g., a hard drive, storage array, etc.). In some embodiments, these other forms of storage may also store program instructions executable by the processor subsystem.

The interconnect of the host computing device may connect the processor subsystem and memory with various I/O devices. One possible I/O interface is a bridge chip (e.g., Southbridge) from a front-side to one or more back-side buses. Examples of I/O devices include storage devices (hard drive, optical drive, removable flash drive, storage array, SAN, or their associated controller), network interface devices (e.g., to a computer network), or other devices (e.g., graphics, user interface devices.

The present disclosure includes references to an “embodiment” or groups of “embodiments” (e.g., “some embodiments” or “various embodiments”). Embodiments are different implementations or instances of the disclosed concepts. References to “an embodiment,” “one embodiment,” “a particular embodiment,” and the like do not necessarily refer to the same embodiment. A large number of possible embodiments are contemplated, including those specifically disclosed, as well as modifications or alternatives that fall within the spirit or scope of the disclosure.

This disclosure may discuss potential advantages that may arise from the disclosed embodiments. Not all implementations of these embodiments will necessarily manifest any or all of the potential advantages. Whether an advantage is realized for a particular implementation depends on many factors, some of which are outside the scope of this disclosure. In fact, there are a number of reasons why an implementation that falls within the scope of the claims might not exhibit some or all of any disclosed advantages. For example, a particular implementation might include other circuitry outside the scope of the disclosure that, in conjunction with one of the disclosed embodiments, negates or diminishes one or more of the disclosed advantages. Furthermore, suboptimal design execution of a particular implementation (e.g., implementation techniques or tools) could also negate or diminish disclosed advantages. Even assuming a skilled implementation, realization of advantages may still depend upon other factors such as the environmental circumstances in which the implementation is deployed. For example, inputs supplied to a particular implementation may prevent one or more problems addressed in this disclosure from arising on a particular occasion, with the result that the benefit of its solution may not be realized. Given the existence of possible factors external to this disclosure, it is expressly intended that any potential advantages described herein are not to be construed as claim limitations that must be met to demonstrate infringement. Rather, identification of such potential advantages is intended to illustrate the type(s) of improvement available to designers having the benefit of this disclosure. That such advantages are described permissively (e.g., stating that a particular advantage “may arise”) is not intended to convey doubt about whether such advantages can in fact be realized, but rather to recognize the technical reality that realization of such advantages often depends on additional factors.

Unless stated otherwise, embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of claims that are drafted based on this disclosure, even where only a single example is described with respect to a particular feature. The disclosed embodiments are intended to be illustrative rather than restrictive, absent any statements in the disclosure to the contrary. The application is thus intended to permit claims covering disclosed embodiments, as well as such alternatives, modifications, and equivalents that would be apparent to a person skilled in the art having the benefit of this disclosure.

For example, features in this application may be combined in any suitable manner. Accordingly, new claims may be formulated during prosecution of this application (or an application claiming priority thereto) to any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined with those of other dependent claims where appropriate, including claims that depend from other independent claims. Similarly, features from respective independent claims may be combined where appropriate.