NWebCache Features
Below are some features of NWebCache:
Specify regular expression based rules
NWebCache allows you to create caching rules based on .NET regular expressions. Any URL expression, as long as it is syntactically correct, should work.
Specify cache or do-not-cache rules
Rules play an important role in caching HTTP responses. You can define rules to avoid caching certain responses for example a dynamic page that change its contents on each request is not a cacheable page so you may want to avoid caching it.
Following are the different types of rules that you can specify using NWebCache Manager.
- Cache: This rule is intended to cache the response if the request comes under this rule. Once the response is cached, it is served from the cache for all the subsequent calls until the response is expired from the cache.
- Avoid Cache: Responses of all URLs coming under this rule must not be cached.
- Analyze Content: Analyze the response for the requests coming under this rule and determines for how long the response of the URL can be cached.
- Cache ASP.NET ViewState: Viewstate for the URLs coming under this rule will be cached if its size is greater than the specified threshold.
- Invalidate Cached Responses: Requests of all URLs coming under this rule can invalidate some other responses cached for different URLs.
By default, use Http header for cache guidelines
NWebCache also support HTTP 1.0/1.1 header based caching. You can turn on or off header based caching at anytime.
Specify compression rules
Use NWebCache compression feature even if your web server does not support compression. You can enable compression on each rule and can also define file types that should be compressed before sending the response to the users. If the compression is enabled NWebCache stores the compressed response in the distributed cache. This increases the response time and reduce the bandwidth used by the servers.
Use gzip compression
NWebCache supports GZip compression.
Cache ViewState & send unique key to browser
ASP.NET ViewState is another source that consumes lot of bandwidth and NWebCache handles it very intelligently. NWebCache intercepts the ASP.NET response, extract the ViewState then store it in the distributed cache and it appends the response with an encrypted ViewState key (very small size) and send the response to the client. On the next request NWebCache reads the ViewState from the cache based on the ViewState unique key and replace it with the actual ViewState retrieved from the cache and send it to the web server. This way it reduces the bandwidth consumption.
Send cached ViewState to web server for post-back
When NWebCache receives the postback request it extract the NViewState key from the response and get the actual ViewState from the cache and then it appends the response with the actual ViewState before sending it to the web servers.
Send PDF to browser page by page
NWebCache provides PDF documents caching and allows the clients to read the PDF pages using the Byte Range. NWebCache downloads PDF documents one time, even if there are multiple NWebCache servers configured. And all the client requests are fulfilled by cached PDF document, which increases performance and reduces the bandwidth.
Absolute Time Expiration
Absolute expiration indicates that a cached response should expire at a specific point in time (e.g, 10 minutes from now).
Idle Time Expiration
Idle Time expiration means that if the cached response is not accessed for a specific period of time then it should be removed from the cache.
Auto Reload Expired Pages
Auto reload feature allows a page to be automatically refreshed as soon as it gets expired from the backend caching subsystem. This helps in minimizing delays a user would face in fetching a page from web server directly.
SqlCacheDependency for SQL Server 2005/2008 & Oracle 11g
NWebCache synchronizes cached pages with data in your database with the help of SqlCacheDependency. You can have a cached response depend on a row in a SQL Server 2005/2008 & Oracle 11g database. Then if anybody updates or removes that row, the cached response will be removed from the cache. This allows you to cache all your dynamic pages and still keep them fresh.
Polling based DbDependency for all OLEDB databases
This is another way to synchronize cached pages with data in your database. You can have a cached response depend on a row in any OLEDB database including SQL Server 2000, Oracle, DB2, and Sybase. Then if anybody updates or removes that row, NCache removes that cached response from the cache. NCache implements this through polling. A special table called ncache_db_sync is created in the database and you're required to modify your insert, update, and delete triggers so when a row is updated in your table, this trigger updates a flag in a corresponding row in the ncache_db_sync table. Then, the next time NCache polls that table, it finds out which rows were updated and then removes those cached items from the cache
Automatically identify candidate pages for caching
Content Analysis helps in determining the cacheable responses from the current incoming traffic. The analysis is done separately on each URL. NWebCache calculates the expiration time for each response by analyzing the changes observed in each response during the analysis period.
File based Cache Dependency to invalidate cached pages
Like Database synchronization, you can invalidate the cached response using the File dependency. You can have a cached response depend on a File and if anybody modifies or removes that file, the cached response will be removed from the cache.
Session based caching
NWebCache also provides session based content caching for dynamic pages. There can be two types of session based applications, Private and Shared. NWebCache provides caching for both.
- Private Session : Each individual has its own session and all the data is private, like Emails are accessible to owner only.
- Shared Session : Each individual has its own session but data is shared, like blogs, discussion forums.
Security
Security by default is turned off. However, if you turn it on then NWebCache authenticates and authorizes all client connections before accepting them. The client is required to send (in clear text) username and password that are first authenticated on the server node. Authentication is done against Active Directory. Once the user is authenticated, then NWebCache checks its authorization as either a User or an Admin. If the current user is neither in User or Admin list, then the connection is rejected. Users are allowed to access the cache at runtime for data and Admins are allowed to also create and administer the cache
Multiple NICs Support
NWebCache provides support for multiple NIC’s. Network traffic can be balanced using multiple network cards. User can specify different network interface cards for different levels of network communication NWebCache supports.
SSL Support (Only Pass-through)
NWebCache does not support SSL based requests. All requests are treated as Pass-through by NWebCache proxy.
Media Stream Support (Only Pass-through)
NWebCache does not support Media Streams. SSL based requests. All requests are treated as Pass-through by NWebCache proxy.
URL Based Invalidations
NWebCache also provides URL based invalidations. Contents saved against a url/urls can be invalidated based on another URL. For example: Cached Page of a Load_customer 123, would be invalidated as soon as Save_Customer 123 is called.
HTTP Based Invalidations
This feature gives user a single point to invalidate all cached pages. It allows user to specify a single url, that would invalidate all the cached pages as soon as a request for the said page is received by NWebCache.
HTTP Based Invalidation API
This feature allows NWebCache users to invalidate cached URLs using Invalidation API, in their .Net based applications. (For Developers use)
Block/Unblock specific IP List
Multiple NWebCache allows user to specify different IP-Pools and apply different caching rules on each pool separately.