Java Hosting Generally Sucks

by Steven J. Owens (unless otherwise attributed)

I've been off in corporate consulting land, so I haven't been keeping as up to date on java servers as I'd like, but in a nutshell, there is no effective java shared hosting option, the way there is with, say, apache/php.

So that leaves colocations, and lately VPS hosting. VPS stands for virtual private server, not to be confused with virtual hosting. In virtual hosting, you appear to have your own web server and often the server is set up so that at the shell login level you appear to have your own box, but in reality you're using the same OS as the other virtual hosting customers, and if their screwed up code takes the OS down, they take you down with it.

The closest thing to a virtual private server that most people have experienced is (depending on your favorite desktop OS) a vmware or parallels image. In web hosting it's usually implemented with something like Xen or User-Mode Linux. In this case, it is literally a virtual server instance, a simulation of a server, being run on the same hardware as other simulations.

Whatever you use for java hosting, you pretty much have to have your own java server process. Even though almost all servers can support mutiple applications/sites, you can't trust some other user's code not to muck it up and burn up too many resources. JSR-284 might change this (and Google's one of the forces behind JSR-284, so it's a very real possibility; note from about a year later, nope, not anytime soon).

I'm personally a little skeptical of VPS, mainly because I had a bad experience with a supposed colo that, it turned out, even though we were renting the hardware from them, they were running the entire system on some sort of virtualization scheme, because they used the virtualization app for server configuration management.

This was the experience that convinced me that there's no real java analog to web hosting available.

The most you can get, which is what we got, was renting colo hardware, so at least that way you knew that the provider had a room full of hot-swappable spares and a good process to swap in the OS, etc, quickly if the hardware explodes.

But you really have to do your own application server management, figure out and set up your own app server configuration, maintain your own backups, etc. Of course, the latter (backups) is a truism for most web hosting as well, but then again, people generally use java for more serious applications and either they or their customers have more stringent organizational requirements for backups, etc.

I'm hearing a lot of good things about Glassfish, an open source application server based on some code that Sun donated to the community. Glassfish v3 is supposed to do some clever things with library loading to manage memory better, and have better support for shared hosting.

Also, the recent opening up of the java licensing and the subsequent availability of GPL java in the package management of various linux distros should mean java will start just "showing up" by default on a lot more hosting platforms, so that may turn out to be another pressure pushing towards better java hosting, out there.

OSGi also looks like a really interesting alternative.

Also see this excellent comment at:

In theory he's wrong on some points (e.g. the servlet spec has included the option for unloading servlets to free up resources since day one), but in practice he's right (AFAIK nobody actually does that).

The problem here is not the hosting companies, it's Java.

Save on a virtual server, there is no safe way to deploy in to a shared VM. None of the major VM vendors provide the control and safety that shared hosting really requires.

Also, Java hosting is resource expensive as well compared to others. Even if we had a good shared VM model, it's still expensive to host Java applications.

With box stock JSP and servlet, everything gets loaded in to the VM and thereby consumes some amount of memory. Most JSP implementations even load the entire page text in to memory as well. That's all well and good, but the problem is simply that once loaded, these artifacts tend to STAY in memory.

So, now consider the classic cheap virtual hosting solution with a single Apache instance fronting PHP for several hundred lightly used web sites.

PHP loads things on the fly, interprets them on the fly, and throws things away. That's one reason why PHP folks need to jump through hoops to increase performance. It's always being reloaded, reinterpreted, and tossed out for each page hit.

The benefit of this is that you can scale your memory burden to the TRAFFIC that the site gets. That's the perfect model for overselling a HTTP Virtual Server host, since most sites get very little traffic.

In the Java model, however, if you have 1000 different sites, and each one get a hit once a day, that's 1000 JSPs that are loaded in the VM and that, typically, STAY in the VM all day long. That means that someone who got a hit at 1am is still impacting the server 12 hours later at 1pm simply because the JVM doesn't do a good job of unloading classes and what not.

In the PHP model, that 1am web hit came and went, never to be heard of again.

So, that means that a Java site needs to be scaled to the number of ACCOUNTs on the site, rather than the actual TRAFFIC to the site (regardless of the accounts).

That's a different revenue model.

Then there's also the safety model. It is trivial to write a piece of Java code that can destroy a VM, suck up all of it heap. Once that's done, the VM needs to restart -- and this affects all of the users of the VM, rather than the malcontent who wrote the bad page. In PHP, a bad page is a bad page. System reaches internal limits, kills the process, Apache restarts it, and a single user has much less affect on other users.

All of these factors weight against Java as cheap hosting solution. I think it would take a great amount of reengineering, both at the VM level AND at the container level to mitigate these issues and make Java friendlier to the bulk hosting providers.

Also see whartung's comment here, somewhat redundant but goes into a little more detail on some things:

Feedback

Verification Image:
Subject:
Your Email Address:
Confirm Address:
Please Post:
Copyright: By checking the "Please Post" checkbox you agree to having your feedback posted on notablog if the administrator decides it is appropriate content, and grant compilation copyright rights to the administrator. Message Content: