Wednesday, December 22, 2010

REAL Studio Web Edition Status

Since the release of REAL Studio 2010r5, we've been receiving lots of questions regarding deploying Web applications. They have come from the forums, our mailing lists, sent to our customer service and tech support contacts, as well as directly to my inbox. So here is a kind of status update regarding Web Edition, as well as some background information, and possibly assistance with getting your application deployed once we have made r5.1 available.
I see two main deployment issues:
  1. Some/many shared hosts are not able to support this yet. Some do though, and we expect more to over time. Currently, the most cost-effective way to deploy is using a VPS, unless you've found a shared hosting package that works for you.
  2. FastCGI has a few bugs.
A few days before we shipped, it was discovered that apps deployed as FastCGIs could take up 100% of the CPU. Obviously, that's not going to work.
From past experiences with Cocoa, delaying the release was not an option. If we delayed, users would be upset anyway. A "damned if you do, damned if you don't situation." We decided to get this into our users hands and do a r5.1 release.
The good news is that FastCGI is much improved in r5.1. We ran an internal test of the Chat example last night on a CentOS 5 + Apache server using Dynamic FastCGI. Aside from a couple minor issues that need looking into, it performed wonderfully. Average CPU was 0%, RAM at 8MB. The app did not crash, it handled all requests perfectly. We were very pleased.
This test also revealed another configuration requirement though. By default, the FastCGI process manager will spawn additional instances of your application at its will. This is a problem for our applications, as state information is stored in memory. When this happened, although the apps were functioning, the client-side experience fell apart terribly. To prevent this, here's what I added to our Apache config file:
FastCgiConfig -minProcesses 0 -maxClassProcesses 1
Basically, this line tells the process manager that it is allowed to have no app running (for when no users are connected and the app is not needed) and is allowed to run only one instance of each app.
We intend to have a r5.1 beta available to the beta program in time for the holidays. We'll be collecting feedback over the holiday break, and intend to have a r5.1 release in January. As with all point releases, r5.1 will be available to anybody eligible for r5.
The new config options will be added to the wiki at some point, and we intend to setup demo apps on our website. However, these things may not happen until after the holidays. In the mean time, here's everything I did to get an app deployed.
  1. Purchased a new dedicated server from InMotion Hosting. A VPS would work just as well once this is stable, but for our testing, we want a dedicated box where we can control every variable, and not cause problems for other users on the same server should our app eat up all resources or something. It is a CentOS server with cPanel installed, very similar if not identical to the average hosting package.
  2. Downloaded and installed mod_fastcgi. This requires root access, so either get root access or ask Tech Support for assistance. For me, it was very easy, but not everybody is as comfortable with the command line.
  3. I modified /usr/local/apache/conf/includes/pre_main_global.conf. This can be done via command line, or through WHM. I added two lines:
    LoadModule fastcgi_module modules/
    FastCgiConfig -minProcesses 0 -maxClassProcesses 1
  4. Restarted Apache
  5. Uploaded an app using FTP as if it were any other file.
  6. Set the app as executable. This can be done with any good FTP client.
  7. Added an .htaccess file to the directory containing my app:
    Options +ExecCGI
    AddHandler fastcgi-script .fcgi
  8. Visited the URL for my app to test. The URL will be dictated by the directory structure you uploaded your app to.
One last bit of information this test unveiled is that default installations of cPanel will relaunch Apache every 2 hours. When this happens, your application will be stopped as well, and your users disconnected. We are investigating a solution to this issue, but that solution will NOT make it into r5.1. In the mean time, the only solution we can offer is to disable log processing, or at least slow down the rate at which logs are processed. This can be done using WHM, under the "Server Configuration" section, look for the "Statics Software Configuration" option. There is a thread on the cPanel forums about this issue at for those interested.


MGV said...

Thanks for doing this - it seems to be everything I wanted - so now I just have to try and get some apps going with it.

Can this run as a virtual host under apache if you are running multiple domains?

This would allow one server to do normal web hosting but have a subdomain running only as Web edition program?

This is probably most relevant if you are already running your own server (which I am)..


Thom McGrath said...

Yes, aside from the LoadModule directive, the others can all be placed safely into a VirtualHost block.

Derk said...

How can i install mod_fastcgi ? i cant seem to find any usefull how-to information on google. Im using apache 2.2.x Plesk 10.1.x


Thom McGrath said...

The download for mod_fastcgi has instructions. Look in INSTALL (or INSTALL.AP2 for Apache 2) for details.

Basically, you'll run two commands: "make" and "make install". If your Apache directory is in a non-standard location, you'll need to add a top_dir assignment to those commands.

waveuponwave said...

How is the installation of mod_fastcgi different if you are using apache on windows? Thanks for the blog update.

Thom McGrath said...

I don't do Windows servers myself, but a quick Google search reveals which looks quite a bit more involved, but still possible.

waveuponwave said...

Thanks for the reply Thom. I have already tried using the .dll download from for apache 2.2 and I cannot get it to work properly using apache on windows. I had already tried all of the steps you have mentioned in your guide. Is there some reason I should try to create my own .dll from the INSTALL info?

tkaltschmidt said...

Being not able to spawn processes (the way FastCGI is used widely), will this not have an impact on Web-Performance? What happens when 20-100 users likes to access the Web-App?

best regards

waveuponwave said...

For all of you trying to use web apps with Windows. Forget this information, go here instead:

Data Concepts said...

Hey despite issues, this technology is going to be sweet very soon.

Anyway, been working trying to get a working solution on another host. We are still working on it. If it goes through we will write it up.

On a VPS, we have the app loading however it loads slloooowww and then once displayed, locks the CPU at 100% as mentioned here.

Plugging along.

waveuponwave said...

I wrote a step by step guide on how to get web apps working using apache tomcat on windows. This is currently the best windows deployment solution I know of.

hiprince said...

Hi guys, I noticed that you've encountered a problem that fastcgi worker is using nearly 100% CPU but doesn't response to any requests in your R5 version product. Recently I ran into the same issue. Could you please let me know how do you fix this in your R5.1 release? Thank you!