Re: Performance of BEQ v IPC protocol

<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 Received on Thu Oct 26 2000 - 06:26:11 CDT