Назад | Перейти на главную страницу

Обработка нагрузки на сервер: один пакетный запрос против нескольких запросов

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

Скажем, у меня есть приложение типа электронных таблиц. В каждой строке у меня есть несколько ячеек, которые я могу редактировать. Один из способов сохранить эти изменения - отправлять серверу запрос на обновление при каждом обновлении ячейки. Другой вариант - отклонить все обновления, скажем, на 10 секунд.

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

Я пытался найти и понять влияние этих двух подходов на производительность, и у меня возникли проблемы с их поиском. Будет ли такое количество запросов существенно влиять на производительность? Может кто-нибудь объяснить это?

Конечно...

Представьте, что мы говорим о HTTP API, ладно?

Общая полезная нагрузка для каждого запроса будет состоять из всех ресурсов, используемых только для выполнения этого конкретного запроса, поэтому мы можем думать в одном полезной нагрузке запроса для вставки только ОДНОЙ строки в базу данных следующим потоком, просто для иллюстрации, хорошо?

Шаг 1. Запрос на запуск (CURL или любые аналогичные HTTP-клиенты)

Шаг 2: Сервер получает запрос и запускает новый поток (в зависимости от программного обеспечения веб-сервера)

Шаг 3: Weberver выполняет HTTP-рукопожатие и запускает новый поток для Script Interpreter (PHP .NET или что-то еще)

Шаг 4: Интерпретатор сценариев, запускает соединение с базой данных (может быть снова через сеть или локальный сокет, если база данных находится на том же сервере)

Шаг 5: Перенаправьте данные однократной вставки SQL-команды в процесс SGDB

Шаг 6: Выполняет statemant и возвращает статус выполнения (если в команде select результат запроса также будет передан сюда) интерпретатору скриптов (опять же, PHP .NET или что-то еще)

Шаг 7. Интерпретатор сценария возвращает данные программному обеспечению веб-сервера (Apache, Nigins или что-то еще)

Шаг 8: Программное обеспечение веб-сервера снова получает доступ к HTTP-соединению и снова отправляет данные результата клиенту для передачи через сеть ...

Шаг 9: Finnaly завершает цикл потока и освобождает системные ресурсы!

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

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

Очевидно, что у каждого сценария есть свои свойства, и эту логику необходимо проверять для каждого случая ...