Bug #68827 multiple connections using Shared Memory interfering
Submitted: 1 Apr 2013 18:47 Modified: 24 Apr 2013 8:37
Reporter: Louis at oracle Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Windows Severity:S2 (Serious)
Version:5.6.11 OS:Windows (window7 64bit)
Assigned to: MySQL Verification Team CPU Architecture:Any
Tags: Connection, shared memory

[1 Apr 2013 18:47] Louis at oracle
Description:
Hello,

I have been experimenting to get more performance out of a visual studio application connected to mysql 5.6.10 via mysql dot net adapter.

Among other things I tried to get more preformance by changing the connection from "localhost;Port=3306" to "Protocol=memory;Shared Memory Name=^FastConn^

That helps a bit (10%), however as soon as I started to use multiple connetions, I got fatal mysql errors in .net adapter

 
 

How to repeat:
I did use multiple connections to decouple tasks:
- reading source
- inserting destination
- logging

Especially when I started using

        cn_dest = New MySqlConnection(connMyDB)

        Call MyLog(3, Now(), "Fill_DB_Vast_DB_Voip", 1, "Gestart", "")

when starting application
        MyCmd.Connection = cn_dest       
        MyCmd.Connection.Open()

when executing inserts
            MyCmd.CommandText = sqlInsertRow
            MyCmd.ExecuteNonQuery()

ending application
   My.Connection.close()

Suggested fix:
No Suggestion

However appart from the bug, note that IMHO, the performance improvement from using shared memory could and should be bigger than 10 - 15%
[1 Apr 2013 18:51] MySQL Verification Team
This could also be a server problem. There is a fix for 5.6.11, it would be interesting if you could wait for server version 5.6.11 to be released and try that...
[1 Apr 2013 18:51] MySQL Verification Team
Bug 13934876 - SHARED MEMORY CONNECTIONS CRASH THE SERVER WHEN ENDING
[22 Apr 2013 17:34] Louis at oracle
I switched to 5.6.11 and it looks like the problem is still there.

Louis
[22 Apr 2013 18:41] MySQL Verification Team
the bugfix i mentioned is in 5.6.11. That's a good thing.  However, 5.6.11 still gives some problems.

If I run a single threaded application that connect/disconnect, around 4000 times per second, it's okay.   If I fire up another application, immediately they both catch many errors like;

mysql_real_connect failed: Lost connection to MySQL server at 'reading initial communication packet', system error: 0 (2013)

I will upload a C application here, tomorrow.  I don't think it is a fault of Connector/Net (not sure though, server still has some problems imho).
[22 Apr 2013 18:52] Louis at oracle
Hum,

Shane, probably you did not notice, but the error you descibe seems also related to another bug report of me

Bug #68983
Fatal error encountered during data read 

Louis
[23 Apr 2013 5:35] MySQL Verification Team
Verifying as a server bug.
[23 Apr 2013 6:20] MySQL Verification Team
C app, runs fine if one instance runs. Errors out if another instance is run in another window!

Attachment: win_shared_memory.cpp (text/plain), 2.51 KiB.

[23 Apr 2013 6:31] MySQL Verification Team
on my win7 pc, this app makes 12500 connections per second in single thread.

on a very rare occasion this also hits one error during connecting..
perhaps a race between the old thread exiting and new connection already being sent by client.
[24 Apr 2013 8:37] Louis at oracle
Shane,

for info I am *not yet* using Multi threading in my (test) application. Reason is simple, I can not even get it running in single proces mode. 
(that holds for all my recent bug reports)

However, even if the application is only one process / thread, within mysql it is not. As descriped in the other bug report, I use one connection per "purpose". Each connection is assiged its own thread, and of course the server has a lot of threads as well.

At the moment the read problem occurs (Bug #68983 Fatal error encountered during data read) the application process has just ended communicating via connection "2 (inserts) and 3 (updates)" and is reading data from conenction "1 ( reads on another table). As indicated each connection has its own thread assigned 

Sincerely,

Louis