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]
