Создавать новые подключения к БД или нет?

Question

Я запускаю задание cron (каждые 15 минут), выполнение которого занимает около минуты. Он выполняет множество вызовов API и сохраняет данные в базе данных.

Прямо сейчас я создаю соединение mysql в начале и использую то же соединение через код. Большую часть времени тратят на вызовы API.

Будет ли эффективнее создавать новое соединение с базой данных только тогда, когда пришло время хранить данные (ниже)?

1. убить последнее соединение
2. Ожидание завершения вызова API
3. Создать новое соединение с БД
4. Выполнить запрос
5. Перейти к 1

[Edit] Вот отчет MYSQL. Я новичок в MySQL - есть ли основания для повторного подключения к БД на основе следующего отчета?

  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

Редко выгодно сбрасывать соединения и восстанавливать их.Установление соединения с БД обычно является довольно сложным процессом.Множество приложений создают пулы соединений только для того, чтобы этого избежать: создайте некоторое разумное количество соединений, а затем сохраняйте их в течение длительных периодов времени, возможно, даже навсегда, позволяя каждому потоку или пользователю брать соединения из пула, когда они вам нужны, и затем возвращать их.

Если у вас есть проблема с потерянными соединениями - запрос не выполняется, и вам никогда не удается освободить соединение - реальное решение состоит в том, чтобы реализовать надлежащую обработку исключений, чтобы этого не происходило.

Если у вас один поток сидит на неактивном соединении, в то время как другие потоки выходят из строя из-за того, что база данных достигла максимума своего соединения, тогда да, вам нужно посмотреть на освобождение соединений.

ПримечаниеMySQL утверждает, что он может устанавливать соединения очень быстро, так что это не такая большая проблема, как для других механизмов баз данных.Я никогда не тестировал это.

Answer 2

Если горлышко бутылки заключается в том, что у вас недостаточно свободных слотов для подключения к БД, тогда, по возможности, закройте соединение.
В противном случае используйте его и используйте повторно (по крайней мере, в том же запросе).

Answer 3

Сложно дать заключение, учитывая, что мы не знаем, что происходит в (2).

Помните, что первое правило оптимизации: " Не делайтеэто ».В том смысле, что если у вас нет веских причин (для других пользователей медленная БД, максимальная загрузка ЦП во время процесса cron и т. Д.), Возможно, для решения проблемы производительности лучше не делать ничего.

Если у вас есть некоторыеПричиной повышения эффективности программы является то, что у вас будет несколько жестких чисел для сравнения (например: ваша партия cron занимает так много времени, что вам пришлось пропустить некоторые прогоны, или она заканчивается слишком поздно, чтобы удовлетворить требования пользователя, или заполняетструктуры отката и т. д.) и вы можете просто применить свою модификацию в своей тестовой среде (это выглядит как простое исправление, если вы не забыли сообщить нам, что это будет очень сложно реализовать) и посмотреть, улучшит ли она того, что у вас естьизмерил и обнаружил недостаток в начале .

Извините, но «интересно, может ли это быть более эффективным», не имея представления о том, какую проблему вы действительно пытаетесь решить, это рецепт проблем.