Administering ArcGIS for Server (2014)

Appendix A. Selecting the Right Hardware

Hardware is the set of cogs that makes the system operate. If a company wants to deploy software, it will require hardware to deploy it on. Purchasing expensive servers with highest specifications can be the choice for most companies in this case. However, knowing the software and hardware requirements and the estimated usage can help the company make smart decisions, save a lot of money, and have a system that runs efficiently and effectively. If you have a maximum of 500 users combined, it is costly and inefficient to purchase hardware that can serve 5,000 users. This section is dedicated to guide you to pick the hardware you need and distribute it carefully so that ArcGIS for Server can comfortably serve your maximum users.

Licensing – more machines or more power

The best way to select hardware is to understand the software you are going to use it for. ArcGIS for Server is licensed and based on processer cores, not users; this means the more cores you have, the more expensive the product becomes. For example, let us say you want to purchase a four-core license. This can give you many hardware solution options: you can get one server with quad-core CPU, or you can get two dual-core servers. If you could even find a single-core server these days, you can get four of those. But the question is which one of those solutions is suitable? According to Moore's law, computer power doubles every 18 months; this can be applied to the price as well, where the cost of the hardware drops. Although this depends on other factors including the clock speed of the core itself, having four single-core servers can theoretically give the same power as a one quad-core server given that they have relatively the same frequency. There is one thing which is important to be noted: not all the ArcGIS for Server tasks run on parallel processing. This means if you have four tasks or requests to be executed, it is more efficient to line them up on four moderately strong servers rather than stacking them up on one powerful server.

Four physical servers have their own dedicated memory and bus routes linked in a high-speed cluster, which gives more availability than one quad-core server and it is definitely cheaper. This way you can save a lot for the same or even more power; the key is not to be tricked by gimmicks of the hardware marketers and to know your requirements before purchasing the hardware. Esri has a dedicated website that compares different hardware and provides recommendations for the best hardware for Server; you can take a look at it at http://www.esri.com/systemdesign.

Choosing the number of cores

The number of cores defines the licensing for ArcGIS for Server and eventually how many users you are going to serve. According to Esri, a CPU in a GIS server under average conditions can support about four concurrently active service instances. The key is that if you are planning to serve users, not all will be sending requests at the same time; this means we can safely load more than four users on a single core. This also means a quad-core processor can serve up to 16 concurrent users. Let's do the math: assume an average GIS request takes about 200ms to execute and a single core can serve up to four requests in parallel, which means it can execute all the four requests in just 200ms. How much time does this core take to serve 1,000 requests assuming that they all came in at the same time? The answer is simple. We divide the requests by four and then multiply them by 200ms, which is the time required to execute each request in parallel. It takes 50 seconds to execute 1,000 GIS requests, four at a time, until they are all exhausted. Adding another core will shave half of that time off and serve as many requests. You can use the following formula to calculate the time required:

Where:

As seen in the previous table, T is the total execution time in seconds to complete Q number of requests; this can also signify the waiting time in the service. As per the equation, adding more cores (C) will decrease T, and having more clock speed will decrease X and will potentially bring T down. Similarly, you can reverse the equation to determine the number of cores required to serve, for example, 2,000 requests in 30 seconds as follows:

We substitute T with 30 seconds; this is my threshold, X will be 0.2 seconds, Q is 2,000, which leads to 3.3 cores, since there is no processor with as many number of cores. The nearest thing is a quad-core processor.

Choosing the size of memory

ArcGIS for Server requires a 64 instruction-set CPU in order to run. Your Server can run effectively on a quad-core 64-bit processor with minimum 8 GB RAM Server. Although, as your services and users increase, your 8 GB RAM will be drained quickly. The good thing about memory is that adding more is always better, since memory is cheap and you are not licensed for memory, at least not for ArcGIS for Server. Theoretically, a 16 GB RAM GIS server can serve up to 100 users if you were planning to have five services on one GIS server. You can replace that GIS server with two 8 GB RAMs as well. I have developed another rule of thumb to determine how much memory you require for each GIS server.

Where:

As seen in the previous table, R is the minimum amount of memory in a single GIS server required to make an optimal setup. It is measured in Gigabytes. You may round this number to the next nearest market-available RAM. For instance, if you got 13 GB, you may round it 16 GB. S is the total number of web services you are planning to have; this includes services that you are using; services that are not used should not be included in this equation. U is the maximum number of users you expect; note that this is the user and not requests. G is the number of GIS servers that will split the load. If you wish to have less RAM, you should increase this variable as these two variables are indirectly proportional. Let us say you want to serve 200 users and you anticipate publishing maybe 20 services running on 2 GIS servers. Using the preceding formula, you will get the size of memory you need as shown:

Although this seems like a lot of memory to have for each GIS server, it is the maximum you need for the worst-case scenario. It is definitely a figure that can help decide the size of memory needed. Serving 200 users that may consume all 20 services of course will spawn a lot of processes, and having 64 GB of memory will be enough to serve those requests and other applications that are running on the GIS servers including the database clients. If you increased the number of Servers (G) to 4, you will only need 32 GB per server. This will help you make smart decisions based on quotations you will be getting from hardware vendors.

Summary

This appendix has described how to select the right hardware for your ArcGIS for Server environment by providing some rules of thumb. By calculating the number of cores and memory required to serve your users, you can now estimate the level of hardware you need to efficiently set up Server on a good hardware that can run comfortably and serve your users without experiencing any deficiencies or requiring upgrading frequently. The next appendix will explain the history of architectures of ArcGIS for Server 10.1 and 10.2 versus the prior versions 10 and 9.x.