On Mon, 25 Aug 2008 12:23:49 -0500, Gary M. Dennis <[EMAIL PROTECTED] com> wrote:
>Assumptions: > >0. A VM server machine > >1. A cluster of client virtual machines (possibly thousands) > >2. n buffers are allocated for each client virtual machine > >3. Each buffer contains table elements that require > (a) Element ageing > (b) Element deletion when invalidated by: > 1. lack of use > 2. client machine request > (c) Compression as buffer fragmentation occurs > >4. Each client virtual machine in the cluster is connected via IUCV to t he >server virtual machine. > >5. IUCV traffic between the server machine and client machine is extreme ly >low volume. Initial call, termination call, intermittent statistics cal l. > >6. After the initial call, the server virtual machine will maintain the >buffer table entries in each client virtual machine without additional I UCV >interaction. > >Now the questions: > >1. Does IUCV infrastructure overhead specifically associated with number of >connections become prohibitive at some well known point? > >2. Has anyone had experience with an application having a high IUCV >connection count like this? If so, what was that experience? > >Again, the traffic incidence per connection is very low but the number o f >connections is potentially very high. > > >Thanks > > >--. .- .-. -.-- > >Gary Dennis >======================== ========================= ========== ============== If the volume is that low, you could use the old paradigm used by many VM applications (OfficeVision, for example), use the virtual reader as a queue and the vi rtual punch (or CMS SENDFILE) as the requester. Can go both ways, too. This is the ancestor o f MQ. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
