server technical spec

Its really dependent on whether you are integrating your scene into an existing environment or building one from scratch and of course the server load of your V3D application.

When V3D is delivered via the web it can be treated like any other website for the most part. You can determine your bandwidth needs using standard web dev tools in chrome and then determine the concurrent load your server can withstand given the app’s needs. Because scenes can load various content, other scenes, textures, videos, pdf, etc…it is often best to put dynamically called content on a CDN that can handle large loads efficiently. Separating these loads from your main server loads.

Typically it’s stated that a single-core CPU can handle roughly 200 concurrent users but again this is based on what your app is really doing and the hosting environment and pipe/bandwidth it has but in general its a good reference point.

We utilize virtual servers in most of our implementations that scale as needed for our clients to meet any user load that hits our clients sites. This of course comes with a large price tag but a lot cheaper than planning for 100,000 concurrent users and only getting 1,000 with traditional implementations.

If you have a game where the chances are high that you could have lots of concurrent users like its typically solved by the user having to select a server, a realm or a map that is hosted within a zone to prevent server overload.

For applications where we know there are going to be large number of concurrent users we design an architecture that has virtual servers and multiple CDNs based on geographic locations. These are often broken into countries or country regions. These sort of setups require a teired architecture and synching so that you only update one and the rest update accordingly.

As far as hardware specs…I really can’t offer you too much advise without knowing the app. You can find a number of resources online that will guide you in your decision. You will have to determine your points of failure and determine what your levels of risk are for downtime. A single multicore webserver for a professional system would not be a wise selection as power supplies, motherboards etc will fail at some point so keep redundancy in mind. If you are going to host this in a professional hosting service they can help you out and run tests for you to help you select the best options. If you plan to stuff this in a closet at work and run it yourself then you need not worry about the load as much as you need to worry about up time. Limit your concurrent users to what you know you can handle….throttle it up slowly until it fails…then back off that limit and run it as long as you can.

Sounds like a great project.

I would start by looking at the sites current analytics and gauge the number of concurrent users they currently have and what has been the years progression in order to forecast an expected concurrent user load for the next 12 months. You will also want to determine what marketing/trafic drivers are and those release dates. This will allow you to know when loads are expected and how to plan for them.

If their IT team will provide it they can give you a current load to user ratio and you can determine how many visitors they get at their peak and how much buffer their current servers has left.

For most clients like this there are typically two or three environments: Prod, Staging and Dev. What I would do is get the app on to staging server and then have an outside company conduct load testing a few weeks before launch so you can adjust the Production environment to meet your actual performance needs.

The good news is your client should have plenty of funds to support their efforts. Congrats.