CSP Gateway Configuration Guide - InterSystems Documentation

More documents

Recommendations

Info

CSP Gateway Operation and Configuration 2.6.2 Using the GZIP/ZLIB Library The Gateway implements two modes of operation (1 and 2) for compressing the response data using the ZLIB library: 1. In this mode, the Gateway streams all data received from Caché into the compressor. When all the data has been processed, the compressor streams the compressed data back to the Gateway at which point it is forwarded on to the client. This mode offers the best possible compression at the expense of slightly higher latency. Of course, the latency is more pronounced for larger forms. 2. In this mode, the Gateway streams all data received from Caché into the compressor. On each and every call, the compressor makes as much compressed data as it can available to the Gateway at which point it is forwarded on to the client. This mode offers the lowest possible latency at the expense of slightly reduced level of compression. Of course, the reduction in the degree of compression achieved is more pronounced for larger forms. Generally speaking, mode 2 is more appropriate for CSP applications where it’s usually not possible to know, in advance, how much data a CSP response contains. If (and only if) the Gateway is able to successfully compress the data stream returned from Caché, it modifies the HTTP response headers to include the appropriate Content-Encoding directive. For example: HTTP/1.1 200 OK Content-Type: text/html; charset=ISO-8859-1 Set-Cookie: CSPSESSIONID=000000000002119qMwh3003228403243; path=/csp/samples/; CACHE-CONTROL: no-cache CONNECTION: Close DATE: Fri, 15 Aug 2003 10:05:18 GMT EXPIRES: Thu, 29 Oct 1998 17:04:19 GMT PRAGMA: no-cache Content-Encoding: gzip Before attempting to compress response data, the Gateway always checks the value of the Accept-Encoding HTTP request header (the HTTP_ACCEPT_ENCODING CGI environment variable). The Gateway only compresses a response if the client has indicated that it is capable of dealing with compressed content. For example: Accept-Encoding: gzip, deflate There are several methods for specifying that a CSP response should be compressed. These are discussed in the following sections. 2.6.3 Specifying Compression for Individual Pages The %response object contains a property called GzipOutput. If this property is set to true (or the mode required) the Gateway attempts to compress the response. Set %response.GzipOutput = 2 Quit 1 Compression can also be specified on a per-page basis by adding the CSP-gzip directive to the HTTP response headers. This must, of course, be done in the OnPreHTTP method. For example: Do %response.SetHeader("CSP-gzip", "2") Quit 1 The CSP-gzip header directive should be set to the compression mode required (1 or 2). 42 CSP Gateway Configuration Guide
CSP Page Output Caching 2.6.4 Specifying Compression for All Pages within an Application Path Compression can be specified on a per-application path basis. This, incidentally, is the commonest method for indicating that compression should be used when using a Web server output filter (such as mod_deflate). Use the following configuration parameters in the Gateway Application Access section: Item GZIP Compression GZIP Minimum File Size Function If Enabled, all CSP output for that path is compressed using the Gateway's mode 2 of operation. Default is Disabled (no compression). Control the minimum response size for which compression is activated. The parameter is specified in Bytes. If left empty then all responses for which GZIP is enabled are compressed. 2.6.5 Monitoring An Event Log level of V3 instructs the Gateway to record the degree of compression achieved for all CSP responses that were successfully compressed. The size of the compressed data and the original uncompressed data stream is recorded. For example: GZIP Compression for /csp/samples/inspector.csp GZIP Mode=1; Uncompressed Content Size=19042; Compressed Content Size=2499 (13 percent) 2.7 CSP Page Output Caching Most Web developers are familiar with the way Web browsers support a client cache of previously requested Web pages. Client-side page caching can improve the performance for individual users by allowing previously accessed pages to be retrieved from local storage (memory or local hard drive) rather than as a result of fetching the document from the original server. CSP Page Output Caching provides the option to maintain a cache of frequently accessed pages within the CSP Gateway. Since the Gateway is a core component residing on the Web server, its cache can be shared amongst all users of that CSP installation. For example, if a single user requests a page that is configured to be placed in the Gateway cache, then all subsequent requests for that page can use the cached copy. Cached pages are available to all users. This facility can have a dramatic effect on performance for two reasons: Firstly, from a user’s perspective, pages retrieved from the cache are served extremely quickly and, secondly, the Caché system is not involved in the delivery of cached pages so its work load is significantly reduced. The Page Output Caching facility implemented for CSP is based on the equivalent mechanism provided by Microsoft’s ASP.NET product. This choice of design was made in order to reduce the amount of learning involved in getting to grips with this facility. Most developers are familiar with ASP.NET. Page caching is controlled by settings within the CSP %response object. Two properties are available for controlling which pages should be cached and for how long. The default behavior of CSP is that pages should not be placed in the cache. 2.7.1 %response.Expires Property The standard Expires property controls how long a page should reside in the cache. CSP Gateway Configuration Guide 43
Page 1 and 2: CSP Gateway Configuration Guide Ver
Page 3 and 4: Table of Contents About this Book .
Page 5: 4.4.1 Starting NSD on Alternative T
Page 9 and 10: 1 Introduction to the CSP Gateway T
Page 11 and 12: Using the Network Service Daemon (N
Page 13 and 14: Minimal Apache Web Server or Privat
Page 15: Minimal Apache Web Server or Privat
Page 18 and 19: CSP Gateway Operation and Configura
Page 60 and 61: Using Caché Server Pages with a Re
Page 67 and 68: 4 Web Servers for Microsoft Windows
Page 69 and 70: Microsoft Internet Information Serv
Page 99 and 100:
Microsoft Internet Information Serv
Page 101 and 102:
Apache Servers Note: There are sepa
Page 103 and 104:
Apache Servers is hard-coded into t
Page 105 and 106:
Apache Servers Allow from all The
Page 107 and 108:
Apache Servers This results in all
Page 109 and 110:
Apache Servers ScriptAliasMatch ^/c
Page 111 and 112:
Apache Servers Specify appropriate
Page 113 and 114:
Operating the Network Service Daemo
Page 115:
Locked-down Apache environments Usi
Page 118 and 119:
Web Servers for UNIX®, Linux, and
Page 120 and 121:
Page 122 and 123:
Page 124 and 125:
Page 126 and 127:
Page 128 and 129:
Page 130 and 131:
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
Page 138 and 139:
Page 140 and 141:
Page 142 and 143:
Page 144 and 145:
Web Servers for Hewlett-Packard (HP
Page 146 and 147:
Page 148 and 149:
show all

CSP Gateway Configuration Guide - InterSystems Documentation

Create successful ePaper yourself

Delete template?

Save as template?