There are more and more questions about how to install Arena server in a way to make it accessible to a federation’s fans, wrestlers, people who are interested about wrestling results (eg. #37). Such a setup requires to use the Arena’s built-in synchronization capability and one or more Arena’s could “push” data to a central repository.
The current Arena configuration is designed to serve all the requirements at an event, but not designed to accept high number of requests at the same time. However considering to some recommendations it is possible to establish similar service to https://arena.uww.org website.
The aim of this article is to encourage every user who has already been working on their implementation to share their experiences, or even detail their setup steps, thus provide a best effort support to our new users who are planning to do the same.
Since there is no a “single-good” solution, everybody can have slightly or even completely different configuration, which is completely OK.
Here are the basic guidelines everybody must consider:
Content caching:
Depending on the concurrent requests Arena server must process, it’s recommended to put a proxy server in front of Arena. This proxy can take some load off from the server (especially to resources like images, contents changed very rarely) thus more visitors can be served at the same time without additional computing power on the server.
As a disadvantage to this solution, some information might come from “cache” when the data behind it has already been changed/updated. This can be controlled by finding the balance between a realtime resource rendering (a page is re-computed every time when it’s requested) and a cached content (computed at first request and the same content is delivered to any subsequent similar request for X minutes). This is called as Time-To-Live (TTL) in this context.
Hosting:
Arena is an appliance and running in a virtualized environment. It’s strongly discouraged to use it by exporting it to a new environment especially as service providers can support operating such an appliance. However based on the required computing power of an appliance, SP may offer different price plans according to the CPUs, network bandwidth, other hardware capabilities. By default the Arena VM is configured with 2 CPUs and 40GB of hard disks. This is the minimal specification, which can be increased if necessary (and depending on the utilization of the server). We do not recommend to go beyond that (in terms of number of Arena servers) which would require more advanced setups and operation.
Security:
It’s also recommended to review the current security setup of Arena. Since it’s designed to operate under a controlled environment (within an isolated network at the event), an Internet facing instance of Arena requires hardened network and application security.
Backups:
It’s strongly recommended to run regular backups of the database running behind Arena.
Version control:
Arena has its own version management module. Whenever a new application version is released every Arena system gets notified about the upgrade capability. Although we do our best to verify and validate all the new features a version contains, it is possible to introduce bugs in these new versions. Having a “pre-production” system where the new version(s) can be tested is essential to avoid unlikely situations during event. However it’s important that the server version must be identical with the client(s) we use in synchronization.
Keeping these recommendations can help successfully operate a public version of Arena.
Let’s share your experiences here!
There are more and more questions about how to install Arena server in a way to make it accessible to a federation’s fans, wrestlers, people who are interested about wrestling results (eg. #37). Such a setup requires to use the Arena’s built-in synchronization capability and one or more Arena’s could “push” data to a central repository. The current Arena configuration is designed to serve all the requirements at an event, but not designed to accept high number of requests at the same time. However considering to some recommendations it is possible to establish similar service to https://arena.uww.org website.
The aim of this article is to encourage every user who has already been working on their implementation to share their experiences, or even detail their setup steps, thus provide a best effort support to our new users who are planning to do the same. Since there is no a “single-good” solution, everybody can have slightly or even completely different configuration, which is completely OK.
Here are the basic guidelines everybody must consider: Content caching: Depending on the concurrent requests Arena server must process, it’s recommended to put a proxy server in front of Arena. This proxy can take some load off from the server (especially to resources like images, contents changed very rarely) thus more visitors can be served at the same time without additional computing power on the server. As a disadvantage to this solution, some information might come from “cache” when the data behind it has already been changed/updated. This can be controlled by finding the balance between a realtime resource rendering (a page is re-computed every time when it’s requested) and a cached content (computed at first request and the same content is delivered to any subsequent similar request for X minutes). This is called as Time-To-Live (TTL) in this context.
Hosting: Arena is an appliance and running in a virtualized environment. It’s strongly discouraged to use it by exporting it to a new environment especially as service providers can support operating such an appliance. However based on the required computing power of an appliance, SP may offer different price plans according to the CPUs, network bandwidth, other hardware capabilities. By default the Arena VM is configured with 2 CPUs and 40GB of hard disks. This is the minimal specification, which can be increased if necessary (and depending on the utilization of the server). We do not recommend to go beyond that (in terms of number of Arena servers) which would require more advanced setups and operation.
Security: It’s also recommended to review the current security setup of Arena. Since it’s designed to operate under a controlled environment (within an isolated network at the event), an Internet facing instance of Arena requires hardened network and application security.
Backups: It’s strongly recommended to run regular backups of the database running behind Arena.
Version control: Arena has its own version management module. Whenever a new application version is released every Arena system gets notified about the upgrade capability. Although we do our best to verify and validate all the new features a version contains, it is possible to introduce bugs in these new versions. Having a “pre-production” system where the new version(s) can be tested is essential to avoid unlikely situations during event. However it’s important that the server version must be identical with the client(s) we use in synchronization.
Keeping these recommendations can help successfully operate a public version of Arena. Let’s share your experiences here!