Written by

Question Delab guz · Feb 11, 2022

Driver odbc performance

Hello,

I'm using the InterSystems Iris odbc driver (DriverODBCVer=02.10) to get data from Iris table but it is slow.

Is there any options to improve performance ? Increase the packet size ?

Change to do in odbcinst.ini / odbc.ini to make it quicker ?

Thanks

Product version: IRIS 2021.2

Comments

Dmitry Maslennikov · Feb 11, 2022

Is it works on the same host or not? Server and odbc  client

0
Delab guz · Feb 11, 2022

No,on 2 different servers.

Iris is installed on a server and the odbc driver is installed on another server.

0
Dmitry Maslennikov  Feb 11, 2022 to Delab guz

The driver may work much faster when works locally, it uses shared memory for communication 

0
Delab guz · Feb 11, 2022

by locally you mean the driver installed on Iris db server ?

But the thing is the driver is installed on the client and from client we pulled data.

If installed on server, I cannot access to the driver.

0
Eduard Lebedyuk · Feb 12, 2022

Is it just a SELECT * FROM table query or is it something else?

Run the query in a Management Portal and compare the timings.

0
Saurav Acharjee · Feb 14, 2022

Hi Delab,

I had a similar issue where a third party Reporting Tool was using the IRIS ODBC driver (in machine A) to pull data from IRIS DB (in machine B). 

After several hours of investigation I found that it was the Anti Virus (in machine A) interfering with the  Super Server port (The port that we use in the ODBC driver setting). 

As Eduard suggested, you can run the query from SMP to compare timing. I would also suggest to access the SMP from machine A and run the query.  I believe it will give you more clue about the network.  Good Luck!! 

0
Delab guz · Feb 15, 2022

Hi guys,
Yes it is just a select *
From Portal and even from the third party tool, it return first row in less than one minute.
So I guess it could be the fw or network slowing the transfer

0
Yaron Munz · Feb 28, 2022

I also suggest that you will try to use %PARALLEL. sometimes it helps.

We have experienced that in some (very heavy queries) a good option is in some cases is to have a SP (stored procedure) that will get the query request parameters and run it in parallel "segments" using the build in "queue manager"

0