Netscaler Knowledgebase

I won't go into explicit configuration details here, but some overall best practices:

1.  Always remember that if you turn IC on, then it is **ON**, in that for all http requests going through the box, it will attempt to cache based on RFC compliant behaviors for HTTP.  With this, it will honor maxage values, honor the cache control headers, etc.  If without any policies the IC isn't operating effeciently if you simply turn on IC, then chances are the back-end application could be tuned better to serve content tagged with the proper policies.  In many cases this can be the best way to handle things, as it allows the content developers to control expiration, caching, so that the NS configuration doesn't have to be tuned.  This behavior is part of the "default rules" so if you bind a policy before the default rules, then you will be overriding this internal behavior.
2.  If you disable IC or change policies, it will NOT flush or otherwise modify the cache objects already in the cache.  As a result, you could continue delivering an object that you don't want to have cached from a previous instance of the cache policies.
3.  Before turning on IC, you should bind a "default nocache" policy as precede default rules, which will insure that you only cache content based on explicit policies, not the built-in policies;
4.  If you are using SSL offload, rule #2 is in particular important.  Many applications that use SSL are not coded properly to write HTTP headers properly to account for caching, as with encrypted content, no intermediate caches are in play.  With the NetScaler doing the encryption, it may be following RFC compliant behavior, but the content isn't playing by those rules.  For pure HTTP content, in general any fair sized application will have hit proxies in the middle before, and tuned the code, but if the NS is doing it, fingers will blame the NS for causing the problem.
5.  Create an "invalidation" policy that the content developers/server administrators know.  An invalidation policy is one that will result in objects being flushed from the cache, instead of being stored in it.  This will allow the NS administrator to sleep well at night when a content push is made in the middle of the night, and they realize that objects from the previous version of the content are in the cache, and breaking the application.  If you provide this policy to them, they can flush the cache without having direct admin access to the box.  Hint:  The URL for the invalidation policy is effectively a password that can be used to  flush the cache, so it should be a unique and non-guessable URL that will trigger the behavior.  This request will also make it to the server logs, and probably generate a 404 error, so even if someone does guess it, it won't provide any indication that it worked.
6.  Remember that the IC subsystem will cache objects that the NS compresses itself.  If the first request for an object doesn't have an accept-encoding header, and it caches the object, then later requests will get the non-compressed version.  If the reverse occurs though, where the object is compressed and cached, but the request doesn't have an accept-encoding header, then it will be considered a cache miss, and the request will be made to the server.  This can actually be tuned if desired using "cache selectors" if it has a large impact on cache behavior.
7.   If you have content that is "time dynamic" but is otherwise static, i.e. a stock quote hit, and the same request is requested often by many users, then you can make use of the flash cache option+invalidate when complete to serve the content.  This will allow the object to be served from the cache even when it isn't completely served from the source server, and ALL users that request it while it is "in play" will receive the same copy of the object.  When the object is completely served from the source, no new connections will be "attached" to that instance of the object, instead a new instance of the object will be created for the new requests, and again it will be requested from the server.  This allows the time-dependent dynamic content to be served more efficiently to the users, and helps to avoid  database hits for such objects.

The Oracle