Hello,
In an earlier post I complained of performance problems with ODBC+MySQL
when running a server which makes many 'small' queries and writes. What is
the overhead? The benchmarks indicate that MySQL via ODBC is perhaps only
2x slower than MySQL alone, yet the performance we are experiencing is
_many_ times slower than using Access via DAO. I'm wondering if the
overhead has a lot to do with the fact that MySQL runs over a socket
connection to localhost, whereas the Access jet engine was going directly
to disk with each query/write?
I'm considering re-writing our database stuff to access MySQL directly via
the C API, but I'm not confident this will actually help much, and I really
doubt it will bring our app back to the performance level we achieved with
the Access/ODBC combo. But that combo is undesirable as our database grows.
So: does anyone know of a way to avoid the socket connection, i.e. a way to
directly call the functions executed by the MySQL server process? If the
socket connection can pose a serious bottleneck for small-volume data
access, this would be an ideal solution. I'm using win32 (2000Pro),
creating ONE single connection to the localhost which lasts the duration of
the app. Everthing is optimized as best I know. We are not using
Prepare()'d SQL because we are always creating unique queries on the fly.
I'll mention that I profiled our app with the MySQL + ODBC combination, and
the SQLExecDirect() odbc call (which handles all our queries) took a
whopping 52% of the total process cpu time. argh! This is many times
worse than with our previous solution :(
Q
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
