새 DB 연결을 만들지 여부

Question

나는 약 1 분 정도 걸리는 크론 작업 (15 분마다)을 실행 중이다. 그것은 API 호출을 많이 만들고 데이터를 데이터베이스에 저장합니다.

지금 나는 처음에 mysql 연결을 만들고 코드를 통해 동일한 연결을 사용합니다. 대부분의 경우 API 호출을 보내는 데 소비됩니다.

데이터를 저장할 때 (아래)에만 새 데이터베이스 연결을 만드는 것이 더 효율적입니까?

1. 는
2. 고토에게
새로운 DB 연결
4. 실행 쿼리를 작성 완료하는 데 1

[편집] 여기 MySQL의 보고서를 API 호출에 대한 마지막 연결

대기 죽여 . 나는 mysql을 처음 사용했다. 다음 보고서를 기반으로 DB에 다시 연결할 이유가 있습니까?

1 MySQL 5.1.26-rc-5.1.26r uptime 0 1:8:58  Tue Jun 15 21:25:03 2010 
    2 
    3 __ Key _________________________________________________________________ 
    4 Buffer used 33.00k of 24.00M %Used: 0.13 
    5 Current  4.52M   %Usage: 18.84 
    6 Write hit  33.33% 
    7 Read hit  69.16% 
    8 
    9 __ Questions ___________________________________________________________ 
10 Total   1.75k  0.4/s 
11 COM_QUIT 319.92k 77.3/s %Total: 18312. 
12 -Unknown 319.90k 77.3/s   18311. 
13 DMS   1.53k  0.4/s   87.58 
14 Com_   199  0.0/s   11.39 
15 QC Hits   1  0.0/s   0.06 
16 Slow    144  0.0/s   8.24 %DMS: 9.41 
17 DMS    1.53k  0.4/s   87.58 
18 SELECT  1.22k  0.3/s   69.83   79.74 
19 INSERT   155  0.0/s   8.87   10.13 
20 UPDATE   155  0.0/s   8.87   10.13 
21 REPLACE   0  0/s   0.00   0.00 
22 DELETE   0  0/s   0.00   0.00 
23 Com_    199  0.0/s   11.39 
24 check   86  0.0/s   4.92 
25 show_status  41  0.0/s   2.35 
26 set_option  23  0.0/s   1.32 
27 
28 __ SELECT and Sort _____________________________________________________ 
29 Scan    653  0.2/s %SELECT: 53.52 
30 Range    0  0/s   0.00 
31 Full join   0  0/s   0.00 
32 Range check   0  0/s   0.00 
33 Full rng join  0  0/s   0.00 
34 Sort scan   0  0/s 
35 Sort range  590  0.1/s 
36 Sort mrg pass  0  0/s 
37 
38 __ Query Cache _________________________________________________________ 
39 Memory usage 43.57k of 12.00M %Used: 0.35 
40 Block Fragmnt 25.35% 
41 Hits    1  0.0/s 
42 Inserts   916  0.2/s 
43 Insrt:Prune  916:1  0.2/s 
44 Hit:Insert  0.00:1   
45 
46 __ Table Locks _________________________________________________________ 
47 Waited    0  0/s %Total: 0.00 
48 Immediate  1.65k  0.4/s 
49 
50 __ Tables ______________________________________________________________ 
51 Open    47 of 1024 %Cache: 4.59 
52 Opened    54  0.0/s 
53 
54 __ Connections _________________________________________________________ 
55 Max used   3 of 60  %Max: 5.00 
56 Total   319.92k 77.3/s 
57 
58 __ Created Temp ________________________________________________________ 
59 Disk table   2  0.0/s 
60 Table    28  0.0/s 
61 File    5  0.0/s 
62 
63 __ Threads _____________________________________________________________ 
64 Running    3 of 3 
65 Cached    0 of 4  %Hit: 100 
66 Created    3  0.0/s 
67 Slow    0  0/s 
68 
69 __ Aborted _____________________________________________________________ 
70 Clients    0  0/s 
71 Connects  319.86k 77.3/s 
72 
73 __ Bytes _______________________________________________________________ 
74 Sent   52.36M 12.7k/s 
75 Received  23.17M 5.6k/s 

Answer 1

연결을 끊고 다시 설정하는 것이 거의 바람직하지 않습니다. DB에 연결하는 것은 보통 상당히 복잡한 과정입니다. 많은 응용 프로그램이 연결 풀을 만들지 만이를 막기 위해 몇 가지 합리적인 연결 수를 만든 다음 오랜 기간 동안 유지합니다. 어쩌면 영원히 유지할 수도 있습니다. 필요할 때마다 각 스레드 나 사용자가 풀에서 연결을 가져온 다음 다시 돌려줍니다. .

연결이 끊어져서 쿼리에 실패하여 연결을 해제 할 수없는 경우 실제 해결책은 적절한 예외 처리를 구현하여 발생하지 않도록하는 것입니다.

데이터베이스가 연결 최대 값을 초과하여 다른 스레드가 실패하는 동안 하나의 스레드가 비활성 연결에있는 경우 연결을 해제해야합니다.

사이드 노트 : MySQL은 연결 속도가 매우 빨라서 다른 데이터베이스 엔진보다 문제가 적다 고 주장합니다. 나는 이것을 결코 벤치마킹 한 적이 없다.

Answer 2

그것은 우리가 무슨 생각이 없다는 것을 고려하고 의견을주고 조금 어렵습니다 (2).

최적화의 첫 번째 규칙은 "Don't do it"입니다. 그런 의미에서 성능상의 문제를 해결하기위한 좋은 이유가 없다면 (다른 사용자에게는 DB가 느리고 cron 프로세스 중에는 CPU가 최대치가되는 등) 성능상의 문제를 해결할 수는 없습니다.

프로그램의 효율성을 향상시킬만한 이유가있는 경우 비교할 하드 번호가 있습니다 (예 : cron 일괄 처리가 너무 오래 걸려 일부 실행을 건너 뛰거나 너무 늦게 종료 됨) 사용자 요구 사항을 만족 시키거나 롤백 구조를 채우는 등) 테스트 환경에서 수정 사항을 간단히 적용 할 수 있습니다 (구현하기가 매우 복잡하다는 것을 잊지 않는 한 단순한 수정처럼 보입니다). 당신이 무엇을 측정했는지 그리고 처음에 부족한 것으로 발견 된 것이 있다면.

정말 미안하지만 문제가 실제로 해결하려고하는 문제에 대한 아이디어가 없으면 "이것이 더 효율적 일 수 있는지 궁금합니다."문제 해결법입니다.

Answer 3

병 목에 DB에 연결할 수있는 충분한 여유 슬롯이 없다면 가능하면 연결을 닫으십시오.
그렇지 않으면 사용하고 적어도 동일한 요청에서 재사용하십시오.