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.

DSP includes a number of configurable settings and internal features to facilitate good performance. With caching, data response times can actually improves upon those provided by native access mechanisms.

# Query Optimization

As a declarative language, XQuery also 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.

The types of query optimization DSP performs include:

- When possible, DSP pushes predicate evaluation, joins, aggregation, and other data manipulation functions to the underlying SQL databases. This minimizes the number of database calls required and reduces the volume of data returned from those calls.
- DSP handles layered data services using 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 in a local relational database. 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 suits the type of information. If the information is apt to be long-standing without change, the cache can hold that data longer. If information changes frequently, you can have the cache expire as frequently as appropriate.

You can manage the cache 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 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.