Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

re direct memory drivers for Open-Client

3 posts in Product Futures Discussion Last posting was on 2002-03-06 17:49:43.0Z
Johan Posted on 2002-01-08 06:49:49.0Z
From: Johan
Date: Tue, 8 Jan 2002 01:49:49 -0500
Newsgroups: sybase.public.ase.product_futures_discussion
Subject: re direct memory drivers for Open-Client
Message-ID: <6C894AC05B64024A0025851985256B3B.0025852F85256B3B@webforums>
Lines: 33
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com!webforums.sybase.com!news
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:959
Article PK: 95200

A possible radical performer would be shared memory drivers for
Open-client.
I think this would be much more than simply a nice-to-have.

The client then does not go through the network layers (if local), and
communicates directly via shared memory.
This will only benefit clients on the same host as the server, but judging
on the performance it buys comparable products, it would be especially
benificial for back-end processes.
It also has the added performance benefit one could now get by having you
app server on the same E10K for example.

I thought it would a major engineering challenge, but I'm told it may be
less work than I thought.
I also understand that IQ has this already.

So basically this comes down to prioritising of engineering efforts.

For the performance improvements this could bring I think it's obvious that
this should be added soon.
We're talking order of magnitude for a single user connection, which won't
scale linearly to 100's of users, BUT:
It WILL benefit back-end tasks / batches etc hugely.
It will not scale as impressively with a large user-pool, but from testing
with other products still rules out a lot of overhead if you have a number
of local clients.

Backporting such a driver to 12.0 would be nice too, and would be welcomed
by a number of customers, who DO NOT currently realise how much faster
their back-end tasks can be.

Any feedback on this one from engineering ?

Johan


Carlos Ruiz Posted on 2002-03-06 17:21:48.0Z
Message-ID: <3C86502B.3C7CF424@sybase.com>
Date: Wed, 06 Mar 2002 18:21:48 +0100
From: Carlos Ruiz <cruiz@sybase.com>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Johan@sybase.com
Subject: Re: re direct memory drivers for Open-Client
References: <6C894AC05B64024A0025851985256B3B.0025852F85256B3B@webforums>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: sybase.public.ase.product_futures_discussion
Lines: 48
NNTP-Posting-Host: 158.76.170.28
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:743
Article PK: 94273

Hello Johan,

The shared memory driver exists in ASE 12.5. It works with
jconnect. The problem is that the connectivity guys do not have
any plans to port it to work with ct-lib. It was created for the
EJB. In any case, I think the difference in performance using it
was not that impresive.

Cheers

Carlos
-------------------

Johan wrote:

> A possible radical performer would be shared memory drivers for
> Open-client.
> I think this would be much more than simply a nice-to-have.
>
> The client then does not go through the network layers (if local), and
> communicates directly via shared memory.
> This will only benefit clients on the same host as the server, but judging
> on the performance it buys comparable products, it would be especially
> benificial for back-end processes.
> It also has the added performance benefit one could now get by having you
> app server on the same E10K for example.
>
> I thought it would a major engineering challenge, but I'm told it may be
> less work than I thought.
> I also understand that IQ has this already.
>
> So basically this comes down to prioritising of engineering efforts.
>
> For the performance improvements this could bring I think it's obvious that
> this should be added soon.
> We're talking order of magnitude for a single user connection, which won't
> scale linearly to 100's of users, BUT:
> It WILL benefit back-end tasks / batches etc hugely.
> It will not scale as impressively with a large user-pool, but from testing
> with other products still rules out a lot of overhead if you have a number
> of local clients.
>
> Backporting such a driver to 12.0 would be nice too, and would be welcomed
> by a number of customers, who DO NOT currently realise how much faster
> their back-end tasks can be.
>
> Any feedback on this one from engineering ?
>
> Johan


Roger Broadbent Posted on 2002-03-06 17:49:43.0Z
From: "Roger Broadbent" <RBroadbent@wilco-int.com>
References: <6C894AC05B64024A0025851985256B3B.0025852F85256B3B@webforums> <3C86502B.3C7CF424@sybase.com>
Subject: Re: re direct memory drivers for Open-Client
Date: Wed, 6 Mar 2002 17:49:43 -0000
Lines: 75
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID: <udKumgTxBHA.304@forums.sybase.com>
Newsgroups: sybase.public.ase.product_futures_discussion
NNTP-Posting-Host: wilcohost-180.wilco-int.com 212.36.174.180
Path: forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.ase.product_futures_discussion:742
Article PK: 94270

That would depend on what you were doing with it. For longer-running SQL
statements, there would be no discernible difference. For many smaller SQL
statements with little or no physical i/o, the benefits would quickly add
up. We have whole products whose performance is limited by the network
communication round-trip times. I would expect these to benefit
significantly from connection via shared memory. Mind you, they currently
use db-lib. The chances of a shared memory interface there are rather slim I
should imagine...

--
Roger Broadbent
Technical Consultant
Wilco International Ltd

Carlos Ruiz <cruiz@sybase.com> wrote in message
news:3C86502B.3C7CF424@sybase.com...
> Hello Johan,
>
> The shared memory driver exists in ASE 12.5. It works with
> jconnect. The problem is that the connectivity guys do not have
> any plans to port it to work with ct-lib. It was created for the
> EJB. In any case, I think the difference in performance using it
> was not that impresive.
>
> Cheers
>
> Carlos
> -------------------
> Johan wrote:
>
> > A possible radical performer would be shared memory drivers for
> > Open-client.
> > I think this would be much more than simply a nice-to-have.
> >
> > The client then does not go through the network layers (if local), and
> > communicates directly via shared memory.
> > This will only benefit clients on the same host as the server, but
judging
> > on the performance it buys comparable products, it would be especially
> > benificial for back-end processes.
> > It also has the added performance benefit one could now get by having
you
> > app server on the same E10K for example.
> >
> > I thought it would a major engineering challenge, but I'm told it may be
> > less work than I thought.
> > I also understand that IQ has this already.
> >
> > So basically this comes down to prioritising of engineering efforts.
> >
> > For the performance improvements this could bring I think it's obvious
that
> > this should be added soon.
> > We're talking order of magnitude for a single user connection, which
won't
> > scale linearly to 100's of users, BUT:
> > It WILL benefit back-end tasks / batches etc hugely.
> > It will not scale as impressively with a large user-pool, but from
testing
> > with other products still rules out a lot of overhead if you have a
number
> > of local clients.
> >
> > Backporting such a driver to 12.0 would be nice too, and would be
welcomed
> > by a number of customers, who DO NOT currently realise how much faster
> > their back-end tasks can be.
> >
> > Any feedback on this one from engineering ?
> >
> > Johan
>