NexusCore: Technical specifics

NexusCore - .NET Core for cPanel & WHM > Technical guide

Technical specs

This page will list the technical specifications on .NET Core. The technical specifications will be written in a comparison-form, comparing every detail with the way it’s done in PHP. This way you’ll be able to recognize all difference accross the (technical) board when it comes to NexusCore and cPanel + WHM. You’ll be running .NET Core like an expert in no-time.

This page was created to offer an in-depth explanations of the inner workings of .NET Core on Linux, as well as how this compares to PHP. The content below is not suitable for end-users, but was instead tailored to IT professionals.

PHP version versus .NET Core runtime

On a normal WHM+cPanel installation you will be offering PHP to your hosting customers. As you well know, PHP has different versions you can run (from 5.4 to 7.2 at the time of writing). In WHM you have to assign users a PHP version to use for their hosting account (or let them choose themselves).

In the .NET Core world this works a bit different. Our installer automatically installs all runtimes (.NET Core 2.0, .NET Core 2.1, new ones will automatically be added). With NexusCore you do not specify the version a hosting package will support, in stead the customers application will specify the .NET Core version required for his application. In a typical .NET Core project they will have an appsettings.json file that contains the version the user wishes to support as can be seen below.

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>
</Project>

If the user selects a .NET Core runtime that does not exist on the server, the user will be presented with error messages. The .NET Logs will then show “Your application is running a version that is not support”. In reality this will not happen if your customers are using stable builds of .NET Core (NexusCore does not support preview runtimes to prevent stability issues).

Serving PHP or .NET Core

PHP / HTML is served by the Apache (or Litespeed) web server on a regular cPanel + WHM setup. Apache is responsible for parsing the request and handing over the PHP code to the PHP interpreter and then returning the final result to the site visitor.

With .NET Core this works differently. Compiled code is served by the Kestrel Webserver, proxied through Apache. Kestrel is responsible for executing the .NET Core code. Kestrel is not directly reachable through a public interface, but in stead requests are proxied through Apache.

Kestrel will be running on 127.0.0.1:[port] for every application. Kestrel has an auto-restart and auto-healing feature where application that crashed (this is possible with .NET Core) will be restarting where needed.

Below you’ll find a schematic view of the difference between PHP and Kestrel.

(Schematic view of .NET Core hosting versus PHP hosting)

PHP File upload versus .NET Core deployments

With cPanel & WHM it is easy for customers to deploy a new PHP application. They start up their FTP Client and start uploading files to the public_html folder, or they use the file manager.PHP is an interpreted language, and because of this PHP is parsed every page load. this is a great (and fast) way of working

In the .NET Core world, this works differently. The .NET Core language is a compiled language, meaning that an application has to be compiled before uploading it. Customers typically compile applications on their local machines using an IDE like Visual Studio 2017, or Visual Studio Code. The result is a collection of binaries (.dll files) that is uploaded to the public_aspnet folder in the users’ home directory through FTP. The .NET Core runtime will then reload the application and serve the ‘new’ application.

(typical list of files deployed as a .NET Core application)

Performance tuning

.NET Core is different than PHP or other interpreted languages have the upside of not staying in memory very long, just the duration of the interpration will cost CPU cycles and memory. With .NET Core this is different. Kestrel web server will take a bit of memory and CPU while the application is running (continuously). On top of that, .NET Core is a completely different beast when it comes to applications.

In PHP we have the “max_execution_time” and “memory_limit” php.ini directives. In .NET Core there are no such things (for now). This means that users can possibly run applications that spin up a number of long-running background tasks, reserve big blocks of memory (e.g. reading a 2GB file in memory) and do other stuff that’s not really possible with PHP (unless limits have been changed).

We advise you to run .NET Core in production environments on CloudLinux. CloudLinux has the unique feature of being able to sandbox users’ resources through use of the LVE (Lightweight Virtual Environment), basically limiting users’ resource usage straight from the kernel.

Where you would be able to offer 500 users shared PHP hosting, the ceiling for server resources might lie a lot lower when offering .NET Core. We have no real-world benchmarks yet, but will add them once we have them!

NexusCore manages most of it!

All of the concepts that surround .NET Core might be new or strange to you, but don’t worry; NexusCore handles all the aforemended .NET Core hosting work. You only need to install the plugin and let NexusCore run its course for you:

Automatically provisions Kestrel for accounts with .NET Core
Automatically listens for ‘application deployments’ to restart Kestrel
Sets up system services (systemd) to (re)start .NET Core applications
Disables kestrel if a hosting account is demoted to PHP hosting
Enables kestrel if a hosting account is promoted to .NET Core hosting
Guides users through their deployments