Зарегистрируйте время отклика в веб-службе на основе рестлетов

Question

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

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

Самая близкая вещь, которую я смог найти, - это рецепт: http://www.naviquan.com/blog/restlet-cookbook-log,, он объясняет, как изменить формат журнала. Но, похоже, нет параметра для времени отклика, поэтому, возможно, нужен совершенно другой подход.

Answer 1

Что ж, самый простой способ регистрации времени отклика - это, конечно, вызов System.getCurrentTimeMillis() в начале вашего рестлета, а затем снова в конце вашего рестлета и регистрация разницы. Это, конечно, не приведет к дополнительным затратам на фреймворк, и я подозреваю, что это гораздо более наивно и тривиально, чем после.

Однако я публикую это, потому что через 10 дней никто не ответил вам, и я подозреваю, что это потому, что все спокойно думают

"Разве вы не можете просто использовать System.getCurrentTimeMillis ()? Нет, конечно, это слишком глупый ответ; я бы выглядел как идиот, если бы сказал это. Я просто подожду, пока кто-нибудь еще сделать первый пост. "

Answer 2

Один из способов сделать это, я полагаю, - использовать метрический API Codehale. Просто добавьте аннотацию @Timed(name="sampleApiName") к объявлению API.

Answer 3

Я не думаю, что ведение журнала - это путь, по крайней мере, ни один из типов ведения журнала, встроенных в Restlet или Java API. Они предназначены либо для программно-ориентированной отладки, либо для ведения журнала доступа, предназначенного для предоставления статистики о том, какие ресурсы используются и кем. Но реальная проблема заключается в том, что вы не будете измерять реальный опыт, который ваши пользователи будут иметь с вашим сервисом.

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

Если вам нужно только протестировать результаты довольно простых GET и POST запросов, вероятно, подойдет такая служба, как Pingdom . Если ваш сервис более сложный, то вам может потребоваться написать собственное приложение / скрипт для выборки, которое могло бы служить прокси от Pingdom и др. Для вашего фактического сервиса. Вы должны разместить прокси-сервер выборки на отдельном сервере от вашего фактического сервиса. Google 10000 * App Engine может быть удобен для этого.