By choosing Perfion as your future PIM system, you gain complete control over your solution. You won’t share a database or application server with competitors, and you have the flexibility to decide 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 influence this decision, and there is no one-size-fits-all solution for every organization. That’s why Perfion is designed to be flexible, allowing it to run in multiple ways depending on your organization’s needs and existing infrastructure.

SaaS or Hosted

The first crucial question to consider is who will take responsibility for the production environment.

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

Alternatively you can choose to manage the hosting yourself, either in a corporate data center, or through a hosting provider of your choice. Even in this case, Azure can still serve as the technological platform - just without Perfion managing it.

Open

For some organizations, purchasing the software and taking care of hosting under their own corporate wings, is the best choice - especially when an existing hardware infrastructure is already in place, or the internal staff has the expertise to run Perfion on platforms like Azure/AWS/Oracle/Google or similar.

For others, ease of delivery and fast implementation are top priorities. In this case, a Perfion-hosted and managed solution is the ideal option, allowing you to focus solely on managing your data while we take care of the infrastructure.

The following sections will first outline the Perfion Azure-hosted model, and then provide an overview of key considerations for an on-premise Perfion setup.

The Perfion SaaS Offering

By choosing Perfion-hosted PIM, you gain access to world-class virtual hardware powered by Microsoft Azure, ensuring

• 99.9%+ uptime

• Dynamic scaling options

• Best-in-class security measures

Before starting your project, we will assess the complexity and scale of your installation, to determine the right“fit”, a factor that influences running costs. Your solution remains fully adaptable, allowing for additional storage or other add-ons as your need evolve.

Since your Perfion solution is entirely yours, integration and network configurations are as flexible as if you were operation on your own hardware.

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

• Integrating with a cloud-based web shop? Also, no problem.

• Doubling your solution’s size after a merger? Now that’s a challenge - but one that we can fix in 15 minutes.

By default, Perfion as a service, includes access to both the Web Client and the Rich Client (the rich client being accessible via RDP or a web gateway).

If you want to know more about running Perfion hassle-free without worrying about hosting, contact your local sales representative.

Hosting Perfion: Considerations

Perfion is made up of multiple components, each of which can, in theory, 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 often relies on remote data from external sources, adding another layer of complexity to when deciding where to host each component.

The following sections describe some common hosting scenarios, highlighting their pros and cons. Each of the components will then be examined in more detail.

Scenario 1: The On-premise Installation

For many small and mid-sized organizations with an in-house IT department, the most efficient way to leverage existing infrastructure is to:

✔ Host the database on a local SQL server managed by IT
✔ Install the Perfion Windows Client on each user’s PC

This setup is straightforward, cost-effective, and easy to maintain - making it the simplest deployment option.

Pros:

• The client program is runs on multiple individual PCs utilizing already existing hardware resources.

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

Con:

• Potentially, remote data from cloud-based systems could impact performance, causing slower response times.

Of course, more often than not, additional components, such as API service for integrations, or a scheduler for time-triggered actions, come into play. This doesn’t mean the on-premise option isn’t a viable choice - it only requires the IT department to be prepared to support these additional complexities.

Scenario 2: The Hosted solution

Another common scenario involves teaming up with a trusted partner to handle the hosting. Depending on the technology used by the data center, the pros and cons could either resemble an on-premise installation or align more with an all-cloud scenario.

If there is a tight integration between Perfion and an ERP system, it is generally recommended to have both systems hosted on the same platform (or at least within close network proximity).

An external data center typically offers professional monitoring and services, but at a higher cost compared to in-house installations. It is often beneficial to foster strong communication between the Perfion implementation partner and the data center services provider, ensuring everyone fully understands the context in which Perfion will operate.

Scenario 3: The Cloud Installation

If an organization has a committed cloud-only strategy, hosting Perfion the same way is a logical choice, especially if the ERP system and other PIM-related integrations are also cloud-based.

In theory, all the major cloud providers are viable options:

• Microsoft Azure

• Amazon Web Services

• Google Cloud Platform

• …

A decision still needs to be made regarding the Perfion Windows Client: whether to host it also on virtual machines or allow the locally installed program to communicate with a cloud database.

Pros:

• High uptime and flexible scalability

• No in-house hardware or personnel required

Cons:

• Total cost may be higher than than an on-premise installation

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

Component-specific considerations

Database

The central component in all Perfion solutions is the SQL database itself. Two main factors determine how well the database performs: sizing and latency.

Sizing

Predicting the appropriate sizing of a Perfion database server can be challening. Configurations vary based on several parameters, each of which can impact sizing. Just to mention a few:

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

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

• Complex formulas and remotes - these can require additional queries per feature displayed

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

• Configurations with deep hierarchies, numerous feature dependencies, etc.

• Intensive interaction with external systems via the API

• …

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

And while we generally recommend placing Perfion data on a dedicated SQL server, it is common for other systems to share the same database, which can make 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 can be as low as ~5ms, whereas using a cloud provider or an external data center abroad could introduce latency of several hundred milliseconds.

In situations where multiple roundtrips are rquired (such as for complex grid searches or detailed tabs in the item editor), these difference will be multiplied, which can significantly impact performance.

If there is a noticeable bottleneck between the database and the client software, consider deploying the client on a virtual machine located close to the database, since latency becomes less of an issue when transferring the image of an RDP window.

API Service

The IIS hosting the API, should ideally be located very close to the database, as latency and data transfer performance are highly dependent on the network connection between the two.

The API itself is typically not very dependent on the CPU and memory allocated to the IIS server. 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 heavily involved in image caching—for example, in the context of an e-commerce website—it can sometimes be beneficial to install multiple APIs, each dedicated to specific tasks. For instance, one API could handle e-commerce data, while another could focus solely on image processing.

Windows Client

The Perfion Windows Client is lightweight, meaning it can run efficiently even on older or smaller PCs without significant performance issues. Please refer to the System Requirements for the general minimum requirements.

For general use, typical memory consumption is less than ½ GB. However, there are specific scenarios where performance may be impacted. If a user is tasked with producing large catalogs or working with very large datasets on-screen, memory usage can become a limiting factor. In such cases, performance bottlenecks can be easily identified using the Windows Task Manager.

Web Client

Using the Web Client significantly reduces the requirements for the host device, as the only necessity is having an updated browser installed.

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

Scheduler

If the scheduler is a key component in the Perfion solution landscape, it can be installed as a service on any server with access to the database. However, it is often placed on the same server as the API and/or web client. While this is not inherently problematic, the CPU/memory consumption of the scheduler depends entirely on the volume and complexity of the scheduled tasks. If large or numerous operations are scheduled, it may be advisable to offload the scheduler to a separate server to ensure optimal performance.

E-Commerce Connectors

Each of our standard E-Commerce Connectors requires the setup of a dedicated service. Similar to the scheduler, this can typically be hosted on a shared server, as many use cases won’t demand significant hardware resources. However, actual usage can vary considerably, so it's always recommended to monitor the connector during the test phase to identify any potential performance issues and ensure smooth operation moving forward.

ERP Integration Modules

The installation of the Perfion ERP modules for Dynamics or SAP rquires only a minimal footprint within the ERP system with no special sizing considerations. The primary concern would be whether the ERP users might place additional strain on the Perfion API, depending on the volume of interactions or the complexity of the data being processed.

Asset Portal

The Perfion Asset Portal is a standalone component and should generally be hosted on a separate server. This is due to the potentially compute-intensive nature of converting and scaling images, as well as the memory demands associated with handling large video files. However, in typical usage—where only incremental changes or additions to the image and file libraries occur—the system's requirements remain relatively low. For more detailed specifications, please refer to the separate requirements document for the Asset Portal.

Supplier Portal

The Supplier Portal is a central SaaS solution, meaning it is always hosted by Perfion in Azure, and monitoring/scaling are handled by Perfion.

Naturally, the actual data transfer speed to and from the Perfion database will be influenced by the API and database configuration of the individual customer, as discussed earlier.