There are many awesome features in NetScaler, DataStream and DataStream caching add to the gambit to help bring NetScaler into a new environment, or leverage an existing implementation and add to the value already experienced. There are reasons why you would want to use DataStream and DataStream caching together, or by themselves. To help parse the use cases, below are a few:
Load balancing multiple SQL servers is a no-brainer use case scenario. If you need to leverage multiple SQL servers for performance, NetScaler is the solution. Within this category, there are a couple of ways you can configure NetScaler based on your SQL design.
The first method in configuring a load-balanced solution is in a SQL master/slave database architecture. In this scenario, you have a SQL server(s) for writes and other SQL servers for reads. NetScaler will parse the query and determine based on policies, whether to send the traffic to the master SQL server(s) for writes or send the traffic to the slave SQL servers for reads. To accomplish this, you would need the following objects created on the NetScaler:
Load balancing services - One service for each SQL server.
Load balancing master virtual server - This virtual server will be bound to the master SQL server services.
Load balancing slave virtual server - This virtual server will be bound to the slave SQL server services.
Content switching virtual server - This virtual server will be used for client connections. The virtual server will then forward the SQL traffic to the appropriate load-balanced virtual server (master or slave) based on policies.
Content switching policy - This is where you define how to forward your traffic. You can create a policy that listens for "select\" and forward that traffic to the slave virtual servers for read actions. Then all write actions will by default go to the master virtual server.
The second method in configuring a load-balanced solution is the token method. With the token method, you create a token on the NetScaler and the NetScaler will gather the token value from the client. Thereby, sending all like tokens to the same backend SQL server. For instance, if you create a token on the NetScaler to listen for database names, all client requests that are going to the same database will be forwarded to a SQL server, the next database (different database name) requested will then go to another SQL server. Below are some sample expressions that can be used to create tokens:
.REQ.QUERY.TEXT
.REQ.QUERY.TEXT(n)
.REQ.QUERY.COMMAND
.CLIENT.USER
.CLIENT.DATABASE
MYSQL.CLIENT.CAPABILITIES
To accomplish the token-based load-balanced method, you will need the following objects on your NetScaler:
Load balanced services - One load-balanced service per SQL server.
Load balancing virtual server - One load-balanced virtual server for client requests with the load balanced method set to "token" and the rule expression of your choice. The load-balanced services will be bound to this virtual server.
With either of the 2 load-balanced options above, or if you only have a single SQL server you can add DataStream caching on reads. With DataStream caching, the main advantage is to take queries that take a long time to process, to a mere fraction of a second to send back to the client. To configure DataStream caching, you will need the following objects:
Load balanced services - One load-balanced service per SQL server.
Load balancing virtual server - Minimum, one load-balanced virtual server for client requests.
Cache Selector - A selector is a filter that locates particular objects in a content group to reduce any possible duplicate cached content.
Content Group - Minimum, one content group. This is where the query cache will be stored.
SQL Cache Policy - This is where you define your expression on when to cache.
In testing, I have seen requests that take around 80 seconds, down to .03 seconds. There are some obvious questions in regards to caching. What happens if you update the record, how do you let NetScaler know to invalidate the cache? There are a couple of methods that you can take advantage of. First, you can set timeouts on the cache in seconds. Second, you can create a policy so that if the NetScaler processes a write action, the policy will invalidate the cache. Once the cache is invalidated, the system will wait for a query that matches the configured policy and cache the response. Any subsequent querys to the same data will be retrieved from the NetScaler cache instead of the SQL server. Then, either the cache timeout or the policy that invalidates the cache will take action and the process starts over.
So, whether you have a single or multiple SQL servers, with DataStream and/or DataStream caching you will definitely see an improvement with performance.