Re: ODBC Driver performance comparison

Here also another test - http://freepcrf.com/files/my_vs_pq_vs_tt.png
There 3 runs of commercial application with constant load on same PC,
13:58-14:17 - mysql,
14:35-14:55 - PostgreSql,
15:03-15:20 - Timesten
You can see high softirq usage on Posgresql. This is network driver
related.

Here you can found information how performance report collected
http://gperftools.googlecode.com/svn/trunk/doc/cpuprofile.html.

On Fri, Sep 5, 2014 at 10:40 AM, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com
> wrote:

> On 09/05/2014 08:53 AM, Vladimir Romanov wrote:
>
>> Hello all!
>> I do some test with ODBC driver for PosgreSql, TimesTen & MySQL. I compare
>> performance on very simple request. Database always located on same PC as
>> test application. Test PC - Lenovo T500, Cnetos 6.5 64, 8 Gb RAM, SSD.
>> I found what PostgreSql ODBC driver is slowest in comparison.
>> IMHO problems related to protocol used. I can't use SHM connection to
>> server or even UNIX socket.
>>
>
> Actually, you can use a UNIX domain socket with psqlodbc. Just put the
> path to the socket, e.g. "/tmp", in the Servername property, instead of the
> hostname. That's assuming psqlodbc was compiled with libpq support,
> (--with-libpq configure option), but I'm pretty sure that's the default on
> all major distributions.
>
> perftool report - http://freepcrf.com/files/db_test_pq.pdf
>>
>
> Would be interesting to get the psqlodbc function names in the chart. Any
> chance you could re-run the benchmark with a debug-enabled build?
>
> It's interesting that 10.7% of the runtime seems to be spent in
> __tz_convert() function, called indirectly by SQLExecute. Off the top of my
> head, I don't see where that call is coming from. I wouldn't expect
> SQLExecute to do much with timezones, at least when there are no timestamp
> fields involved.
>
> It might also be fairly straightforward to optimize the sprintf/sscanf
> function calls. They're probably used to convert between integers and
> strings, and it should be possible write some sort of fast-paths for those
> conversions.
>
> Are you measuring wall-clock time or CPU time? If it's CPU time, I'm
> surprised that the I/O-related syscalls, poll(), send() and recv(), are so
> high on the profile. If not, there isn't much you can do in the client side
> to make them faster, as the time is simply spent waiting for the server.
>
> - Heikki
>

--
Vladimir Romanov