Kirk,
I think this is very interesting but what I was wondering
is could I just plug any VM into this architecture? It seems
you're providing a parallelization of these VMs and unless
I'm offbase I would think you need to modify the VM itself
to support this type of IPC between the VMs. This may or may
not be an issue for some but unfortunately would be a problem
for us.
Thanks,
John Harby
>From: Kirk Pepperdine <[EMAIL PROTECTED]>
>Reply-To: A mailing list for Enterprise JavaBeans development
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Entity beans, clistering and scalability
>Date: Fri, 9 Feb 2001 13:38:35 -0800
>
>----- Original Message -----
>From: "Evan Ireland" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Friday, February 09, 2001 6:04 AM
>Subject: Re: Entity beans, clistering and scalability
>
>
> > Jeff Schnitzer wrote:
>
>
> > >
> > > Pardon my (perhaps) naivete, but why on earth would starting multiple
> > > VMs on the same box increase scalability? It would seem like you're
> > > just going to consume a lot of extra resources, when all you really
> > > should need to do is start more threads.
>[snip]
> > >
> > > Please tell me what I'm missing.
>
>Where should I start.... 8^)
>
>One of the steps in tuning a VM is to determine the maxumum number of
>threads that it will support before performance bogs down. It will bog
>down for a number of reasons to do with thread management. Depending
>upon you're applications footprint on the VM, you'll typically see VM
>performance degradation at about 70 threads. I believe that the number of
>VM threads is a tunable paramater in WL (which ties into their clustering).
>Gemstone/J also tried to control this but using a different mechanisum.
>The other factor that affects performance is the size of the VM. These
>two factors by them selves indicate that heavier applications will do much
>better if they utilize more than one VM. This corrolates well with my
>experiences tuning EJB applications. FWIW, I've never seen a single VM
>even come close to tapping out an E10K.
>
>From my vantage point, the vendors that are making scalability claims
>support
>multiple VM deployments. The question is, which mechanisums, work, are
>easily configurable, easy to deploy, and really do offer a performance
>advantage.
>Oh and BTW, do they help with stability and avaliability. For instance, if
>you're
>single VM blows, then what?
>
><vendor>
>I didn't use these tags in the previous paragraph because that was straight
>java stuff.
>GemStone/J has the capability to launch several VM's on the same hardware
>in the same ip space. It does this out of the box with no special
>requirements
>for hardware or software to support this functionality. I contend that
>administrators
>love this because, the can contain the entire application server on a
>single
>piece of
>hardware if they so desire without setting up separate ip spaces. The VM
>pool
>sizes adapt to changes in the load on the system. A single VM/ip space
>strategy
>cannot dynamically add more ip spaces and consequently cannot dynamically
>launch more
>VMs.
>GSJ's VM pooling also helps with stability and availability as old stale
>VM's can
>be rolled out of the system seamlessly. The application server can support
>different
>versions of the same application running at the same time. This offers a
>very flexible
>migration possibilities. You can upgrade the application without having to
>take down
>the system.
>
>Point is many of these things are easy because of how the systems supports
>multiple
>VMs.
></vendor>
>
>Kirk
>[EMAIL PROTECTED]
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
