On 4/6/06, Preston L. Bannister <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
isn't it easier to give each user a pre-configured lightweight
but own
tomcat?
leon
On 4/6/06, Preston L. Bannister <[EMAIL PROTECTED]> wrote:
Well, that is one definition of "real applications". There are
other
definitions. :)
On 4/6/06, Tino Schwarze <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
