- Enable Page Cache: Enable or disable the page cache possibility globally. You must have a very good reason for setting it to “No” as it has a big performance impact and the cache on pages can be disabled individually instead where needed.
- Selective page cache update: Enable or disable if pages should be updated selectively in deliverWorking – do not set to “No” unless you have a special reason.
- Expire cache automatically: Enables one to set that the page caches and other caches are thrown away every x millisecond (x defined below). This is not a common setup as it’s quite ineffective and there are better options if such behaviour is needed.
- Cache expiration interval: How many milliseconds to wait until refreshing the caches. Only used if Expire cache automatically is set to yes.
- Request timeout (in deliverWorking and preview only): If set to a positive value the working/preview deliver will kill off request-threads that take longer than the set value. This is to avoid faulty test templates etc to block/disrupt the system. A value between 30000 and 120000 could be suitable if you have problems with blockage/hangs – otherwise keep empty.
- Request timeout(in deliverLive only): If set to a positive value the live deliver will either report or kill off requests that take longer than the set value. This is to avoid stability issues when issues arises. In some situations blocked threads can linger forever. A value between 30000 and 120000 could be suitable if you have problems with blockage/hangs – otherwise keep empty. Very nice to have if you have surrounding systems which are behaving badly like taking to long for example. Whether it kills the thread after the time specified here or just sends a warning mail depends on the next field.
- Kill live request after timeout: Decides if the live deliver should kill threads or just warn the sysadmin when threads take to long.
- Limit the number of active threads: This feature lets you tell InfoGlue to qeue up threads if to many comes in at once so we limit the synchronization costs. OBS: Use only after you have tested very much in a controlled environment so you know what is best for your site. Not many needs this setting.
- Max number of concurrent threads: Lets you state how many threads can be active at once. Only active if you set the previous setting to true. A value of 20 to 40 is not uncommon if used.
- Max time for requests before starting sleeping new threads: Lets you specify how long the request must become before InfoGlue should start to limit the incoming active requests. Only active if you set the previous setting to true. A value of 3000 (milliseconds) is not uncommon if used.
- Compress page cache: States if the page cache should be compressed before stored in memory. Saves quite a lot of RAM.
- Compress page response: States if the resulting pages should be gzip:ed before sent to the visitor. Saves bandwidth and speeds delivery a bit.
- Disable decorate final rendering (if you have good templates you can disable this): Disables last rendering in velocity after the components are rendered. If you have nice components which behaves you may be able to turn this off. Makes some sites a bit faster.
- Use IP-security: States if some application actions like UpdateCache and ViewApplicationState should be protected on which IP-addresses the call come from. If set to Yes you must specify the ip-addresses in the field below.
- Allowed admin IP-addresses: States the IP-addresses that are allowed to call some admin actions. OBS: This settings are also on the application settings startpage – use them there. Take care in allowing the cms-server to do this as the cache update calls are handled like this. If not cache will not get updated correctly.
- AllowXForwardedIPCheck: Allow you to specify that it is ok for Apache X-forwarded IP-addresses in IP-protected actions like ViewApplicationState.action.
- Default page cache key: States what parameters should be taken into account when creating or fetching data from the page cache. The complexity of this affects how large the page cache is in memory and how often the page cache holds what the user wants. The default key is:
- which means for example which browser the user has affects the hit rate on the cache. If one knows one will not make components which cares of the browser on the server side the page cache key can be shorter which is good. If one need cookies and session parameters can be used in the key.
- Default component cache key: States what parameters should be taken into account when creating or fetching data from the component cache (cache containing complete rendered component on a page). The complexity of this affects how large the component cache is in memory and how often the cache holds what the user wants. The default key is:
- which means here as well for example which browser the user has affects the hit rate on the cache. If one knows one will not make components which cares of the browser on the server side the page cache key can be shorter which is good. If one need cookies and session parameters can be used in the key.
- Cache settings: This is a feature which allows you to state individual sizes for each cache. The syntax is for example:
This means that the cache called “contentVersionCache” as named in the ViewApplicationState.action-view will use a LRU-algorithm when inserting things in the cache. When the cache capacity we have defined as 10000 above reaches it’s limit it will throw away the item used least recently. This way one can control memory usage quite a bit. Especially the page cache and some caches above can be very large after a while. If you start running without these settings you can check out how much memory is used in ViewApplicationState.action and limit the memory if needed. Remember – less memory caches means worse performance so don’t take it to far.
comments powered by Disqus