Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: Performance of BEQ v IPC protocol
billy, can you explain what is a BEQ protocol ? what are other protocol
beside BEQ ? Also, do you have a reference, I can lookup for this
subject.
thnx ted
In article <8t94do$7cj$1_at_ctb-nnrp2.saix.net>,
"Billy Verreynne" <vslabs_at_onwe.co.za> wrote:
> <harronc_at_attglobal.net> wrote in message
>
> > I have an application which select around 2 million rows from a
table.
> > The application runs on the same host as the Oracle instance. I
> > currently have a performance problem with this application and
> > utlbstat/utlestat shows as I expected that Oracle spends a lot of
time
> > waiting from SQL*Net message from client.
>
> Messing around with protocol stacks and IPC will not solve the basic
problem
> with the client.
>
> If the physical delivery mechanism in getting the data packet from
Oracle to
> the Client is not the bottleneck, how can you expect any performance
> increase by making the delivery mechanism faster?
>
> A bigger pipe will not solve the problem with a client app retrieving
a
> single row at a time (instead of doing an array fetch). The size of
the pipe
> is not the problem.
>
> > 1. Am I right in assuming that as BEQ is based on UNIX pipes it
will be
> > faster that IPC which uses sockets?
>
> No. There is no guarantees that a local Unix pipe is any faster than
a local
> TCP connection. From a programming point of view, there is little
difference
> as in both cases standard Unix read() and write() i/o calls are
usually used
> for both. In both cases there is a 'mechanism' that deals with the
i/o - so
> in both cases there is an overhead to pay as delivery is not direct.
>
> Sure, if you have a TCP connection running thru a couple of routers
or over
> a small pipe, then the performance is very likely to be slower than
IPC. But
> then that is because of the physical network hardware layer and not
because
> the TCP protocol stack is significantly slower (if at all) in
its "software
> operation" than IPC's "software operation".
>
> > 2. Why is there so little documentation available on the BEQ
protocol?
> > Is there a good reason why Oracle do not want its users to use BEQ?
>
> AFAIK the BEQ protocol is in essence an IPC connection directly
between the
> client process and its shadow process, without having to use SQL*Net
to
> establish the connection and without having to use a network protocol
as
> delivery mechanism.
>
> I doubt that there's anything hidden or secretive with the BEQ
protocol. It
> is up to you the user to select whether you want to use a TNS alias
using
> the BEQ protocol or any other protocol. Even when writing client
code, the
> protocol is irrevelant as that is handled by OCI for you. Which makes
sense
> as this is one lesser thing (and a very complex one at that) to worry
about.
> In addition, I am sure that Oracle has fine tuned the protocol
interfaces to
> provide the best possible performance from a software perspective..
Thus,
> should the protocol performance be a problem, that requires the NOS
(network
> operating system) to be fine-tuned and not the OCI protocol drivers.
>
> > 3. I have noticed that there is a RAW protocol diver. Does anyone
know
> > what this is for?
>
> No idea... Can not think of what that can be. Maybe some legacy left
over?
>
> regards,
> Billy
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
Received on Sat Oct 28 2000 - 00:53:51 CDT