This guide introduces you to how InterSystems IRIS™ data platform can scale for user volume by using application servers for distributed caching, leveraging the Enterprise Cache Protocol (ECP).
It presents an introduction to scaling with distributed caching architecture and walks through some initial tasks associated with deploying an InterSystems IRIS™ distributed cache cluster. Once you are done, you will have a basic understanding of how a distributed cache cluster works and how to set it up.
When users connect to your InterSystems IRIS databases via applications, they need quick and efficient access to the data. Whether your enterprise is small, large, or in between, a high number of concurrent user requests against the databases — user volume — can cause performance problems on the system that hosts the databases. This can potentially affect many more users, making them wait longer to receive the information they need. And in a dynamic business, user volume can grow rapidly, further impacting performance.
In particular, if a lot of users are executing many different queries, the size of those queries can outgrow the cache, meaning that they can no longer be stored in memory and instead need to read data from the disk. This inefficient process causes bottlenecks and performance problems. You can increase the memory and cache size on the system (vertical scaling), but that solution can be expensive, inflexible, and ultimately limited by the maximum capabilities of the hardware. Spreading the user workload over multiple systems (horizontal scaling) is a more flexible, efficient, and scalable solution.
To improve the speed and efficiency of users’ access to the data, InterSystems IRIS can use distributed caching. This technology allows InterSystems IRIS to store the database cache on multiple application servers. User volume can then be distributed across those servers, thus increasing the cache efficiency. The internode communication that makes this possible is enabled by ECP, the Enterprise Cache Protocol.
Using distributed caching, you can enable users who make similar queries to share a portion of the cache, which is hosted on an application server clustered with the data server where your data is hosted. The actual data remains on the data server, but caches are maintained on the application servers for faster user access. The data server takes care of keeping the cached data up-to-date on each application server in the enterprise.
With a distributed cache cluster, you can easily scale your solution by adding or removing application servers as needed. All application servers automatically maintain their own connections to the data server, and attempt to recover the connection if it drops.
You can configure application servers and their associated data servers on the individual cluster instances using their Management Portals, or deploy and configure a cluster using InterSystems Cloud Manager (ICM). For more information on ICM, see First Look: ICM and the InterSystems Cloud Manager Guide.
When you deploy an InterSystems IRIS distributed cache cluster, you designate one instance as the data server, and one or more instances as application servers. The instances do not need to run on the same operating system or hardware; they only need to conform to the InterSystems IRIS system requirements.
Set up a distributed cache cluster with InterSystems IRIS is easy. This simple procedure walks you through the basic steps of configuring ECP on several instances.
In this example, you will set up one InterSystems IRIS instance as a data server and two more instances as application servers. This means you will need three instances altogether. Your choices for InterSystems IRIS include several types of licensed instances; the instances need not be hosted by the system you are working on (although they must have network access to each other). For information on how to deploy each type of instance if you do not already have three to work with, see Deploying Licensed Instances in InterSystems IRIS Basics: Connecting an IDE.
First, enable the ECP service on each of the three instances as follows:
You have now enabled ECP on your system. There are just a few more steps to finish the setup for the data server and the two application servers.
On the system that will be your data server, there are just two more quick steps to finish the setup. First, you need to increase the number of allowed application servers from the default of one. Then, you will create a new database for your application servers to connect to. Of course, in a production environment, you would already have a database in use.
To finish the data server configuration:
For more details about creating a data server and setting the available options, see Preparing the Data Server in the “Horizontally Scaling Systems for User Volume with InterSystems Distributed Caching” chapter of the Scalability Guide.
To create a new database for this exercise:
You have created your new database, and your data server is ready to go.
In the next sections, you will set up the two application servers and configure them to be able to communicate with the data server. For this purpose, you will need to know the data server’s superserver port number, as described in InterSystems IRIS Basics: Connecting an IDE.
Next, you will set up your other two instances as application servers. You will configure each application server to point to the data server, and create a new namespace on each, mapped to the database you created on the data server.
Be sure to perform both of the following procedures on each application server.
Now that you have connected your application servers to your data server, you need to create a namespace on each application server. This namespace will be local to the application server, but instead of containing a local database, it will be mapped to a remote database — that is, the ECP database on the data server, which you created in the previous section.
For more details about creating a namespace and its associated database, see “Create/Modify a Namespace” in the “Configuring InterSystems IRIS” chapter of the System Administration Guide. For background information, see “Namespaces and Databases” in the Orientation Guide for Server-Side Programming.
You are done! Once you have performed both procedures on each application server instance, you have successfully created a cluster that has one data server and two application servers. In the next section, you will test the connections to make sure that all three instances are communicating with each other correctly.
Now that you have enabled the ECP service and set up two application servers with namespaces pointing to the database on the data server, it is time to do a quick test to make sure that the three systems are communicating with each other. To accomplish this, you will set a simple global on one application server, then read and change it on the second application server.
To learn more about globals, see Using Globals.
ECPNS, so you would do:
USER>zn "ECPNS" ECPNS>
ECPNS> set ^MyGlobal = "My Value"
ECPNSnamespace as described above.
ECPNS> write ^MyGlobal My Value
This shows that the two application servers are communicating properly with the data server. You used one of the application servers to create the global, but because you were working in the namespace that contains the remote database, the global was actually created on the data server. That is why the other application server can read it. Of course, this is only an example, but the mechanism is the same, regardless of whether you are manually setting and then reading a global on the Terminal, or having a large number of users issuing thousands of transactions per second through a dozen application servers fronting the same data server. ECP will ensure that the data is kept in sync and guarantee transactional consistency for all those users’ interactions with the system.
MyGlobalon the list.
To learn more about using distributed caching and ECP with InterSystems IRIS, see the following resources: