2.1.1. Caching Data when Transferring Files

Engineering Knowledge Manager

Administration Guide | Chapter 2: Overview of Servers and Workspaces | 2.1. Distributed Servers and Workspace Access |

2.1. Distributed Servers and Workspace Access |  | 2.1.2. Setting Up Caching
Prev |  | Next

### 2.1.1. Caching Data when Transferring Files

Caching can greatly improve file transfer performance in a globally distributed environment. In addition to a user-accessible workspace, every EKM server has a hidden system workspace that can cache data belonging to multiple remote servers when the File Transfer Client is used to upload/download files. To set up caching in a distributed configuration, you must specify a Cache Server definition in the EKM server that contains the repository that remote users will be accessing to upload/download files. This establishes the connection between the EKM server that hosts the data and the EKM server that is being used for caching. See Setting Up Caching for more information.

Sometimes you may want to use an EKM server only for caching. In this case the `Default` user-accessible workspace is simply not used. It is important to note that users are not defined in the cache workspace. Users cannot sign in to such a workspace, or perform any actions in it. Its sole purpose is to store, synchronize and release data during file transfers.

Note:

- Caching is not used when files are transferred using the browser.

- Caching is also used in Master-to-Slave transfers when running distributed jobs. See Running Jobs in a Distributed Environment.

#### How Caching Works

In Figure 2.3: Distributed Setup with Dedicated Cache Server, a user in London has a user account on the EKM server in New York (the Master Server). In order for data to be cached on the EKM server in London, a Cache Server definition must be specified on the Master Server in New York, and that user must be assigned in the Cache Server definition.

When the user logs into the EKM server in New York, and chooses to upload or download a file, the EKM server in New York recognizes that their user account is configured to use the Cache Server in London, and communicates this to the File Transfer Client. The Cache Server will first check to see if it has the file. If it does not, it will download it from the remote server in New York. At the same, the Cache Server will stream the file data to the user’s machine.

The user does not interact with the Cache Server at all because caching occurs seamlessly behind the scenes. To the user, it just seems like the file is being downloaded to their machine from the New York server. The only noticeable indicator is the data reported in the File Transfer Client.

Figure 2.3: Distributed Setup with Dedicated Cache Server

In the figure above, note that the EKM server in London does not have to be a dedicated Cache Server. It can also have its own user-accessible workspaces for data and simulation management.

#### How Caching Improves Performance

As users transfer files between a remote server and their desktops, the cache in their local EKM server becomes populated with files. Referring to Figure 2.3: Distributed Setup with Dedicated Cache Server, if a user in London downloads a file from the New York server that has been downloaded before by any user in London (and therefore exists in the cache workspace in London), the Cache Server will first ensure that it has the latest copy of the file from New York. If the file has changed on the New York server, the Cache Server will begin downloading the file from New York to get the cache in London up-to-date, and the File Transfer Client will simultaneously stream the downloaded data to the user’s machine.

If the file has not changed on the server in New York, the request can be processed by the Cache Server in London without requiring a data transfer from the Master Server in New York. File transfer performance will be improved because the user is getting the file directly from their regional server over a LAN rather than from the Master Server over a WAN.

Similarly, when a user in London uploads a file to the Master Server in New York, the file is first uploaded to the Cache Server in London. The Cache Server then uploads the file to the Master Server in New York and retains a copy of the file in its cache repository.

While there is technically no improvement in actual overall file transfer time for uploads, because the upload of the file is only over the LAN to the Cache Server, there is a perceived performance gain. Once the file is uploaded to the Cache Server, you do not have to wait for the Cache Server to upload the file to the Master Server and you may perform other actions. This essentially enables the setup of a queue of pending uploads (to the Master Server) that the Cache Server will handle later. You can even sign out once the files have been transferred to the Cache Server.

Contains proprietary and confidential information of ANSYS, Inc. and its subsidiaries and affiliates.

Prev | Up / Contents | Next

Release 18.2 - © ANSYS, Inc. All rights reserved.