P21 System Performance in Accordance

When deploying any enterprise-level application such as Epicor’s Prophet 21 ERP, system performance is an extremely important consideration, one that can have significant impact on the successful use of the application. Memory allocation, transaction logging, network connections and a litany of other factors can affect the user community’s experience of the application. Failures in any one of these areas can bring an application to a grinding halt. This is certainly the case in a P21 environment.

As such, the work of a P21 administrator is critical in the successful deployment and maintenance of the Prophet 21 ecosystem.

While the successful administration of a P21 environment will differ on several factors, such as the version installed, the presence of a middleware server, the use of terminal services, and the use of the legacy desktop application, the actions taken to attain, maintain, and sustain a P21 ecosystem can be summarized by the two following principles:

• Scaling Up: Stacking up resources onto a single existing server, user terminal, network, or device to allow it to perform better and bear additional load.
• Scaling Out: Branching out by breaking out additional servers, terminals, network connections or devices to improve the capacity and capability of the overall P21 infrastructure.

Scaling up in a Prophet 21 Ecosystem

Scaling up involves the addition of resources, most often to a server, to address issues with usage and performance. In many cases, the performance of a single server, whether it is an application server, a database server or a user terminal, can be improved by identifying the problem in question and judiciously allocating some additional resources, such as RAM, CPU, or storage.

Let’s use the Prophet 21 desktop application as an example. The architecture of the legacy desktop application was such that a single desktop client generally consumed one entire CPU when in use. This creates a challenge for terminal services, given that two users logged into the same terminal server cannot share the same CPU, as is the case with other applications.

To address this, system administrators need to “scale up” and add CPUs to the terminal server, to allow multiple users to work from it in parallel. This is of course easier to do when the computer is virtualized, so admins will want to consider this should they have the need to build out a remote desktop for their user community. Depending on the number of users in your company, such an approach to your P21 environment may be satisfactory. 

With the shift from the legacy P21 desktop application to the P21 middleware server, the concern with scale similarly shifts. Scaling up under the modern architecture now involves the resources allocated to a given middleware server to allow it to handle heavier loads. Even here, it is not uncommon that companies encounter scaling issues with the P21 middleware server, as the company grows. In many cases, the answer is not to scale up, but to scale out.

Scaling out in a Prophet 21 Ecosystem

Using the example of the Prophet 21 desktop application, a company can scale up a single remote desktop so high before the additional building blocks no longer elevate its cause. In the case of a remote desktop, a single terminal server can support approximately 12 CPUs to support roughly 15 users working in parallel—any further and the platform begins to bend under the weight of its own design.

In this case, it is preferable to spin up a separate P21 terminal server to support additional user requirements, and to integrate the multiple servers with a broker to create a server farm.

A similar but updated concern relates to Epicor’s middleware application server layer, and the number of users it can support. As with the development of a Prophet 21 server farm for remote desktops, the need might arise to create a load-balanced farm of Prophet 21 middleware servers, in order to meet user needs.

The shift from a 2-tiered architecture, in which the fat client speaks directly to the database to a 3-tiered architecture, where the thin client speaks to the middleware server naturally shifts much of the heavy lifting from the traditional desktop client to the P21 middleware server itself. 

Again, the specifications are ambiguous, but we’ve found that often a single Prophet 21 middleware server can be scaled up such that it will support roughly 50 concurrent users before the server can no longer perform any additional heavy lifting. In these cases, it is preferable to build out a new Prophet 21 middleware server in a load-balanced environment.

P21 Economies of Scale

In practice, helping users often involves some combination of scaling up and scaling out. It begins with an understanding of the scope and limitations of the Prophet 21 architecture and an understanding of the size of the user community and their needs. From there, the combinations and permutations become an intriguing and multifaceted challenge for the P21 administrator to circumnavigate.