php mysql disconnect가 실제로 연결 해제 되나요?

Question

24/7 PHP 셸 스크립트에서 MySQL 시간 초과 문제가 있습니다.

Pear DB DB :: connect()가 새로운 핸들을 생성한다는 인상을 받았지만,이 경우는 아닌 것 같습니다. DB :: connect()는 루프에서 다섯 번 사용하더라도 실제로 "서버가 사라졌습니다"라는 오류를 반환합니다.

이제 DB :: connect() 전에 db-> disconnect() 및 unset ($ db)을 스크립트에 추가했습니다. 이것이 기본 mysql 모듈이 연결 (localhost) 전에 리소스를 해제하게할까요? 그렇지 않다면 독점적 인 new_link를 사용하는 것 외에 다른 옵션을 보지 못합니다. manual에서

Answer 1

흠. 결론적이지 않다.

샘플 PHP 스크립트를 동일한 설정으로 두 번 연결하여 mysql_close()를 실행 한 다음 세 번째 연결을 실행하십시오. 다른 창에서 tcpdump도 실행했습니다.

처음 몇 번의 실행에서 후속 연결시 서버에 약간의 트래픽이 발생했습니다. 그런 다음이 교통 체증이 사라졌습니다.

결과적으로 mysql_connect()가 없으면 mysql_connect()는 이전 연결을 실제로 사용하며 이후의 mysql_connect()에서는 트래픽이 제로입니다.

mysql_close()를 실행할 때 덤프는 TCP 연결이 종료되었음을 나타냅니다.

세 번째 연결에서 연결이 처음부터 다시 설정됩니다.

13:37:57.842598 IP 192.168.1.1.58772 > 192.168.2.2.mysql: S 3281731243:3281731243(0) win 5840 <mss 1460,sackOK,timestamp 503312235 0,nop,wscale 7> 
13:37:57.887534 IP 192.168.2.2.mysql > 192.168.1.1.58772: S 1293434507:1293434507(0) ack 3281731244 win 5792 <mss 1460,sackOK,timestamp 3402066848 503312235,nop,wscale 7> 
13:37:57.887639 IP 192.168.1.1.58772 > 192.168.2.2.mysql: . ack 1 win 46 <nop,nop,timestamp 503312245 3402066848> 
13:37:57.932750 IP 192.168.2.2.mysql > 192.168.1.1.58772: P 1:61(60) ack 1 win 46 <nop,nop,timestamp 3402066859 503312245> 
13:37:57.932843 IP 192.168.1.1.58772 > 192.168.2.2.mysql: . ack 61 win 46 <nop,nop,timestamp 503312256 3402066859> 
13:37:57.935983 IP 192.168.1.1.58772 > 192.168.2.2.mysql: P 1:62(61) ack 61 win 46 <nop,nop,timestamp 503312258 3402066859> 
13:37:57.981130 IP 192.168.2.2.mysql > 192.168.1.1.58772: . ack 62 win 46 <nop,nop,timestamp 3402066871 503312258> 
13:37:57.981181 IP 192.168.2.2.mysql > 192.168.1.1.58772: P 61:72(11) ack 62 win 46 <nop,nop,timestamp 3402066871 503312258> 
13:37:58.017172 IP 192.168.1.1.58772 > 192.168.2.2.mysql: . ack 72 win 46 <nop,nop,timestamp 503312279 3402066871> 

at 13:38:01 there was the second mysql connection 

at 13:38:04 now the mysql_close():  
13:38:03.989796 IP 192.168.1.1.58772 > 192.168.2.2.mysql: P 62:67(5) ack 72 win 46 <nop,nop,timestamp 503313772 3402066871> 
13:38:03.989844 IP 192.168.1.1.58772 > 192.168.2.2.mysql: F 67:67(0) ack 72 win 46 <nop,nop,timestamp 503313772 3402066871> 
13:38:04.034818 IP 192.168.2.2.mysql > 192.168.1.1.58772: F 72:72(0) ack 68 win 46 <nop,nop,timestamp 3402068385 503313772> 
13:38:04.034920 IP 192.168.1.1.58772 > 192.168.2.2.mysql: . ack 73 win 46 <nop,nop,timestamp 503313783 3402068385> 

at 13:38:07 the third connection after mysql_close(). Afterwards script exits and mysql connection is closed. 
13:38:06.995120 IP 192.168.1.1.58773 > 192.168.2.2.mysql: S 3287179963:3287179963(0) win 5840 <mss 1460,sackOK,timestamp 503314523 0,nop,wscale 7> 
13:38:07.035065 IP 192.168.2.2.mysql > 192.168.1.1.58773: S 1439831970:1439831970(0) ack 3287179964 win 5792 <mss 1460,sackOK,timestamp 3402069136 503314523,nop,wscale 7> 
13:38:07.035166 IP 192.168.1.1.58773 > 192.168.2.2.mysql: . ack 1 win 46 <nop,nop,timestamp 503314533 3402069136> 
13:38:07.075107 IP 192.168.2.2.mysql > 192.168.1.1.58773: P 1:61(60) ack 1 win 46 <nop,nop,timestamp 3402069146 503314533> 
13:38:07.075188 IP 192.168.1.1.58773 > 192.168.2.2.mysql: . ack 61 win 46 <nop,nop,timestamp 503314543 3402069146> 
13:38:07.075437 IP 192.168.1.1.58773 > 192.168.2.2.mysql: P 1:62(61) ack 61 win 46 <nop,nop,timestamp 503314543 3402069146> 
13:38:07.115123 IP 192.168.2.2.mysql > 192.168.1.1.58773: . ack 62 win 46 <nop,nop,timestamp 3402069156 503314543> 
13:38:07.115178 IP 192.168.2.2.mysql > 192.168.1.1.58773: P 61:72(11) ack 62 win 46 <nop,nop,timestamp 3402069156 503314543> 
13:38:07.115821 IP 192.168.1.1.58773 > 192.168.2.2.mysql: P 62:67(5) ack 72 win 46 <nop,nop,timestamp 503314553 3402069156> 
13:38:07.115844 IP 192.168.1.1.58773 > 192.168.2.2.mysql: F 67:67(0) ack 72 win 46 <nop,nop,timestamp 503314553 3402069156> 
13:38:07.155524 IP 192.168.2.2.mysql > 192.168.1.1.58773: F 72:72(0) ack 68 win 46 <nop,nop,timestamp 3402069166 503314553> 
13:38:07.155606 IP 192.168.1.1.58773 > 192.168.2.2.mysql: . ack 73 win 46 <nop,nop,timestamp 503314563 3402069166> 

그리고 스크립트 :

<?php 

output("starting"); 
$start = microtime(true); 
$res = mysql_connect('192.168.2.2','user','pass'); 
if($res === FALSE) 
     die(output("SQL error on connect\n")); 
output(sprintf("Connect took: %.3f", (microtime(true)-$start))); 

output("sleep 3"); 
sleep(3); 

$start = microtime(true); 
$res = mysql_connect('192.168.2.2','user','pass'); 
if($res === FALSE) 
     die(output("SQL error on connect\n")); 
output(sprintf("Connect took: %.3f", (microtime(true)-$start))); 

output("sleep 3"); 
sleep(3); 

output("closing"); 
mysql_close($res); 

output("sleep 3"); 
sleep(3); 

$start = microtime(true); 
$res = mysql_connect('192.168.2.2','user','pass'); 
if($res === FALSE) 
     die(output("SQL error on connect\n")); 
output(sprintf("Connect took: %.3f", (microtime(true)-$start))); 

output("all done"); 
exit; 

function output($str) 
{ 
     echo date('Y-m-d H:i:s')." ".$str."\n"; 
} 

Answer 2

:

많은 웹 응용 프로그램은 데이터베이스 서버에 영구 연결을 도움이됩니다. 영구 연결은 스크립트의 끝에 에서 닫히지 않지만 다른 스크립트가 동일한 자격 증명을 사용하여 연결을 요청하면 캐싱되고 다시 사용됩니다. 지속적인 연결 캐시를 사용하면 스크립트가 데이터베이스와 통신해야 할 때마다 새로운 연결을 설정하는 오버 헤드를 피할 수 있으므로 빠른 웹 응용 프로그램에서는 이됩니다.

이것은 연결 풀로 알려져 있습니다. 연결은 연결 풀을 사용하여 수행됩니다. 새 연결을 만드는 경우에도 풀에서 가져 와서 사용자에게 제공됩니다.

Do 연결을 닫으면 성능이 저하되고 전혀 이점이 없습니다.