Computer programming refers to the process of producing computer programs or applications. Computer programs are groups of instructions specified in one or more programming languages that describe actions to be performed by a computer or other processor-based device. When a computer program is loaded and executed on computer hardware, the computer will behave in a predetermined manner by following the instructions of the computer program. Accordingly, the computer becomes a specialized machine that performs the tasks prescribed by the instructions.
Several technologies exist to optimize programs as a function of the scenario in which they are used. Most of these performance optimizations involve dynamic and sometimes static analysis of the program to determine which blocks of code are utilized most often. A compiler then consumes this tracing data and produces a new version of the program where the most popular blocks are emitted in a way that these blocks will be loaded/executed in a faster way at runtime. Even though these techniques have proven very useful in the past, they have several downsides. First, only certain scenarios are optimized while other might suffer performance degradation. Additionally, since dynamic analysis uses tests that execute certain scenarios in the code, these tests have to be carefully written and selected to ensure the proper scenarios are optimized. Thirdly, writing these tests and selecting scenarios to optimize can be a huge cost, and writing the tooling for such analysis is also expensive.
Increasingly, computer programming or coding is shifting away from single devices and toward distributed systems. Client/server architectures of the past have reemerged as a dominant computing paradigm thanks to advances in network communication as well advent of the Internet. Moreover, development is moving toward software as a service. Here, applications are designed as network accessible services. Service consumers reside on a client and communicate with server providers over communication networks such as the Internet.
The World Web (simply the Web) is based on a distributed architecture. The Web is a system of interlinked documents accessible over the Internet. Client devices include Web browsers that facilitate presentation of web pages including text, images, sound, video, and/or programs. More specifically, a web browser connects to a web server at a particular address over the Internet and requests a web page and/or associated content designated at that address. In response, the web browser transmits the entire web page and/or related content to the browser for subsequent presentation and/or execution. Conventionally, web browsing can be optimized by caching content on the client side. For example, after retrieving a web page, the entire page can be cached such that if needed again the page can be quickly acquired from cache memory rather than the longer process of requesting and receiving the page over the Internet.
The following presents a simplified summary in order to provide a basic understanding of some aspects of the disclosed subject matter. This summary is not an extensive overview. It is not intended to identify key/critical elements or to delineate the scope of the claimed subject matter. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
Briefly described, the subject disclosure pertains pre-fetching in a distributed computer environment. In accordance with one aspect of the disclosure, rather than downloading all content (e.g., code, data . . . ) associated with a distributed application from a server at once, portions of content can be downloaded or otherwise acquired by a client in a piecemeal manner on an as needed basis. To mitigate delay associated with cross network or communication framework retrieval, content likely to be needed in the near future can be pre-fetched and pushed to a client according to another aspect of the disclosure. As a result, client side application processing is optimized or at least improved.
To the accomplishment of the foregoing and related ends, certain illustrative aspects of the claimed subject matter are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways in which the subject matter may be practiced, all of which are intended to be within the scope of the claimed subject matter. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.
Systems and methods are described hereinafter relating to pre-fetching in a distributed computer environment. Rather than requiring all content to be transmitted to a client for execution at once, portions of the content can be judiciously transmitted. This improves client side processing speed since it does not need to wait for a large quantity of data to be transmitted prior to beginning execution especially where some content is unlikely to be utilized. Furthermore, content can be automatically pre-fetched and pushed to a client by a server such that needed content is readily available without communication framework interaction.
Various aspects of the subject disclosure are now described with reference to the annexed drawings, wherein like numerals refer to like or corresponding elements throughout. It should be understood, however, that the drawings and detailed description relating thereto are not intended to limit the claimed subject matter to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the claimed subject matter.
Referring initially to
Interaction between the client application component 110 and the server application component 120 can be iterative in nature. In other words, instead of transmitting all content portions, blocks or chunks of content are requested and delivered as needed. As a result, load time is reduced thereby enabling the client application component 120 to begin processing content earlier. This is beneficial from an overhead standpoint because all content including that which may be unlikely to be utilized need not be downloaded at once. The down side is that some slow down can occur when content is first loaded. However, the pre-fetch component 130 addresses this issue.
The pre-fetch component 130 provides content likely to be needed in the near future via the server application component 120 or directly. The mechanism determines or infers content likely to be needed automatically utilizing affinity matrices, statistical analysis, machine learning, and/or administrative configuration, among other things. In operation, if a client application component 110 requests content, that content as well as additional content that may be need for future processing is provided in response. Suppose, for example, it is known or it can be determined that “X” and “Y” are related. If the client requests “X,” then the pre-fetch component 130 can identify “Y” and both “X” and “Y” can be pushed to the client. This can also be recursive such that if “Z” is related to “Y,” then “X,” “Y,” and “Z.” can be provided in response to a request for “X.” However, the extent of pre-fetching can be limited explicitly, by space limitations or time constraints, among other things. It should also be noted that a byproduct of piecemeal interaction in combination with pre-fetching is reduced network traffic, which can improve transmission speed and thus client server interaction.
The system 200 also includes content identification component 230 communicatively coupled to the monitor component 220 and structure component 210. The content identification component 230 is a mechanism for identifying content to be pushed to a user, for example in addition to requested content. Information from the monitor component 220 and structure component 210 aid identification by affording potential usage paths and relative content as a function of current application execution state. Identification of a particular path and content can be determined utilizing statistical, machine learning, and/or administrative configuration, among other things. For example, it can be determined, inferred, or otherwise known that one path is more likely than another. As a result, if confronted with a choice, the content identification path component 230 can select the most likely path and content associated with that path.
Additionally, system 100 can also include context component 240 coupled to the content identification component 230 and optionally the monitor component 220. The context component 240 receives, retrieves, or otherwise acquires or obtains contextual information, for example regarding a client, user, historical usage, etc. Such information can be provided or made available to the content identification component 230 to aid identification of relevant content. Further, context information can be provided or made available to the monitor component 220 to influence the range of information that is relevant to pre-fetching given a current state.
Referring to
The client component 410 acquires and/or produces data pertaining to a client device. For example, it can determine whether a device is a thin client with limited processing power or fat client with more resources. Furthermore, the client component might identify specific computational resources available or not available (e.g., processor, processor power, memory, software . . . ). Still further yet, current or substantially real-time information can be acquired relating to load, resource allocation, and/or resource utilization, among other things.
The network component 420 affords context information related to a communication path between a client and the server. It can provide information regarding network bandwidth and latency. Further, the network component 410 can identify and optionally acquire information related to a network address such as an Internet protocol (IP) address. This could assist in identifying other information such as geographical information of a client and/or server, among, inter alia.
User demographic information can be obtained or acquired utilizing user component 430. In this case, information about a user such as age, gender, race, ethnicity, religion, group affiliation, and/or educational level, etc. can be afforded by the system. This information can be supplied explicitly by users and/or inferred as a function of other information provided or not provided.
The history component 440 tracks historical usage data. In one instance, web browser history can be stored and utilized to aid pre-fetching operations. Furthermore, historical client/server application interaction can be a useful source of information. Applications include a plethora of execution paths, not all of which are utilized by every user. By tracking usage, some paths can be eliminated as unlikely thereby improving the odds that an identified path and associated content will be utilized.
The third party component 450 acquires information pertaining to application interaction by others. As a distributed application, many users can interact with instances of the application. Their interaction can be monitored and utilized for improving pre-fetch operation. For example, if a particular path and associated content are more popular than others with a majority of application users, this can factor in its selection for pre-fetching. Similarly, if a path and content are rarely employed, this can negatively impact the chances of it being pre-fetched.
The interface component 110 can also optionally include an observation component 520. While information can be collected and utilized to affect pre-fetching on the server side, the client side application component 110 can also assist in this process. The observation component 520 can collect information or metadata surrounding client side application and provide it to the client side application component 120 and/or pre-fetching component 130 (
Turning to
The system 600 can also include a user interface component 610 communicatively coupled to the pre-fetch component 130. The user interface component 610 provides a mechanism to allow users such as administrators to customize or fine-tune pre-fetching. This enables users to specify pre-fetching algorithms or otherwise control operation thereof. For example, an administrator may tweak the importance of various axes utilized to decide which content to push. These decisions can be made after a set of reports is provided on the effectiveness of pre-fetching.
The pre-fetch component can also include an optimization component 620 to enable automatic fine-tuning of pre-fetching as a function of performance for instance. More specifically, the optimization component 620 can measure the effectiveness of pre-fetching and use this information to update the pre-fetching process for future application runs. In one particular embodiment, the optimization component 620 can choose to instrument a client or content acquired by the client to measure effectiveness.
It is to be noted as well as appreciated that the aforementioned pre-fetching mechanisms can be configured for different client server applications and/or content types. In accordance with one embodiment, the mechanism can apply to programmatic code executing on a client that might need to be optimized. Every time a client needs to run a piece of code that it has not yet loaded, it can request this code from a server. The server can then utilized knowledge that it has built up concerning the program over time, for example based on requests and runs from the same or other clients, to send one or more pieces of code to the client. As it is allowed to send multiple pieces of code at once, it can use this mechanism to push code to the client that the server expects the client will need in the near future thus removing the load time when an event occurs, for example. In one particular instance, the client can be an application running in a browser and the server is a web service running on a server. It should also be noted that client and server could be on the same machine (e.g., different application domains, processes . . . ) or a far apart as the other side of the world. Further, the processing units can be of any unite size including but not limited to instruction, method, type, block, and assembly, among others.
For purposes of clarity and understanding, consider programmatic code that utilizes type as the iterative unit. Every time a client needs to use a type the client has not received in that instance of the program, the client asks the server for this type. The client should expect to receive that type as required and a number of extra types. Accordingly, the server can decide when the client should receive which type. Consider further the following C# application that may be converted to JavaScript and executed on the client:
public class Foo
When this program is run for the first time, it can be executed without any optimization. The server receives a request for each type when it is first used and sends only one type to the client at a time. Every time it receives a request, it will store this information in some data repository. The next time the program is run; the server already has knowledge about this program and can serve up the code in a smarter way. For example, it can decide that whenever the user requests the “Window” type, to also send the “Tester” type, as it knows from previous experience that the two are needed almost instantaneously.
The server could use one or more algorithms to decide which types to send together including but not limited to some form of affinity matrix, machine learning, statistical analysis, and/or administrator configured grouping of type. The server can use several axes to make decisions on including: which machine is executing the client; which user is executing the client; which browser is executing the client; the response time of communication between server and client; download throughput between client and server; performance of the client; library code sent, and/or which application is using the library, among others. Of course, combinations are also possible.
In accordance with another particular embodiment relating to code, it is to be appreciated that client side code can be optimized by not downloading error handling until needed. Error handling comprises a large portion of programmatic code and it is typically invoked infrequently in comparison to other code. Accordingly, a client/server application can be instructed to only download error handling as needed. Further, pre-fetching can be configured to ignore error-handling branches unless actually invoked in which case units of error handing code can be pre-fetched to expedite processing of errors.
Turning to
The pre-fetch component 130 can receive, retrieve, or otherwise obtain information about an application from the tier splitting component 720 or other compilation component(s). Since an application is first developed as a single tier application and later split and deployed on a client and server, for instance, the pre-fetch component 130 can obtain global application knowledge. Intimate knowledge can be obtained about the entire application (e.g., instructions, blocks, types, method boundaries, exception handling envelopes, continuations . . . ), which is useful in generating a use structure, among other things.
It is to be appreciated the mechanisms described herein are not limited to the case in which content programmatic code. Other embodiments are also possible including, without limitation, multimedia, games, and the like. For example, suppose one is streaming music and it is known or can be determined that a user has particular preferences or play list algorithm for moving to the next song. The server and client could utilize this knowledge to stream music in a piecemeal fashion utilizing pre-fetching to eliminate delays.
In another instance, consider an online gaming environment. The server could collect data on play patterns of users. Not every user utilizes every action of feature of a game. In fact, only a limited number actually do. Accordingly, a play pattern can identify an affinity for particular actions in particular situations. For example, in an American football game one user may almost always pass the ball rather than run. In this case, only plays relevant to the passing game need be resident on a client. The running game can be streamed if and when needed.
In yet another instance, consider a travel web site that assists in booking flights, hotels, and rental cars. The system can learn that every time an individual books a flight they also book both a hotel and a rental car. After a flight-booking module is downloaded, chunks associated with hotels and cars can be downloaded in the background while the individual is filling out flight information. Accordingly, there is no waiting when the individual moves on to the hotel and car rental portions. The pre-fetched portions include not just code but data. For example, images associated with hotels and cars can be downloaded. This can be further optimized by considering the individual's destination from the flight portion as well as hotel and car preferences, among other things.
The aforementioned systems, architectures, and the like have been described with respect to interaction between several components. It should be appreciated that such systems and components can include those components or sub-components specified therein, some of the specified components or sub-components, and/or additional components. Sub-components could also be implemented as components communicatively coupled to other components rather than included within parent components. Further yet, one or more components and/or sub-components may be combined into a single component to provide aggregate functionality. Communication between systems, components and/or sub-components can be accomplished in accordance with either a push and/or pull model. The components may also interact with one or more other components not specifically described herein for the sake of brevity, but known by those of skill in the art.
Furthermore, as will be appreciated, various portions of the disclosed systems above and methods below can include or consist of artificial intelligence, machine learning, or knowledge or rule based components, sub-components, processes, means, methodologies, or mechanisms (e.g., support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines, classifiers . . . ). Such components, inter alia, can automate certain mechanisms or processes performed thereby to make portions of the systems and methods more adaptive as well as efficient and intelligent. By way of example and not limitation, the pre-fetch component 130 can employ such mechanism to facilitate identification of content to be pushed to a client, for instance.
In view of the exemplary systems described supra, methodologies that may be implemented in accordance with the disclosed subject matter will be better appreciated with reference to the flow charts of
Referring to
At numeral 920, context information collected through client side observation can be provided to the server to aid client/server interaction. For example, the context information can relate to application processing including performance statistics, dwell time, and the like. However, context is not limited thereto. Any set of facts or circumstances surrounding distributed computation are fair game including without limitation information pertaining to a client device, user, and/or communication network.
At reference 930, requested and additional content is received from the server. The additional content is content that the client may need in the near future. Instead of pushing solely requested content, the server can be proactive and push additional content likely to be needed to mitigate delay associated with later retrieval thereof. As a result, a client should be able to accept this additional content when provided. Furthermore, prior to requesting content the client should check client side memory or storage for the data since it might already be local, thereby eliminating the need to retrieve it externally.
Turning attention to
As used herein, the terms “component,” “system” and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an instance, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computer and the computer can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. It is to be noted that services, tests, or test consumers can be components as defined herein.
The word “exemplary” or various forms thereof are used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Furthermore, examples are provided solely for purposes of clarity and understanding and are not meant to limit or restrict the claimed subject matter or relevant portions of this disclosure in any manner. It is to be appreciated that a myriad of additional or alternate examples of varying scope could have been presented, but have been omitted for purposes of brevity.
As used herein, the term “inference” or “infer” refers generally to the process of reasoning about or inferring states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic—that is, the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources. Various classification schemes and/or systems (e.g., support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines . . . ) can be employed in connection with performing automatic and/or inferred action in connection with the subject innovation.
Furthermore, all or portions of the subject innovation may be implemented as a method, apparatus or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed innovation. The term “article of manufacture” as used herein is intended to encompass a computer program accessible from any computer-readable device or media. For example, computer readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips . . . ), optical disks (e.g., compact disk (CD), digital versatile disk (DVD) . . . ), smart cards, and flash memory devices (e.g., card, stick, key drive . . . ). Additionally it should be appreciated that a carrier wave can be employed to carry computer-readable electronic data such as those used in transmitting and receiving electronic mail or in accessing a network such as the Internet or a local area network (LAN). Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.
In order to provide a context for the various aspects of the disclosed subject matter,
With reference to
The system memory 1116 includes volatile and nonvolatile memory. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 1112, such as during start-up, is stored in nonvolatile memory. By way of illustration, and not limitation, nonvolatile memory can include read only memory (ROM). Volatile memory includes random access memory (RAM), which can act as external cache memory to facilitate processing.
Computer 1112 also includes removable/non-removable, volatile/non-volatile computer storage media.
The computer 1112 also includes one or more interface components 1126 that are communicatively coupled to the bus 1118 and facilitate interaction with the computer 1112. By way of example, the interface component 1126 can be a port (e.g., serial, parallel, PCMCIA, USB, FireWire . . . ) or an interface card (e.g., sound, video, network . . . ) or the like. The interface component 1126 can receive input and provide output (wired or wirelessly). For instance, input can be received from devices including but not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, camera, other computer and the like. Output can also be supplied by the computer 1112 to output device(s) via interface component 1126. Output devices can include displays (e.g., CRT, LCD, plasma . . . ), speakers, printers and other computers, among other things.
The system 1200 includes a communication framework 1250 that can be employed to facilitate communications between the client(s) 1210 and the server(s) 1230. The client(s) 1210 are operatively connected to one or more client data store(s) 1260 that can be employed to store information local to the client(s) 1210. Similarly, the server(s) 1230 are operatively connected to one or more server data store(s) 1240 that can be employed to store information local to the servers 1230.
Client/server interactions can be utilized with respect with respect to various aspects of the claimed subject matter. In fact, client/server interactions provide a foundation for many aspects. More particularly, processing can be split across client(s) 1210 and server(s) 1230 communicatively coupled by communication framework 1250. Units of content can be transmitted from the server(s) 1230 to client(s) 1210 as needed. Furthermore, to mitigate delay some content can be pre-fetched by server(s) 1230 and pushed to client(s) 1210.
What has been described above includes examples of aspects of the claimed subject matter. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the claimed subject matter, but one of ordinary skill in the art may recognize that many further combinations and permutations of the disclosed subject matter are possible. Accordingly, the disclosed subject matter is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the terms “includes,” “contains,” “has,” “having” or variations in form thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.