nodejs + mysql: когда использовать объединенные соединения?

Question

Прежде всего, я знаю, что есть несколько подобных вопросов, но они не отвечают на то, что мне нужно, поэтому позвольте мне открыть этот новый :)

Во-вторых, этот вопрос сфокусирован на mysql, но не ограничивается этим. он, применяя также к другим объединенным службам, таким как memcached.

Насколько я знаю, nodejs выполняет сценарии однопоточными, но может создавать потоки, поэтому он может управлять одновременными пользователями на сервере. Вот почему имеет смысл создавать пул соединений.

Проблема возникает, когда у меня есть этот тест апи служил курьерским, и я выполняю следующий код тестов:

ab -t 30 -c 1000 localhost/test 

дает мне следующий результат для одного-прямого подключения к базе данных:

Requests per second: 1732.07 [#/sec] (mean) 
Time per request: 577.344 [ms] (mean) 

В пуле тузд только 1 подключение:

Requests per second: 1346.24 [#/sec] (mean) 
Time per request: 742.811 [ms] (mean) 

И используя бассейн со 100 соединениями:

Requests per second: 662.82 [#/sec] (mean) 
Time per request: 1508.716 [ms] (mean) 

Какой должен быть обратный, не так ли? объединенное соединение с лучшей производительностью.

Я знаю, что объединение управления требует своего времени (но не должны быть значительными), а запрос SQL является очень простой, но ... ИДК ...

В API-то вроде этого:

function test(response, request, dbc) { 
    dbc.query(SQL, PARAMS, (err, rows) => { 
    dbc.release(); 
    if(err) { 
     log.error('Error while performing the query', err.code); 
     return; 
    } 

    response.send(response, rows); 
    }); 
} 

где dbc является подключение к базе данных отведенную для одиночных/пула соединений и dbc.release() не делает ничего, если соединение не из пула (чтобы один и тот же апи работу на прямых/объединенных соединений с тем же кодом, просто изменив параметр).

Я что-то упустил?

Answer 1

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

Длительное время отклика с пулом кажется странным, я должен признать. Но и тест достаточно прост - прогоните запрос и закройте соединение. Я предполагаю, что он начнет лучше выглядеть в отношении объединения, если тест проделал некоторую «работу», прежде чем отпустить соединение. Как правило, транзакции открываются, выполняется несколько операторов и т. Д. Вы могли бы имитировать это, используя простую задержку, прежде чем отпустить соединение - например, 2 секунды.

Вы можете узнать больше о том, как сервер Узел работает запросов от одного потока, например, в "Node.js: 100 new requests while still serving the first one!"

Answer 2

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