When opting for Perfion as your future PIM system, you will receive a solution that is yours to control. You don’t share a database or the application server with competitors, and you are given the freedom of choosing when and how to upgrade to newer versions.

If you have decided to go with Perfion as your single source of truth for product information, the next step is to decide how you want to deploy and run the solution. Many factors will influence this choice, and there is no single correct answer to fit all organizations. That’s why Perfion is open and can be run in several ways, depending on your organization’s requirements and existing landscape.

SaaS or Hosted

The first crucial question to answer, is who you want to take responsibility for the production environment.

One option is to let Perfion take care of everything, if you buy the software as a service. In this scenario, we will use our partnership with Microsoft to provide a 24/7 managed solution in Azure, providing fast scalability options and an SLA with one of the market’s highest availability guarantees.

The other option is to manage the hosting yourself, either in a corporate data center, or by using a hosting provider of own choice. In this case, there is still a wide range of different scenarios, and Azure could still be the technological platform, only not managed by Perfion.

Open

For some organizations, purchasing the software and taking care of hosting under their own corporate wings, is the best option. This is especially the case if an existing hardware infrastructure is in place, or the internal staff is well-equipped to run Perfion from Azure/AWS/Oracle/Google or similar.

For others, ease of delivery and the time it takes to get started is essential. In that case, opt for a solution hosted and managed by Perfion, in which you only have to worry about taking good care of your data.

The following sections will provide a short description of the Perfion Azure hosted model, and then proceed to discuss general considerations for an on-premise Perfion.

The Perfion SaaS Offering

When choosing to let Perfion handle the hosting of your PIM solution, you will be benefitting from world-class virtual hardware provided by Microsoft Azure:

• 99.9%+ uptime

• Dynamic scaling options

• Best-in-class security measures

Before starting your project, we will discuss the complexity and size of your installation, to determine your “shoe size”, which will impact the running costs. Your solution can always be individually enhanced with added storage or other add-ons as requirements change.

Because your solution is all yours, the possibilities for integrations and network configuration are just as flexible as if you had your own hardware.

• Connecting with an on-premise ERP system? Not a problem.

• Integrating to a cloud-driven web shop? Also, not a problem.

• Doubling the size of your solution after a merger? Now that is a problem (but one that we can fix in 15 minutes).

By default, if you choose to use Perfion as a service, you will have access to both web client and rich client (the rich client can be reached via RDP or a web gateway).

If you want to know more about how to run Perfion without worrying about hosting, contact your local sales representative.

Hosting Perfion: Considerations

Perfion consists of several components, which in theory can be hosted independently:

• SQL Database

• API Service

• Windows Client

• Web Client

• Scheduler

• E-Commerce Connector modules

• ERP integration modules

• Asset Portal

• Supplier Portal

Not all components will necessarily be in use. But the solution will often also depend on some remote data from an external source, which adds another dimension to the decision of where to place each component.

The following sections describe some common scenarios, including pro’s and cons for each. Then, each of the components will be described separately in a little more detail.

Scenario 1: The On-premise Installation

For many small and mid-size organizations with an own IT organization, the most efficient way to utilize existing infrastructure is to install the database on a local SQL server managed by the IT department and have the Perfion Windows Client installed on each user’s PC. This is the simplest and most efficient setup possible.

Pros:

• The client program is running on many individual PC’s à using the hardware resources which already exist.

• The database is “close” à low latency for queries.

Con:

• Potentially, remote data from cloud-based systems can slow down performance

Of course, more often than not, additional components come into play (API service for integrations, scheduler for time-triggered actions etc.). This doesn’t mean the on-premise option is not a good one – only that the IT department should be ready to support in this.

Scenario 2: The Hosted solution

Another common scenario is to team up with a trusted partner to take care of the hosting. Depending on the technology used by the data center, the pros and cons could be either similar to an on-premise installation or closer to the all-cloud scenario.

I there is a tight integration between Perfion and an ERP system, it is generally recommended to have these two systems hosted on the same platform (or at least in the network-wise vicinity of each other).

Usually, an external data center means professional monitoring and services, but at a higher cost than inhouse installation. It is often beneficial to establish a good interaction between the Perfion implementation partner and the provider of the data center services, to make sure everyone understands the full context that Perfion will be operating in.

Scenario 3: The Cloud Installation

If an organization has a committed cloud-only strategy, then hosting Perfion the same way seems logical. This is especially true, if ERP system and other PIM-relevant integrations are also located there.

In theory, all the large vendors are possible:

• Microsoft Azure

• Amazon Web Services

• Google Cloud Platform

• …

There is still a decision to be taken regarding the Perfion Windows Client (whether to host that also on virtual machines or let the locally installed program communicate with a cloud database).

Pros:

• High uptime, flexible scalability

• No inhouse hardware or personnel required

Con:

• Total cost can become higher than for an on-premise installation

• Can require expertise in the specific cloud platform (or a dedicated partner)

Component-specific considerations

Database

The one central component in all Perfion solutions, is the SQL database itself. Two main factors decide how well the database performs: Sizing and latency.

Sizing

It can be very difficult to predict the appropriate sizing of a Perfion database server. Configurations will vary on several parameters, which can all affect the sizing. Just to mention a few:

• Number of items – generally, the higher the number, the more strain on the database

• Size of binary files – if large files are used frequently, disks with fast I/O is important

• Complex formulas and remotes can require additional queries pr. feature to be shown

• Usage of “wide” searches or grid views with many columns

• Configurations with deep hierarchies, many features dependencies, etc.

• Intensive interaction with external systems via the API

• …

There are some generic hardware requirements mentioned on the System Requirements page on the Perfion Knowledge Base, but we recommend making an individual judgment in collaboration with the Perfion partner.

And while it is our general recommendation that Perfion data is placed on a dedicated SQL server, it can often be a factor that other systems are using the same database, which makes sizing and performance monitoring even more complex.

Latency

In general, the closer (in terms of latency) the database is to the client program(s), the better the performance. In an on-premise setup, latency could be ~5ms, whereas a cloud provider or an external data center abroad could mean latency of several hundred ms.

In situations where multiple roundtrips are necessary (such as complex grid searches or complex tabs in the item editor), those difference will be multiplied and become substantial.

If there is indeed a severe bottleneck between database and the client software, consider placing the client on a virtual machine close to the database (since latency is less of an issue for transferring the image of an RDP window).

API Service

The IIS hosting the API, should ideally be placed very close to the database, since latency and data transfer performance are heavily dependent on the network between the two.

The API is seldom very dependent on the CPU and memory allocated to the IIS server itself. Of course, caching (especially of images) can be improved with more RAM, but there will often be a bigger benefit from boosting the database, rather than optimizing the IIS server. Standard monitoring tools can be used to see is there is indeed a bottleneck from an undersized IIS.

If the API is performing high-intensive image caching, e.g. for a website, it can sometimes be beneficial to install multiple API’s that are dedicated to specific tasks (e.g. one for E-commerce data and one for images).

Windows Client

The Perfion Windows Client is light weight, in the sense that it can run even from an older/smaller PC without any large performance deficit. See System Requirements for the general minimum requirements.

A typical user will have a memory consumption of less than ½ GB in normal use. However, there are special scenarios to consider. If a user needs to produce large catalogs, or work with very large datasets on-screen, then memory can become a factor in getting the best performance. This potential pitfall will be easy to identify via the Windows Task Manager.

Web Client

Using the Web Client, eliminates almost all requirements to the host device (except the requirement to have an updated browser installed).

On the server side, the same considerations as for the API service apply here.

Scheduler

If the scheduler is relevant as part of a Perfion solution landscape, it can be installed as a service on any server with access to the database, but often the choice falls on the same server as the API and/or web client. There is nothing making this a wrong choice, but CPU/memory consumption of the scheduler is completely dependent on which actions are scheduled to be performed. So, if many/large operations are scheduled, it can become relevant to consider offloading the scheduler to a separate server for best performance.

E-Commerce Connectors

Each of our standard E-Commerce Connectors involves setting up a dedicated service. As with the scheduler, this can be done on a shared server, because many use cases won’t require large hardware resources. But once again, actual usage may vary heavily and monitoring the connector during a test drive is always recommended to avoid problems down the line.

ERP Integration Modules

Installation of the Perfion ERP modules for Dynamics or SAP involves only a very small footprint in the ERP system. No special sizing requirements have to be considered. The only relevant thought would be whether the ERP users will put any additional strain on the Perfion API.

Asset Portal

The Perfion Asset Portal is a separate component and should generally be installed on a separate server. Converting/scaling images can be compute-intensive and for large video files also memory-consuming. But in normal use with only incremental changes/additions to the image/file libraries, requirements are low. See the separate requirements specification for the Asset Portal.

Supplier Portal

The Supplier Portal is a central SaaS solution, which means it is always hosted by Perfion (in Azure), and monitoring/scaling is done by Perfion.

Naturally, the actual transfer speed of data to/from the Perfion database will depend on the API and database of the individual customer (see above).