Best deployment strategy for PlayFramework applications?

Question

This question is server oriented. I have a hosted server (a rather small one, 1,6Ghz atom, 2Go, 200 GO) with a couple (4 or 5) play apps and more coming. Most of these apps have a real small usage, let's say a hundred requests a day each.

1. Is it better to deploy each of those applications using the embedded server of Play! and thus use 64mb of memory for each application?

2. Or deploy a Tomcat with all the applications inside the tomcat? With a bigger memory shared by all the apps?

EDIT :

I'll add a little further information about my situation. The server also hosts :

• About 10,15 PHP websites on Apache2
• A SVN server going through Apache mod_dav_svn
• A tomcat used for Sonar
• A standalone installation of Jenkins (via Jetty)

My original plan was to deploy all these stuff in Tomcat. Having the apps, Sonar & Jenkins running on Tomcat and Apache2 for static ressources. (Images, scripts)

COMMENT

Last point, I'm aware that having Sonar & Jenkins, Continuous integration systems on a production environment isn't really optimal. But since these are only running at night (automated builds) they are not overloading the system. Plus I'm a student, financially an additional "CI/build" server is out of my financial capacities.

Answer 1

The best approach is to use the included Play server, putting NGinx as reverse proxy in front of it to tackle all the redirection/request managing.

Why this and not Tomcat? You can start with this article that compares performance. An extra argument would be that Tomcat loads all the Java EE environment which Play doesn't require nor use, consuming memory and resources you want free for your apps (specially if you use in-memory caching).

On Nginx as reverse proxy, this should give a hint on why to use it instead of Apache.

EDIT (on question's edit):

In your situation, you can optimize your resources.

First replace Apache 2 by Nginx. Nginx can serve PHP, quite well (if you use Ubuntu see this). It will serve Play very efficiently, and can be used as proxy to Java servers.

Then you can move all your Java apps to Jetty, and get rid of Tomcat. Jetty consumes less resources in average, and even if your apps will only run at night, the server is still online and hoarding ram. The less it takes the better.

What about SVN? Sadly you will need Apache 2 and Nginx as reverse proxy to Apache 2. Why not to keep Apache then? The argument would be usage. In theory the PHP apps will have more traffic than the SVN server, which makes more relevant the resource consumption they have. With nginx, ram and cpu allocated to serve PHP will be less making your machine more responsive. Apache will only act when you use SVN, which will not be so often.

If you don't want to put the effort on moving stuff to Nginx (which I can understand), then just move Java apps to Jetty and use Apache 2 as reverse proxy for Play. But use Play embedded server, don't load the app in Tomcat. It will be more efficient this way.

Answer 2

The production deployments i'm running are using the Play embedded server. It makes life way simpler than Tomcat, especially redeploying - I run the servers under screen, and an upgrade consists of "Ctrl-C", "Up-Arrow", "Enter", executing:

% git stash; git pull; git stash apply; play run

With 2G of memory, I wouldn't worry too much about the per-process overhead. It's certainly a price worth paying to get rid of Tomcat's complexities.

(the git stashing allows me to have some non-git-committed configs lying around on production - more laziness than need, though :-))

Answer 3

I would start for each app a play-server. It's easier in configuration and easier to have separate log-files. Furthermore you can restart each app separately without problems. A redeploy on tomcat is often a job with results in errors.

Disadvantage: You must configure a reverse-proxy like lighttp to get nice urls like mydomain.org/app1 and mydomain.org/app2