Patent Application
20180336253
Conventional systems attempt to improve application performance by improving the efficiency with which content is generated, improving the efficiency with which the generated content is acquired and/or improving the efficiency with which acquired content is rendered on a display. Each of these efficiencies effect not only the performance of an application but also a user's perception of the application's performance. Since user satisfaction is attributable in large part to this perceived performance, other techniques for improving perceived application performance are desired.
The following description is provided to enable any person in the art to make and use the described embodiments. Various modifications, however, will remain readily apparent to those in the art.
Generally, some embodiments improve the perceived performance of a data-rendering application. According to some embodiments, and in response to a request for a data visualization, a local cached copy of the data visualization is initially rendered while active data is contemporaneously fetched in the background. The fetched active data is rendered in a hidden mode. Once fetching and rendering of the active data is complete, the rendered cached data is swapped out for the hidden rendered data. Because a data visualization (i.e., the cached copy) is rendered before the active data is fetched, a user perceives improved performance as compared to systems which render a requested chart only after the active data of the requested chart is received.
According to some embodiments, client 140 executes a Web browser to present a user interface to a user on a display of client 140. The user enters a query into the user interface, and client 140 passes a request based on the query to server 130. Server 130 generates an SQL script based on the request, and forwards the SQL script to DBMS 120. DBMS 120 executes the SQL script to return a result set to server 130 based on data of data store 110, data visualization application 132 generates a data visualization based on the result set, and the client 140 renders the data visualization. According to some embodiments, client 140 receives the result set and generates and renders a data visualization based thereon.
Data store 110 may comprise any data sources which are or become known, including but not limited to database views, spreadsheets, relational databases and/or OnLine Analytical Processing cubes. Data store 110 may also comprise any query-responsive data source or sources that are or become known, including but not limited to a structured-query language (SQL) relational database management system. Data store 110 may comprise a relational database, a multi-dimensional database, an eXtendable Markup Language (XML) document, or any other data storage system storing structured and/or unstructured data. The data of data store 110 may be distributed among several relational databases, dimensional databases, and/or other data sources. Embodiments are not limited to any number or types of data sources.
In some embodiments, the data of data store 110 may comprise one or more of conventional tabular data, row-based data, column-based data, and object-based data. Moreover, the data may be indexed and/or selectively replicated in an index to allow fast searching and retrieval thereof. Data store 110 may support multi-tenancy to separately support multiple unrelated clients by providing multiple logical database systems which are programmatically isolated from one another.
Data store 110 may implement an “in-memory” database, in which a full database stored in volatile (e.g., non-disk-based) memory (e.g., Random Access Memory). The full database may be persisted in and/or backed up to fixed disks (not shown). Embodiments are not limited to an in-memory implementation. For example, data may be stored in Random Access Memory (e.g., cache memory for storing recently-used data) and one or more fixed disks (e.g., persistent memory for storing their respective portions of the full database).
System 100 may be located on-premise according to some embodiments. According to other embodiments, server 130, DBMS 120 and data store 110 are located off-site (e.g., in the Cloud) and are accessed via client 140 over Web protocols.
Initially, at S210, a request to display a visualization is received. The request may be received from a user operating a user interface presented by a Web browser executing on a client system (e.g., a desktop computer, a tablet computer, a mobile phone). More particularly, the user interface may be presented as a result of execution of a Web application by an execution engine of a Web browser. For example, the request may comprise a request for a chart of sales data for several geographical regions over a certain time period.
In response to the received request, a cached version of the visualization is rendered and displayed at S220.
Returning to process 200, an “active” version of the data visualization is requested at S230. In some embodiments, the active version of the visualization is based on data stored in visualization source 310. Accordingly, application 332 may request the data visualization from visualization source 310 at S230. Visualization source 310 may comprise a database platform such as server 130 and data store 110 of
The active version may comprise current data associated with the visualization. The data may include sales figures and/or other measures that are known. The active version may comprise a description of a visualization incorporating such current data, for example, a JavaScript Object Notation file.
At S240, the active visualization is received and rendered in a hidden mode. For example, the active visualization may be rendered but not yet displayed as will be described below.
S230 and S240 may occur contemporaneously with S220 according to some embodiments. For example, a main thread of application 332 may render and display the cached version while a worker thread requests the active visualization at S230 and receives and renders the active visualization at S240.
Finally, at S250, the rendered active visualization is displayed in place of the displayed cached version.
According to some embodiments, hovering a cursor over a displayed cached version (e.g., visualization 345) may result in display of a “loading” indicator icon, while hovering over a displayed active version (e.g., visualization 350) may result in display of a tooltip associated with the marks in the visualization. In some embodiments, the data of the active visualization (i.e., the data stored in visualization source 310 at the time of the request for the active visualization) may be identical to the data represented in the cached version, therefore the active visualization and the cached version are identical and the replacement at S250 may be imperceptible.
Process 500 concerns the presentation of a “story” consisting of one or more data visualizations, or charts. Upon system start (e.g., initialization of data visualization application 135) at S505, all charts persisted in a central data store (e.g., visualization source 310) are synchronized to a client persistence (e.g., volatile memory, cache 334) located on a client system. The charts may be persisted in a serialized format (e.g., JSON) which represents a graphic view of a chart, including its constituent data.
A command to load a story is received at S510, and it is determined at S515 whether all charts have been loaded, or rendered with current active data. For each chart in the story, it is determined at S520 whether the chart is cached (i.e., stored locally on the client system) and, if so, the cached chart is rendered while contemporaneously fetching and rendering the corresponding active chart as described above. For example, the chart is deserialized at S525 (e.g., to Scalable Vector Graphics Document Object Model (SVG DOM)) and rendered at S530. The SVG ViewBox attribute may be used to support fluid resizing of the displayed cached visualization relative to the size of the container.
After rendering the chart, active data for the chart is fetched from the data store at S535. The data may be fetched by a worker thread at S535, while the cached chart is being rendered by a main thread at S530. Once the data is received, the current, or active, chart is rendered at S540 (e.g., by the main thread) and an indication (e.g., a “rendering complete” event) is provided at S545. The current chart is serialized at S550 and stored in the client persistence, for example by overwriting the prior cached version of the chart, if any.
Flow returns to S515 to determine whether all charts are loaded. If not, flow continues to S520 with respect to a next chart in the story and flow proceeds as described above. Accordingly, flow cycles between S515 through S545 as described above until each chart in the story is rendered with active data.
Once it is determined at S515 that all charts of the story have been loaded, an indication is provided at S555 that rendering of the page is complete. The indication may comprise firing of a “page complete” event according to some embodiments. Next, at S560, the cache is synchronized from the client persistence to the data store. Synchronization may comprise overwriting older serialized versions of one or more of the charts stored in the data store with current up-to-date serialized versions which were created during process 500 as described above. Accordingly, at a next initialization of the same or another client system, the newer versions will be synchronized to the corresponding client persistence at S505.
For performance reasons, storage of cached data does not operate directly against the local Client Persistence in some embodiments. Instead, an intermediate in-memory (e.g., volatile memory) or Transient Store is used to capture data to be cached. Writing back to the Client Persistence occurs when there is minimal activity on the main thread, or when performance is less critical. Similarly, synchronization may be performed between the Client Persistence and the Transient Store soon after container load to minimize contention on the main thread. These activities are abstracted out to a Storage Manager. The design of the Storage Manager is intended to work against any arbitrary store types as long as the stores implement a pre-defined Application Programming Interface.
Operations against persistent stores are typically asynchronous, and many Create, Read, Update and Delete (CRUD) operations being performed on container load may lead to interleaving between other container load-related operations. Operations against the Client Persistence may therefore be delegated to web worker threads to alleviate contention on the main thread. A generic Worker Manager service is introduced to spawn workers to handle arbitrary pieces of work as well as automatically manage worker state. The Worker Manager service is intended as a centralized service for all worker thread activities and helps to control application impact on user device resources, remove maintenance of multiple worker manager implementations, and de-couple worker logic from worker management logic.
The stores described herein may implement a cache eviction strategy to evict stale or undesirable visualization entries. The cache eviction strategy may be evaluated in the following order: Max Age, Max entries, Max size. Max Age corresponds to the last modified time of the entry, and may be evaluated first to ensure all entries that are deemed too old are removed as a highest priority. The maximum number of entries ordered by last access time, or Max entries, is evaluated next as a low-cost mean way of eliminating excess entries. Ordering by last access time prioritizes entries the user has read from most recently, assuming the entry has not already expired, which should be handled by the preceeding Max age eviction. The Max size of all entries in aggregate, ordered by last access time, is then evaluated.
Cache loading or eviction may be performed during application load or upon completing a story rendering. For example, at application load, a key may be fetched from the persistent Key Store, and the entry will be pruned in-memory as it is read from the Client Persistence. During a synchronization from Client Persistence t to Transient Store, entries will be pruned in-memory as they are read from the Client Persistence. After receiving an indication that rendering of a story page is complete, all entries in the Transient Store will be persisted (regardless of whether they have expired between application load and the page render complete indication), the Client Persistence is pruned, and the Key Store is pruned.
To facilitate efficient retrieval and reading of data for cache eviction, the Client Persistence may be indexed by created/accessed/modified time and size. In order for the stores created in the Client Persistence to be granular per story (e.g., to prevent read/write of all cached data of the application when only the data for one story is needed), one store per story may be created. Metadata for each store may be tracked in a master/lookup store, which can then be used for store management, including metadata such as last accessed/modified/created time and size in bytes.
As part of persistent caching/storage, it may beneficial to ensure space usage from different caches does not become too large. The Transient Store size may be determined by settings, and the Client Persistence may track usage via a master lookup store.
Encryption/decryption may be performed when reading and writing to and from the Client Persistence (not to/from the Transient Store). Accordingly, encryption/decryption can also be pushed into the worker thread.
Keys may be stored client-side using an indexed database in a separate store from the cached data. This storage uses the ability of the client to keep keys 100% opaque and reduces complexity in the design (e.g., server-client key synchronization, etc.). Keys may expire after some small amount of time (e.g., a few days), and be rotated.
Apparatus 700 includes processor(s) 710 operatively coupled to communication device 720, data storage device 730, one or more input devices 740, one or more output devices 750 and memory 760. Communication device 720 may facilitate communication with external devices, such as a reporting client, or a data storage device. Input device(s) 740 may comprise, for example, a keyboard, a keypad, a mouse or other pointing device, a microphone, knob or a switch, an infra-red (IR) port, a docking station, and/or a touch screen. Input device(s) 740 may be used, for example, to enter information into apparatus 700. Output device(s) 750 may comprise, for example, a display (e.g., a display screen) a speaker, and/or a printer.
Data storage device 730 may comprise any appropriate persistent storage device, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices, Read Only Memory (ROM) devices, etc., while memory 760 may comprise Random Access Memory (RAM), Storage Class Memory (SCM) or any other fast-access memory.
Browser 732 may comprise program code executed by processor 710 to cause apparatus 700 to perform any one or more of the processes described herein. Embodiments are not limited to execution of these processes by a single apparatus.
Cached visualizations 734 may also be stored in volatile memory such as memory 760 during operation as described above. Data storage device 730 may also store data and other program code for providing additional functionality and/or which are necessary for operation of apparatus 700, such as device drivers, operating system files, etc.
The foregoing diagrams represent logical architectures for describing processes according to some embodiments, and actual implementations may include more or different components arranged in other manners. Other topologies may be used in conjunction with other embodiments. Moreover, each component or device described herein may be implemented by any number of devices in communication via any number of other public and/or private networks. Two or more of such computing devices may be located remote from one another and may communicate with one another via any known manner of network(s) and/or a dedicated connection. Each component or device may comprise any number of hardware and/or software elements suitable to provide the functions described herein as well as any other functions. For example, any computing device used in an implementation of a system according to some embodiments may include a processor to execute program code such that the computing device operates as described herein.
All systems and processes discussed herein may be embodied in program code stored on one or more non-transitory computer-readable media. Such media may include, for example, a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, magnetic tape, and solid state Random Access Memory (RAM) or Read Only Memory (ROM) storage units. Embodiments are therefore not limited to any specific combination of hardware and software.
Embodiments described herein are solely for the purpose of illustration. Those in the art will recognize other embodiments may be practiced with modifications and alterations to that described above.
This application is related to, and claims benefit of and priority to, U.S. Provisional Patent Application No. 62/506,739, filed May 16, 2017, the contents of which are hereby incorporated by reference in their entirety for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 62506739 | May 2017 | US |
