Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Performance of BEQ v IPC protocol

Re: Performance of BEQ v IPC protocol

From: frank <fbortel_at_home.nl>
Date: Fri, 27 Oct 2000 18:26:29 GMT
Message-ID: <39F9BD77.7ACD06F8@home.nl>

Billy Verreynne 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.

The question was about BEQ and IPC, not TCP. Anyway, there's a *lot* more overhead in TCP, so the above statement is not true, either.
I have performed tests on AIX 4.2, that showed TCP was about 30 times (!!) slower that IPC. Standalone J50, IPC and TCP defined, connections were made local (in fact, the J50 wasn't even connected to a network) using a tns alias in both cases.
Things have improved in 4.3.3, but fact remains that TCP/IP was invented with bad telephone lines in mind. IPC, (named) pipes or BEQ protocols are "local", so there's much less overhead.

> 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?

It is not available on any platform other than M$ NT, W'95 and W'98. And that is well documented in the Net8 Administrator Guide.

>
>
> 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?

That would be a session (layer) not a protocol. It is used (needed, actually) by IIOP clients

>
>
> No idea... Can not think of what that can be. Maybe some legacy left over?
>
> regards,
> Billy
  Received on Fri Oct 27 2000 - 13:26:29 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US