A brief analysis of the Sphinx long connection problem in PHP

A brief analysis of the Sphinx long connection problem in PHP_PHP Tutorial

WBOY

Release： 2016-07-13 10:47:00

Original

850 people have browsed it

I have already introduced what Sphinx is here. You can check it on Baidu. Next, I will introduce the analysis of Sphinx long connection problem in PHP. I hope these articles will be helpful to all my friends.

SphinxClient::open
(PECL sphinx >= 1.0.3)

SphinxClient::open — Establish a persistent connection to the search server

Description
public bool SphinxClient::open ( void )
Establish a persistent connection to the search server.

Parameters
This function has no parameters.

Return value
Returns TRUE on success, or FALSE on failure.

While optimizing the PHP system code today, I did some analysis on sphinx's long connections and found that the sphinx api of php is not as we imagined. It will always maintain a long connection with the searchd process of sphinx in the fastcgi state of php-fpm. sphinx The open() method in the API interface only provides a session request to ensure that multiple sphinx calls share a sphinx tcp connection channel in a single php process. When the php interpretation is completed, the connection to sphinx will be automatically disconnected. instead of staying connected.

This post also supports the original poster’s idea: http://sphinxsearch.com/forum/view.html?id=7200

> So it seems that the definition of 'persistent connection' in Sphinx is different from
> persistent MySql connections when using a PhP API : the persistence is only across
> multiple calls *in the same php request execution* and not persistence within the client

> process i.e. across multiple php requests.

We can do an experiment like this to prove my point:

Add the sphinx.so extension to php, and then write the following test code:

$s = new SphinxClient();

var_dump($s);
$s->setServer('192.168.1.108','9312');
//$s->open();
var_dump($s->query('abxxxx'));
var_dump($s->query('abxxxx'));

Note that $s->open() is blocked here first, and then we use the strace command to track the execution of this php script in the cli state. When collecting system call information, we will find:

There are two requests to connect to 192.168.1.108 in the system call. That is to say, when the open method is not called, two TCP requests to sphinx will be generated in the same PHP runtime.

611 fcntl64(3, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
612 connect(3, {sa_family=AF_INET, sin_port=htons(9312), sin_addr=inet_addr("192.168.1.108")}, 16) = -1 EINPROGRESS (Operation now in progress)
613 select(4, NULL, [3], NULL, {60, 0}) = 1 (out [3], left {59, 999996})
614 fcntl64(3, F_SETFL, O_RDONLY) = 0
615 send(3, "1", 4, MSG_NOSIGNAL) = 4
616 recv(3, "1", 4, 0) = 4
617 send(3, "1312241", 16, MSG_NOSIGNAL) = 16
618 send(3, "246abxx"..., 140, MSG_NOSIGNAL) = 140
619 recv(3, "131`", 8, 0) = 8
620 recv(3, "25title4text2"..., 96, 0) = 96
621 close(3)
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
756 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
757 fcntl64(3, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
758 connect(3, {sa_family=AF_INET, sin_port=htons(9312), sin_addr=inet_addr("192.168.1.108")}, 16) = -1 EINPROGRESS (Operation now in progress)
759 select(4, NULL, [3], NULL, {60, 0}) = 1 (out [3], left {59, 999997})
760 fcntl64(3, F_SETFL, O_RDONLY) = 0
761 send(3, "1", 4, MSG_NOSIGNAL) = 4
762 recv(3, "1", 4, 0) = 4
763 send(3, "1312241", 16, MSG_NOSIGNAL) = 16
764 send(3, "246abxx"..., 140, MSG_NOSIGNAL) = 140
765 recv(3, "131`", 8, 0) = 8
766 recv(3, "25title4text2"..., 96, 0) = 96
767 close(3) through 768 write(1, "array(9) {n", 11array(9) {

Then we uncomment the open call and continue strace. We will find that the query method is still called twice in succession, but after the first query call, the API will not immediately close the TCP connection, but will continue to give the second query. Call to use.