tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leon Rosenberg" <rosenberg.l...@googlemail.com>
Subject Re: Challenges for Java hosting
Date Thu, 06 Apr 2006 21:48:56 GMT
On 4/6/06, Preston L. Bannister <preston@bannister.us> wrote:
> Define "lightweight". :)

only the basics you need for a webapp. no admin/manager, no
clustering, no gadgets.
To explain it:
Besides large portals with own server farms and millions of hits, I
often have small customers which get a dynamical website with some cms
etc. The problem I had and still have, is that typical hosting
providers (at least in germany) don't offer any support for java
webapps, best you can get is support for jsps only which sucks. This
is ugly, since the customer pays money for the webapp and asks me
afterwards, why should he rent a complete server to host it. Therefore
I started to rent servers myself, and re-rent it to the customer. The
customer gets the complete package, mail, backup, ftp/ssh access and
the webapp. To ensure this, each server has an apache running with two
jsp container instances on it, one for production, one for testing
versions. The customer pays less than he would pay for "professional"
hosting, and I can refinance the server with 3-4 customers. However,
having all test-webapps in one server, and needing to restart it from
time to time isn't really cool. I'd prefer to give each customer two
instances, which consumes low resources, maybe even multiple tomcat
instances in one jvm (is that possible?), and keep them independent
from each other. Therefore lightweight. And therefore pre-configured
:-)

regards
Leon

>
> If we are talking about a small number of users, with high average
> utilization, this might be a good solution.  In fact this is similar in
> resource usage to the virtual hosting (i.e. Xen) solutions.
>
> For more typical usage, the number of users is large, and the average
> utilization is low.  In this case one (very rarely used) JVM per user is
> somewhat expensive.
>
> Note you could reduce the expense with the same approach of using a fork()
> of a single image, expecting copy-on-write to radically reduce the real
> memory use (virtual memory use would be larger).
>
> Depends on what target you are trying to hit.  The hosting world (by numbers
> of users) is dominated by very low usage sites.  Is this a goal for
> Java/Tomcat hosting?  If you can beat PHP in CGI mode *both* in performance
> and in resource usage, then you have a pretty compelling solution.  If you
> are fatter or slower - this is going to disinterest a lot of hosting
> providers.
>
> Note that this notion is pretty much a non-starter if Linux does not do
> copy-on-write with fork().  This was a big deal back in the late 1980's (big
> Lisp apps forking "vi").  Don't know if this made it's way into Linux.  I'm
> pretty sure copy-on-write in fork() was in SunOS, but I don't know about
> Solaris.
>
>
> On 4/6/06, Leon Rosenberg <rosenberg.leon@googlemail.com> wrote:
> >
> > isn't it easier to give each user a pre-configured lightweight but own
> > tomcat?
> >
> > leon
> >
> > On 4/6/06, Preston L. Bannister <preston@bannister.us> wrote:
> > > Well, that is one definition of "real applications".   There are other
> > > definitions.  :)
> > >
> > >
> > > On 4/6/06, Tino Schwarze <tino.schwarze@tisc.de> wrote:
> > > >
> > > > On Thu, Apr 06, 2006 at 09:15:17AM -0700, Preston L. Bannister wrote:
> > > >
> > > > > You have to consider how (or if) to allow for long-running
> > background
> > > > > threads.  Successive requests for the same user will not use the
JVM
> > > > > (whether this counts as an advantage or disadvantage is
> > debatable).  The
> > > > JVM
> > > > > isn't going to be optimizing code.
> > > >
> > > > The point of using an application server (instead of e.g. PHP) is that
> > > > it maintains state on the server. You lose this by using fork(). So
> > it's
> > > > not going to work at all for real applications since your application
> > > > "returns" to it's previous state after every request.
> > > >
> > > > Bye, Tino.
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > > >
> > > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message