Выхад праз проксі не пераносіць ваш рухавік JMeter

Выкажам здагадку, што тэставы рухавік у адным офісе выкарыстоўвае проксі ў іншай краіне. Сайт бачыць публічны выхад проксі, а запыт па-ранейшаму пачынаецца на офіснай машыне.

office engine → regional proxy → website

Гэта карысна для праверкі паводзін, якія выбіраюцца бачным зыходным IP. Ён вымярае шлях, які ўключае ўчастак ад офіса да проксі, а таксама ўчастак ад проксі да сайта і ўласную апрацоўку проксі. Гэта не той самы шлях, што ў кліента, які стартуе побач з рэгіянальным проксі.

Параметры HTTP-проксі ў JMeter могуць выбраць гэтага пасрэдніка. Захоўвайце выбраны endpoint разам з вынікамі тэсту і пераканайцеся, што выкарыстаныя сэмплеры сапраўды ўжываюць патрэбную наладку. Для дазволенай праверкі публічнага сайта без уліковых даных проксі спіс HTTP-проксі прапануе HTTP-кандыдатаў; праверце назіраны выхад, перш чым інтэрпрэтаваць рэгіянальны вынік.

Размяшчайце рухавік там, дзе пачынаецца вымярэнне

Калі пытанне тычыцца нагрузкі, створанай з іншага месца сеткі, выкарыстоўвайце рухавікі ў патрэбных месцах праз падтрыманую аддаленую схему JMeter або незалежна кіраваныя запускі CLI. Месца кантролера не замяняе сеткавыя пункты старту рухавікоў.

Плануйце нагрузку яўна. Аддаленыя рухавікі JMeter выконваюць поўны тэставы план; кантролер не дзеліць адну колькасць патокаў паміж імі аўтаматычна. Некалькі рухавікоў, якія выконваюць адзін план, могуць стварыць большую сумарную нагрузку, чым чакае чытач.

Выбірайце схему зыходзячы з пытання: бачны выхадны IP, рэгіянальны сеткавы шлях карыстальніка або сумарная нагрузка праграмы. Запішыце гэты выбар, каб вынік, абмежаваны проксі, не паведамляўся як самастойная ёмістасць сайта.