Есть ли настройка , ограничивающая объем возвращаемых данных через get- request

[Lankey]

1) Немного не поняла Вашу идею. Там один ответ формируется (один json response на этот get request). Поэтому, думаю, что то пока json не сформируется, трафика не будет
И чем его лучше/удобнее перехватывать? Установила Postman Interceptor extension, подойдет?
UPD: Postman Interceptor extension стоит. В tab браузера открыт postman .Запускаю Interceptor, отсылаю через postman запрос, который возвращает 200 и малый объем данных. Не нахожу в Interceptor записей для URL запроса. Почему ((

2) Может быть так, что проблема в формировании Json ? То есть, данные с sql получает, а вот сериализация в json отнимает много времени или ресурсов?

3) Я пытаюсь отловить в Trace parser то, что происходит. То есть, запускаю в браузере Trace и из постмана отправляю сразу запрос. Но почему-то в Trace parser не вижу следов выполнения класса, ответственного за сервис, ни отправляемого им sql запроса. Это нормально?

[Товарищ ♂uatr]

Цитата:

Сообщение от Lankey

думаю, что то пока json не сформируется, трафика не будет

Да, коммуникация с БД (если сервис это подразумевает) должна завершиться перед формированием ответа на запрос. Если до этапа коммуникации дело не доходит - подключение у сервиса должно отваливаться по time out. Так понимаю, сервис-слушатель этим и страдает, отсюда и повышение времени таймаута имело место?
Postman - другая история. Он, согласно настройкам по умолчанию, ждёт до скончания времён.

На каких этапах может возникать проблема с позиции сервиса Аксапты?

• Получение запроса
  Обычно парадом руководит ядро и внешней стороне должен прийти какой-нибудь код 500.
  Исходя из описания проблематики - маловероятно что проблема здесь*.
• Обработка запроса / подготовка ответа
  Это чёрный ящик - обычно он сломан.
• Отправка ответа
  Перехват трафика относится к данному пункту. Однако, если имеет место "отвал" по таймауту этот пункт можно исключить.

Цитата:

Сообщение от Lankey

Может быть так, что проблема в формировании Json ? То есть, данные с sql получает, а вот сериализация в json отнимает много времени или ресурсов?

На фоне работы с БД - это всё капли в море. Здесь нет сетевого трафика. Это работа с оперативной памятью. Сложите в БД или файл сформированный JSON. Не должно быть с ним проблем.

Цитата:

Сообщение от Lankey

Но почему-то в Trace parser не вижу следов выполнения класса, ответственного за сервис, ни отправляемого им sql запроса. Это нормально?

Не нормально, в штатных условиях оно имеет место только при использовании уровня прослойки между источником запроса и Аксаптой в виде компонета(ов) по управлению трафиком (API Gateway, Load balancer и КО). *В первую очередь необходимо удостовериться, что:
А) Аксапта получает запрос;
Б) Пытается его обработать.



PS Если текущее состояние системы не позволяет пользователям выполнять должностные обязанности и является критичным - можете разбить работы по решению проблемы на 2 задачи:
- Выявление и устранение первопричины;
- Разбивка 1-го большого запроса на N маленьких (постраничная загрузка / порционирование).

PS2

Цитата:

Сообщение от Lankey

1.75 MB json ответ(внутри 78 294 строк, но строки нерепрезентативно, тк это json) за 3.5 минуты

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