19 lines
2.3 KiB
Markdown
19 lines
2.3 KiB
Markdown
|
---
|
|||
|
|
aliases:
|
|||
|
|
tags:
|
|||
|
|
- зрелость/🌱
|
|||
|
|
date:
|
|||
|
|
- - 2024-05-23
|
|||
|
|
zero-link:
|
|||
|
|
- "[[00 Разработка]]"
|
|||
|
|
parents:
|
|||
|
|
linked:
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
Здесь нарисованы квадратики, соответствующим каким-то отдельным фазам. Они нарисованы совершенно не в масштабе, любая сетевая деятельность занимает больше времени, чем любая деятельность на процессоре. Т.е. если мы делаем соединения на один запрос, мы теряем огромное количество времени вначале на установление соединения, в конце на его закрытие, если необходима еще какая-то авторизация доступа, в БД, к примеру, потеряем еще больше времени. Мы за то же самое время астрономическое, если бы у нас соединение было постоянным, могли бы отправить и получить ответ на два запроса, чем то, что мы сделали с соединением, которое устанавливается каждый раз. ==Держать постоянное соединение эффективнее на порядок.==
|
|||
|
|
|
|||
|
|
Если между запросами нет логической связи и, по сути, поток запросов состоит из отдельных, никак не связанных между собой запросов, почему бы нам не отправлять их сразу, не дожидаясь ответа, а потом ждать всех ответов? Такой подход называется pipelining.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
Так, например, [PostgreSQL](00%20PostgreSQL.md) умеет делать pipelining. Вы можете существенно сократить время отклика от БД, а значит уменьшить время отклика бэкенда в целом. Еще одна вещь. Можно между вашим бэкендом и БД поставить proxy.
|