One of our customers shares their experience with deploying a distributed setup with Wisej. They have been working on an E-Learning platform with content created using H5P (seee https://h5p.org) and PDF. Wisej is used to develop the E-Learning front end (displaying and navigating through the content) as well as an administration and management backend based on EntityFramework connected to a single Microsoft SQL Server instance.
Here is what they experienced:
We have been building our system in a single-host setup. Since our application will see a lot of concurrent users from lots of countries we had to design it with multiple instances/servers and load balancing in mind. Localization of the front-end was also important.
An additional requirement was to have the whole deployment process as automated and simple as possible so that in the event of a sudden increase in users (and thus CPU and RAM usage), we could add more servers and deploy the app within hours or even minutes.
The Wisej app instances are hosted on Windows Servers using the Wisej.HostService utility. This allows for quick and easy deployment of the app itself, as all we needed to do was getting the binaries of our app onto the server machine and running a PowerShell script that installs and runs the Wisej.HostService as a Window service. Since we had no idea how much resources (RAM, CPU, bandwidth, …) our app would be using and how stable it would be with lots of users, we planned to have 5 instances of the app on one machine. This would have provided some redundancy in case one of them crashed or was busy/irresponsive for some reason.
When trying to get Wisej.HostService running I encountered a rather obscure problem: Since we did not install/configure ASP.NET, IIS, etc., we were missing a directory which was vital to get Wisej.HostService to run correctly. There is a thread about this here. Essentially, all that was needed was creating the directory “C:WindowsMicrosoft.NETFramework64v4.0.30319Temporary ASP.NET Files”. After that, it worked without a hitch.
Load balancing was done with a rather simple nginx setup on one master Linux machine that functions as reverse proxy for the Wisej app instances. One catch with this was that Wisej requires persistent (“sticky”) sessions, i.e. one user must always be connected to the same upstream Wisej instance once he starts using the app. However, sticky sessions themselves are not part of the open-source version of nginx.
An alternative solution that I had tested at first was client IP-based load balancing (called “ip_hash” in nginx). This would have led to a single client IP always connecting to the same upstream server. It works, but had one downside: Many of our visitors are connected to their corporate networks which are often behind NATs, so they appear to the nginx server as coming from the same IP. All of these visitors would have been assigned to the same upstream server, which is of course not what we wanted.
In the end, we decided to go with the commercial nginx plus and configured its sticky session functionality, which is based on a cookie that identifies the upstream server. This turned out to work very well and has not given us any trouble since.
As I mentioned earlier, we had no concept of how the app would behave once thousands of users started their online courses. To monitor the performance of the individual instances, I implemented a small server monitor (again in Wisej) that monitored how many sessions a particular instance has and how much RAM/Threads it used. This allowed us to keep an eye on the instances and also discover memory leaks and other problems. In the end it turned out that our app (and Wisej) is actually pretty light on system resources.
At no point did the RAM or CPU spike to dangerous levels, even with hundreds of concurrent users. It also did not crash or hang once.
To sum up our experiences with Wisej I can say that it works pretty smoothly and is not a resource-intensive framework. During the development and deployment of our app we encountered some minor issues, but we were able to resolve all of them, and now our web-app (and Wisej) have proven themselves to work quite nicely even with many users.
Given the ease and productivity you see when developing with Wisej, it is almost surprising to see that deployment and load balancing can be accomplished in such an easy and straightforward way. If you look at other frameworks, they ususally have complex white papers on this topic that make performance tuning and multi-tenant/multi-server setup a complicated task. Wisej is refreshingly different and straightforward even when it comes to large-scale deployment.
Thanks Marian, for the kind words and for sharing your experience!