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