Какое время ответа сервиса должно быть при разработке api?

Question

[Владимир Солдатов]

Искал долго и упорно но найти хоть какой то ответ на это не смог. В web разработке общепринятым является время ответа 200ms, но опять же нигде явно об этом не написано. Есть ли какие то стандарты в которых черным по белому написано сколько времени сервер должен отвечать. Для веба, для обменов с erp системами и подобным. Если же кто то не знает такого то все равно прошу отписаться кто как думает какое время приемлемое и насколько реально достижимое для проектов на базе 1C (имеется ввиду не битрикс а управление торговлей скажем), sap erp и прочего, подобного.

Answer 1

[Dmitry Pavlov]

В старой книжке по юзабилити было сказано примерно так:

0,1 s (или 100 ms) - предел, до которого пользователю кажется, что система работает мгновенно и никаких прогресс баров не требуется.

1 s (или 1000 ms) - предел, до которого пользователь замечает небольшую задержку, но в целом ему кажется, что все работает нормально.

10 s (или 10 000 ms) - пользователь перестает следить за процессом и ему кажется что система подвисла.

В целом логика проста: меньше - лучше. Думаю, что предел когда все можно считать OK - до 1 секунды, лучше 500 ms (если конечно речь не про вызов API в цикле - тогда надо чтобы все запросы уложились в этот предел). Если отклик больше имеет смысл для той системы (обычно некий пользоваельский интерфейс), которая использует API - добавить какую-то анимацию вроде индикатора загрузки - в этом случае пользователь спокойней переносит б0льшие интервалы отклика, так как видит что система что-то делает. Обычно в веб приложении, которое лезет за данными (особенно если это не по одному элементу а обработка пакетом) в какие-то внешние системы делают индикатор. Можно довольно просто навесить какую-то анимацию на все AJAX вызовы с помощью api.jquery.com/category/ajax/global-ajax-event-handlers - на старт показывать на завершение скрывать. Есть много готовых решений.

Comments

[Владимир Солдатов]

Проблема не в решении а в нежелании оптимизировать работу "веб сервисов" разработчиками SAP. Ответ в течении 10-15сек ими считается хорошим показателем. Нужно как то их убедить что они не правы и заставить их действовать. )

[Dmitry Pavlov]

Владимир Солдатов: пытаться заставить "внешние системы" работать иначе - обычно такая-же пустая затея, как рефакторинг автогенерируемого кода. API которое поставлется внешними системами как продукт / сервис обычно соповождается документацией. В ней должны быть указаны ограничения на время отклика, чтобы пользователи этого API могли правильно обработать timeout.

Вы можете попробовать сподвигнуть разработчиков SAP что-то предпринять, если найдете эти лимиты, потом сделаете запрос, который будет отрабатывать дольше и затем это отправите как баг. В результате будет одно из трех:
1) Поправят документацию
2) Подскажут как оптимизировать ваш запрос, чтобы уложиться в лимиты
3) Предпримут какую-то оптимизацию на своей стороне, что может вылиться в целом в ускорение системы

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

Если есть контакты разработчиков - спросите их, как можно ускорить отклик от SAP. Иногда даже достаточно проапгрейдить мощности сервера. Часто корпоративка крутится на чахлых серверах а то и вовсе - кастрированных виртуалках. В общем можно попробовать поискать bottle neck (узкое место, слабое звено).

В целом нужно уметь делать свою работу хорошо, не пытаясь сделать идеальным весь мир, Так как это пустая трата времени. А умение работать с неидеальным окружением корректно - ценный профессиональный навык. Не стоит сражаться с ветряными мельницами. Успехов!

[Владимир Солдатов]

Dmitry Pavlov: вы гаверное подумали что я собираюсь писать разработчикам из компании sap . это мое упущение в описании проблемы. Опзработчки эти работают в компании в которой работаю и я. Целый отдел разрабов занимается допиливанием sap. Дак вот проблема как раз заставить их принять решение по оптимизации кода либо бд а не авторов сего чудного немецкого творения.

[Владимир Солдатов]

Dmitry Pavlov: имено это и нужно заставить их делать исказать узкое место. Когда я спросил насчет оптимизации мне ответили что они пытались но чет как то не получилось. Поэтому и вопрос был про стандарт или что то подобное дабы покпзать мол ребята давайте еще подумаем.

[Dmitry Pavlov]

Владимир Солдатов: тогда зовите их на чашечку пива, заодно обсудите все проблемы :)

Answer 2

[Антон Агальцов]

Смотря что за сервис и с чем его едят.

У меня есть несколько сервисов, которые забирают данные по крону. Вот, там мне в целом все равно 100мс или 10с отдается запрос (утрировано).

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

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

Тут надо плясать от ситуации.

Comments

[Владимир Солдатов]

Все верно. Но прокладки уже есть и кэши и прочее. Только вот элементарно получить историю заказов из 3 записей за 1 сек а из 10 уже 3 сек весьма сьранно не находите? )) поэтому и желаю получить публично заявленные требования к времени ответа.

[Антон Агальцов]

Владимир Солдатов: нагрузка такая большая? Вообще люблю я о подобном подумать ))) Ну если только могу предложить грузить историю, порциями по 3 заказа, с анимацией. Пока анимируются первые 3, еще 3 загружаются.

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

[Владимир Солдатов]

Антон Агальцов: у нас не совсем интернет магазин. Точнее совсем не интернет магазин. Мы транспортная компания. А заказы это заказы на перевозку. Я тоже люблю подумать о таких вещах. Поэтому покою и не дает. А про конверсию в точку клиенты уйдут туда где все быстро и просто.