Есть некоторые особенные случаи но они обговариваются с вендорами и те предоставляют специальные аккаунты и время для нагрузки, например

Можно написать эмулятор, если надо логику прокинуть.

У вас же задача протестировать целевую систему, а не PayPal)

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

Это конечно в том случае, если ваш эмулятор будет быстрее отрабатывать.

первый тест делается на отказ внешнего сервиса
для этого самый простой способ, который использовал, настраивал и сервис и клиент на работу через прокси-сервер Fiddler
А там делал Auto Responce на нужные URL
Поддерживаются разные фильтры

Важно поставить галочки Latency и задать время задержки, вплоть до 60 сек

И задать галочку Unmatched, чтобы пропускать те запросы, для которых нет правил особой обработки

Если ваша система работает хорошо, при длительности ответа в 10-60 сек от внешнего сервера или при ответах ошибках, то ок. Можно тестировать дальше

а разве fiddler нормально тянет под нагрузкой? особенно когда он еще и задержку моделирует?

Под нагрузкой он не тянет, это верно.
Тут проверка на отказ в обслуживании при ручном замере

ручные замеры, особенно в хаос тестировании, часто непоказательны

то же самое под нагрузкой может выдать немало сюрпризов.
зачем тогда вообще ручные замеры делать?

Потому что наличие хоть каких-то данных лучше, чем их полное отсутствие?)

Если интеграция сделана на беке и скрыта от пользователя, это одно и это уже не очень ок.
Если она вся на JS или вообще сделана через переход на другой сайт и возврат после оплаты, то уже здорово.
А все что сделано на JS можно проверять в браузере/Fiddler, что фронт не зависает если кто-то не ответил ему, не отреагировал на переход

Тут вся суть показать, что упал не сайт магазинНосков.домен а упала платежная система

Да, Никита

Всем привет. Задача: требуется сравнить производительность выполнения запросов двух СУБД: PostgreSQL и MS SQL и провести анализ результатов. На этом требования - всё)
Собственно требуется помощь: какие основные метрики собирать для сравнения производительности именно СУБД? Пропускная способность, время обработки запроса и аппаратные метрики сервера или что-то еще?
На данный момент я настроил JDBC в JMeter и подготовил запросы, которые будут использоваться при тестировании.
Ну и прикинул, что можно было бы сравнить, возможно это всё мимо, но всё-таки...:
- производительность выполнения каждого запроса по отдельности
- производительность выполнения серии запросов
- производительность при постоянной нагрузке
- найти пиковую нагрузку
- протестировать выше описанное на объемной базе
В правильную сторону хоть размышляю?)

Привет, тебе надо сравнить на ваших нагрузках и специально подготовленных запросах?
Или просто проверить и сказать что быстрее?

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

поковырял вот эту штуку - очень не плохо, удобно тесты пускать, можно вьюшку из любого места открыть причем именно конкретную, например View Result Tree а не весь жметер, есть совместимость с jmx обычным. по покрытию конечно печально, но автор активный и контрибьютить легко. вероятно стоящая тема)
ЗЫ: с градли сборкой могут быть проблему -если будете пробовать то напишите мне я помогу)

"тебе надо сравнить на ваших нагрузках и специально подготовленных запросах?"
Да. У нас планируется переход портала с MS SQL на PostgreSQL, надо провести анализ производительности. Запросы уже подготовлены на основе процедур, вызываемых api запросами.

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

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

Еще надо выбрать правильные индексы, т.к в MSSQL могут быть определенные типы индексов, а в PostgeSQL - нет