3 messages in com.mysql.lists.javaRe: Support for shared memory access ...| From | Sent On | Attachments |
|---|---|---|
| Paul Palaszewski | 07 Sep 2006 05:28 | |
| Mark Matthews | 07 Sep 2006 06:29 | |
| Paul Palaszewski | 07 Sep 2006 07:01 |
| Subject: | Re: Support for shared memory access in Connector/J? |
|---|---|
| From: | Mark Matthews (ma...@mysql.com) |
| Date: | 09/07/2006 06:29:00 AM |
| List: | com.mysql.lists.java |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Paul Palaszewski wrote:
Hi!
I'm running various mysql servers including 5.0.24a with connector/j 3.1.13 and 5.0.3. I successfully used named pipes as alternative to sockets and was wondering if there is any support for shared memory access? Suppose it would be another socket factory, but have not found anything in docs or in code.
Paul,
It's not supported, and isn't planned to be, as the major use for shared memory in the server is for Windows 95/98, which doesn't have named pipes (and is now a "dead" platform).
If it's not supported, please document that. And if is it planed ... when could it be available?
With the experience from other applications I suppose shared memory is again significantly faster than named pipes like named pipes are compared to tcp ip. Does anybody have experience from other drivers, what performance difference the difference between mysql named pipes and mysql shared memory is?
My guess is it isn't, given that under the hood named pipes probably use some shared-memory like mechanism. I'd also have a look at your application, because if it's a "normal" database application, you shouldn't see a large (i.e. orders of magnitude) difference in application performance based on what "transport" you use for the database RPCs, compared to the kinds of performance impact correctly written queries with proper indexes and correct tuning of buffers on the server (to avoid disk I/O) you will see.
-Mark
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFAB6ztvXNTca6JD8RAmpWAKCxy33rdGTmf0IqsKEVNYBWYcdwVQCgr5If BPTP2QxyzbX4TJVCbWnFe3Q= =EYps -----END PGP SIGNATURE-----