Share via

Managing Application Resources

  • Article

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

Use the manifest file to improve application performance on Speech Server by preloading and caching application resources.

Resource Caching

When a new project is created, the Voice Response Web Application Project Wizard creates the Manifest.xml file. Speech Server, more specifically Speech Engine Services (SES), reads this file to identify application resources to preload and cache. Preloading application resources improves performance and user experience. For more information, see About Application Manifest Files.

The SES cache uses standard HTTP 1.1 cache control mechanisms as defined in RFC 2616, sections 13 and 14.

In accordance with the standard, the caching of individual resources is controlled by a freshness lifetime, determined at the time the resource is downloaded. The freshness lifetime is based on two factors:

  • Cache control headers, if present
  • A heuristic, if no explicit expiration time is provided

The SES heuristic sets the freshness lifetime to 10 percent of the resource age. The resource age is the difference between the download time and the last-modified time. The maximum freshness lifetime is one day. The minimum freshness lifetime is one minute.

When the freshness lifetime expires, resources are considered stale. They are still cached, but their validity (determined by whether they are updated) is checked on the next access, using standard HTTP if-modified-since rules. A new freshness lifetime is determined, and they are updated if needed.

Note

SES does not provide an if-none-match header when checking resource validity. The Web server determines whether a resource has changed based on the if-modified-since header and the file modification time, rather than the ETag of that resource. For information about ETags, see the section describing Header Field Definitions in RFC 2616.

Cacheable Resources

Use HTTP headers to set the appropriate expiration time for cacheable resources that have specific expiration dates. For large resources, specify an expiration date so far in the future that these resources can only be updated manually:

  • For dynamically generated resources, use the HttpCachePolicy.SetMaxAge method to set the Cache-Control: max-age HTTP header.
  • For static cacheable resources, use Microsoft Internet Information Server (IIS) administration on a directory or individual resource basis to set the expiration date.

Non-cacheable Resources

To avoid wasting memory or drive space, it is important to identify resources that are good for one use only and cannot be cached:

  • For dynamically generated resources, the generating code should mark the resource as non-cacheable. For example, in C# use the HttpCachePolicy.SetNoStore method to set the Cache-Control: no-store directive.
  • For static non-cacheable resources, use IIS administration on a directory or individual resource basis to specify the resource as non-cacheable.

Enabling Prompt Databases

To enable prompt databases if Speech Server is not installed on the Web server that hosts SALT pages, map the .prompts file type to the content type application/octet-stream.

Enabling Audio File Rendering Using Dynamic Content Pages

If an application references a dynamic content page (for example, an ASPX page) that renders audio, then on the Web server that hosts the dynamic content page, the MIME type for the page must be set to the value that matches the format of the audio that the page renders.

To set the MIME type for a dynamic content page that renders audio

  1. Click Start, click Run, type inetmgr, and then click OK.

  2. On the left page, expand the server node, expand Web Sites, and then expand Default Web Site.

  3. Right-click the virtual directory containing your application, and then click Properties.

  4. Click the HTTP Headers tab, click MIME Types, and then click New.

  5. In the Extension box, type the extension for the dynamic content page (for example, aspx).

  6. In the MIME type box, type the value shown in the following table that corresponds to the type of audio file that your application???s page renders.

    MIME Type Value Use

    audio/wav

    Wave files that contain a header

    audio/basic

    Headerless mu-law audio files

    audio/x-alaw-basic

    Headerless a-law audio files

  7. Click OK three times.

If your dynamic content page is an ASPX page, you can alternatively set the MIME type using the ContentType attribute of the @ Page directive as follows:

<%@ Page ContentType=???audio/wav??? ???  %>

Deploying Grammars

If references to grammar files use file protocol URIs, these should be changed to HTTP URIs when applications are deployed. File protocol references fail when used in a staging or production environment.

Resource Names and URIs

Speech Server treats resource file names and URIs in a case-insensitive manner. For example, Speech Server does not treat the following two grammar files as different resources:

  • mygrammar.grxml
  • MyGrammar.grxml

Using resource files that are differentiated only by file name casing results in unpredictable behavior.