j.random.programmer wrote:
Mark:Once of the great things about MySQL is the prompt attention and response on this list. Thanks for replying to this email so quickly. Read on...
No problem!
Well, I'm all for completeness, so I'll put the columns in there, in case any tools rely on them.
--- Mark Matthews wrote:
>j.random.programmer wrote:
>
>>Hi:
>>
>>Thought I'd mention this (using the latest dev
>>J/connect):
>>
>>A)
>>DatabaseMetaData.getColumns() does not return the
>
>last
>
>>4 columns (SCOPE_*) but it should according to the
>
>>API spec
>
>I'll look into fixing this right away. You should
>write Sun as well, as
>their JDBC compliance testsuite doesn't look for
>this :(
It's kind of a moot point anyway because those
SCOPE_* columns don't really do anything as far
as I can tell. But hey, you may as well be complete.
We've seen problems with various network adapters and MySQL causing problems like this, and specifically problems with network adapters 'autoconfiguring' for full-duplex (read 'misconfiguring'). Make sure that your network adapters/drivers have no unsolved issues running full-duplex, and make sure all ports in the network topology (client, hub/switch, server) are running at the same duplex (hopefully "full").
[snip -- removed comment about perceived performance problem]
You are right. It looks like some sort of network
problem.
I tried this on a seperate set of 2 machines both on a different network. The driver was running on a windows 2000 box (dual 1 GB) hitting the mysql box (dual xeon, 1 GB, linux) over a 100 Mbit line. This test now took about 55 seconds. I have a feeling that switching to 4.x would make things even faster, seeing as you are getting 30 seconds with a slower box. Are you using 4.x internally for your testing ?
Yes, I'm using 4.0.5 (from BK, so I can do SSL development, which is done, btw, so look for it in Connector/J 3.0.2, to be released later this week!) on Suse Linux, and 4.0.4 on Windows XP.
BTW, if you _really_ want Inserts like your benchmark to have excellent performance (like in bulk loading situations), use the multi-value insert form:
INSERT INTO TABLE foo VALUES (...), (...), (...)...
Setting the max_allowed_packet to 16M for my test server, and building the statement for 100,000 rows in one shot before executing it, I was able to run your benchmark in under 5 seconds!
The multiple-value insert is _much_ more efficient on the server-side, so if you can use it in your situation, I advise that you do.
In the future, MySQL will support multiple queries in a single call, and when this happens Connector/J will turn Statement.addBatch()/executeBatch() type queries into this form, which will give you the same type of speedup in a JDBC-standard manner.
For now, you need to do it by hand (like I outlined above).
-Mark
--
For technical support contracts, visit https://order.mysql.com/?ref=mmma
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mark Matthews <[EMAIL PROTECTED]>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer - JDBC/Java
/_/ /_/\_, /___/\___\_\___/ Flossmoor (Chicago), IL USA
<___/ www.mysql.com
---------------------------------------------------------------------
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
