Skip navigation.
Downloads | Product Documentation | Support

Concepts Guide

# Performance and Caching

This chapter describes Data Services Platform (DSP) performance features. It covers these topics:

- Overview
- Query Optimization
- Caching

# Overview

Poor performance can outweigh many of the advantages that an otherwise carefully designed data services deployment provides. From a data user's perspective, response times of the data access layer should be close to that of native data access mechanisms.

DSP includes a number of configurable settings and features for ensuring good performance, as well as numerous internal features. With caching, data response times actually improves upon those provided by native access mechanisms.

# Query Optimization

The data integration language behind data service functions is the XQuery language. As a declarative language, XQuery affords many opportunities for optimization. In general terms, a declarative language focuses on what needs to be done, not on how things are to be done (as is the case for an imperative language). As such, the Data Services Platform engine is free to choose the most effective way to execute a given query, not only for the best performance of the data services layer but also to minimize the burden on the data sources as well.

Among the types of query optimization DSP performs include:

- When possible, DSP pushes predicate evaluation, join operations, aggregates, and other data manipulation functions from XQuery to the underlying SQL databases to minimize the number of database calls required and reduce the volume of data returned from those calls.
- DSP handles layered data services by a process called view unfolding. Instead of retrieving the full data set encompassed by a multi-level function call, DSP retrieves only the data relevant to the actual request.
- DSP combines multiple "trips" to the same database implied by a function into a single access when sensible.

You can view how the engine has compiled a query using the plan view.

# Caching

Caching improves the responsiveness of the client application and minimizes the burden on back-end resources. With caching, DSP stores the results returned from a data service function locally. When a function call is made again with the same parameters, DSP can respond with the cached copy of the data, thereby avoiding repeated calls to the back-end data sources.

Caching with DSP can be managed at a highly granular level. You can enable or disable caching and set the time-to-live on a per function basis. This allows you to apply caching policies as best suited for the type of information. If the information is apt to be long standing without change, the cache can expire that data less frequently. If information changes frequently, you can have the cache expire it frequently as well.

You can manage the cache, for example, by setting time-to-live values and purging the cache through the Data Services Platform Console.

If a client application wants to be sure that it acquires the latest information, it can ignore any cached data and use the GET_CURRENT_DATA attribute to retrieve information directly from the data source. This operation also automatically updates the function cache, if any.

For information about caching see Configuring the Results Query Cache in the Data Services Platform Administration Guide.