Connecting
在线手册:中文  英文

Domain Socket Support

MongoDB has built-in support for via Unix Domain Sockets and will open the socket on startup, by default located in /tmp/mongodb-<port>.sock..

To connect to the socket file, specify the path in your MongoDB connection string:

<?php
$m 
= new MongoClient("mongodb:///tmp/mongo-27017.sock");
?>

If you would like to authenticate against a database (as described above) with a socket file, you must specify a port of 0 so that the connection string parser can detect the end of the socket path. Alternatively, you can use the constructor options.

<?php
$m 
= new MongoClient("mongodb://username:password@/tmp/mongo-27017.sock:0/foo");
?>

更新日志

版本 说明
1.0.9 Added support for Unix Domain Sockets.

Connecting
在线手册:中文  英文

用户评论:

East Ghost Com (2013-05-03 08:40:02)

Confirming fast performance running Apache and MongoDB (even a replicaSet secondary, with distant primary over WAN) on same box, communicating via unix domain socket.
$Mongo = new \MongoClient(
'mongodb:///tmp/mongodb-27017.sock'
, array(
'replicaSet' => 'rs1'
, 'timeout' => 300000
)
);
$Mdb = $Mongo->DB; // create or open DB
$Mdb->setReadPreference( \MongoClient::RP_NEAREST );
"Postgres core developer Bruce Momjian has blogged about this topic. Momjian states, "Unix-domain socket communication is measurably faster." He measured query network performance showing that the local domain socket was 33% faster than using the TCP/IP stack."
http://stackoverflow.com/questions/257433/postgresql-unix-domain-sockets-vs-tcp-sockets
Excerpt: IP sockets over localhost are basically looped back network on-the-wireIP. There is intentionally “no special knowledge” of the fact that the connection is to the same system, so no effort is made to bypass the normal IP stack mechanisms for performance reasons. For example, transmission over TCP will always involve two context switches to get to the remote socket, as you have to switch through the netisr, which occurs following the “loopback” of the packet through the synthetic loopback interface. Likewise, you get all the overhead of ACKs, TCP flow control, encapsulation/decapsulation, etc. Routing will be performed in order to decide if the packets go to the localhost. Large sends will have to be broken down into MTU-size datagrams, which also adds overhead for large writes. It’s really TCP, it just goes over a loopback interface by virtue of a special address, or discovering that the address requested is served locally rather than over an ethernet (etc).
UNIX domain sockets have explicit knowledge that they’re executing on the same system. They avoid the extra context switch through the netisr, and a sending thread will write the stream or datagrams directly into the receiving socket buffer. No checksums are calculated, no headers are inserted, no routing is performed, etc. Because they have access to the remote socket buffer, they can also directly provide feedback to the sender when it is filling, or more importantly, emptying, rather than having the added overhead of explicit acknowledgement and window changes. The one piece of functionality that UNIX domain sockets don’t provide that TCP does is out-of-band data. In practice, this is an issue for almost noone.
http://osnet.cs.binghamton.edu/publications/TR-20070820.pdf
Excerpt: It was hypothesized that pipes would have the highest throughtput due to its limited functionality, since it is half-duplex, but this was not true. For almost all of the data sizes transferred, Unix domain sockets performed better than both TCP sockets and pipes, as can be seen in Figure 1 below. Figure 1 shows the transfer rates for the IPC mechanisms, but it should be noted that they do not represent the speeds obtained by all of the test machines. The transfer rates are consistent across the machines with similar hardware con?gurations though. On some machines, Unix domain sockets reached transfer rates as high as 1500 MB/s.
http://bhavin.directi.com/unix-domain-sockets-vs-tcp-sockets/

易百教程