Warning
Only test systems that you own or are explicitly authorized to test. Start with a low load and monitor the target.
فقط سامانهای را تست کنید که مالک آن هستید یا برای تست آن مجوز صریح دارید. با بار کم شروع کنید و مقصد را زیر نظر داشته باشید.
ابزاری سبک و قابل تنظیم برای تست بار هر وبسایت HTTP/HTTPS با k6. پروژه برای WordPress تنظیمات نمونه دارد، اما به WordPress وابسته نیست و روی Windows و Linux اجرا میشود.
- تست هر وبسایت HTTP یا HTTPS، از صفحه اصلی تا مسیرهای دلخواه
- دو حالت اجرا: کاربر مجازی (
vus) و نرخ ثابت درخواست (rps) - حالت کشف خودکار ظرفیت (
capacity) با توقف روی کندی یا خطاهای 500/502/503 - افزایش و کاهش تدریجی بار در حالت VU
- آستانههای آماده برای نرخ خطا و زمان پاسخ p95/p99
- متریکهای اختصاصی
site_page_durationوsite_5xx_rate - اجراکننده PowerShell برای Windows و Bash برای Linux
- سرویس اجباری دریافت، تست و انتخاب پراکسی متناسب با مقصد در آغاز هر اجرا
- providerهای HTTP، SOCKS4 و SOCKS5 با فایل JSON قابل ویرایش
- حذف خودکار IPهای خصوصی/رزروشده و محدودیت اندازه، تعداد، timeout و concurrency
- توقف قطعی بهجای fallback ناخواسته روی IP اصلی
git clone https://github.com/ZamaniDeveloper/wordpress-load-test.git
cd wordpress-load-testنصب k6 روی Windows:
winget install k6 --source winget
k6 version
Copy-Item .env.example .envنصب k6 روی Debian/Ubuntu:
sudo gpg -k
curl -fsSL https://dl.k6.io/key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/k6-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update
sudo apt-get install k6 python3 curl
cp .env.example .env
chmod +x run-load-test.shFedora/CentOS:
sudo dnf install https://dl.k6.io/rpm/repo.rpm
sudo dnf install k6 python3 curl
cp .env.example .env
chmod +x run-load-test.shحداقل TARGET_URL و مسیرهای موردنیاز را در .env تنظیم کنید:
TARGET_URL=https://example.com
MODE=vus
VUS=10
RAMP_UP=1m
HOLD=3m
RAMP_DOWN=1m
PATHS=/,/pricing,/contactWindows:
.\run-load-test.ps1Linux:
./run-load-test.shاجرای مستقیم و بدون launcher نیز ممکن است:
TARGET_URL=https://example.com PATHS=/,/about k6 run site-load-test.jsبرای WordPress فقط مسیرها را متناسب با سایت تغییر دهید:
PATHS=/,/blog/,/?s=wordpress,/wp-json/| متغیر | کاربرد | نمونه |
|---|---|---|
TARGET_URL |
آدرس پایه سایت هدف | https://example.com |
PATHS |
مسیرهای جداشده با کاما | /,/pricing,/contact |
MODE |
روش اجرا: vus یا rps |
rps |
SLEEP |
مکث میان تکرارهای هر VU | 1 |
VUS |
تعداد کاربران مجازی | 10 |
RAMP_UP / HOLD / RAMP_DOWN |
مراحل حالت VU | 1m / 3m / 1m |
RATE / TIME_UNIT / DURATION |
نرخ و مدت حالت RPS | 100 / 1s / 3m |
PRE_ALLOCATED_VUS / MAX_VUS |
ظرفیت حالت RPS | 80 / 250 |
این حالت بدون تداخل با vus و rps بهصورت یک گزینه مستقل فعال میشود. در سادهترین حالت فقط mode و نرخ شروع را مشخص کنید:
MODE=capacity
RATE=10با تنظیمات پیشفرض، نرخ بهاندازه RATE بالا میرود و در هر پله حداقل ۵۰ درخواست بررسی میشود. تنظیم کامل:
MODE=capacity
RATE=10
CAPACITY_RATE_STEP=10
CAPACITY_MAX_RATE=500
CAPACITY_REQUESTS_PER_STEP=50
CAPACITY_P95_LIMIT_MS=3000
CAPACITY_FAILURE_RATE_LIMIT=0.05
PRE_ALLOCATED_VUS=100
MAX_VUS=1000تست از ۱۰ درخواستبرثانیه شروع میشود و بهترتیب نرخهای ۲۰، ۳۰ و بیشتر را بررسی میکند. هر پله در یکی از شرایط زیر ناموفق محسوب میشود و تست متوقف میشود:
- مشاهده هر پاسخ HTTP با وضعیت 500، 502 یا 503
- عبور p95 زمان پاسخ از
CAPACITY_P95_LIMIT_MS - عبور نرخ شکست از
CAPACITY_FAILURE_RATE_LIMIT - ثبت dropped iteration یا ناتوانی load generator در تولید درخواستها
خروجی، آخرین نرخ سالم، اولین نرخ ناموفق، تعداد کل درخواستها و دلیل توقف را اعلام میکند. گزارش کامل هر اجرا در مسیر زیر ذخیره میشود:
results/capacity-YYYYMMDD-HHMMSS/capacity-report.json
پیش از حالت ظرفیت، پراکسیها همیشه روی TARGET_URL دوباره آزمایش میشوند. ابتدا بازهٔ محافظهکارانهٔ نرخ پراکسیها نمایش داده میشود، سپس بعد از مهلت توقف، کشف ظرفیت واقعی مسیر پراکسی آغاز میشود. عدد نهایی ظرفیت کل مسیر پراکسی است، نه ظرفیت خالص سرور.
پراکسی برای تمام درخواستهای تست اجباری است و امکان fallback به اتصال مستقیم وجود ندارد. launcher در شروع هر اجرا منابع را دریافت و پراکسیها را دقیقاً روی TARGET_URL آزمایش میکند:
PROXY_PROVIDERS_FILE=proxy-providers.json
MAX_PROXY_CANDIDATES=100
MAX_WORKING_PROXIES=5
PROXY_TEST_CONCURRENCY=10
PROXY_PREFLIGHT_DELAY_SECONDS=10
PROXY_FINAL_CHECK_TIMEOUT_SECONDS=5بعد از preflight، تعداد پراکسیهای سازگار، کمترین و بیشترین نرخ تخمینی و سریعترین پراکسی نمایش داده میشود. این بازه از latency و با فرض یک درخواست همزمان برای هر پراکسی محاسبه میشود؛ بنابراین حد قطعی ظرفیت نیست. مهلت PROXY_PREFLIGHT_DELAY_SECONDS (بین ۰ تا ۳۰۰ ثانیه) اجازه میدهد پیش از شروع بار تست را لغو کنید. پس از مهلت، پراکسی منتخب یک بار دیگر بررسی میشود و در صورت خرابی گزینهٔ بعدی انتخاب خواهد شد. گزارش کامل در .proxy-cache/working-proxies.txt.json ذخیره میشود.
فایل proxy-providers.json شامل منابع درخواستی TheSpeedX برای HTTP، SOCKS4 و SOCKS5 و منابع Proxifly است. نگاشت typeها:
| Type | پروتکل | امکان انتخاب برای k6 |
|---|---|---|
1 |
HTTP | بله |
4 |
SOCKS4 | فقط دریافت، تست و ذخیره |
5 |
SOCKS5 | بله |
SOCKS4 توسط transport استاندارد k6 پشتیبانی نمیشود؛ بنابراین اعتبارسنجی و در فایل ذخیره میشود اما launcher آن را برای k6 انتخاب نمیکند. HTTP و SOCKS5 قابل انتخاباند. هر اجرای k6 سریعترین پراکسی سازگارِ همان preflight را انتخاب میکند.
تازهسازی دستی در Windows:
.\Update-ProxyPool.ps1 -TestUrl "https://example.com" -MaxCandidates 50 -MaxWorking 10تازهسازی دستی در Linux:
python3 proxy_pool.py --providers proxy-providers.json --test-url https://example.com --max-candidates 50 --max-working 10MAX_WORKING_PROXIES سقف ذخیره برای هر پروتکل است. پروکسیهای سالم در .proxy-cache/working-proxies.txt ذخیره میشوند و این پوشه در Git ثبت نمیشود. اگر هیچ HTTP یا SOCKS5 سالمی وجود نداشته باشد، اجرای k6 متوقف میشود.
Caution
پروکسی عمومی قابل اعتماد یا محرمانه نیست. کوکی ورود، توکن، رمز عبور یا داده حساس را از آن عبور ندهید. پروکسی میتواند نتیجه latency را نیز مخدوش کند؛ برای benchmark دقیق، تست مستقیم و تست proxy را جدا گزارش کنید.
A lightweight, configurable k6 load-testing toolkit for any HTTP/HTTPS website. It includes WordPress examples but is not WordPress-specific, and it runs on Windows and Linux.
- Test any HTTP or HTTPS website with configurable paths
- Virtual-user (
vus) and constant request-rate (rps) modes - Automatic
capacitydiscovery that stops on latency or HTTP 500/502/503 errors - Configurable VU ramp-up, steady load, and ramp-down stages
- Ready-to-use failure and p95/p99 latency thresholds
- Custom
site_page_durationandsite_5xx_ratemetrics - PowerShell launcher for Windows and Bash launcher for Linux
- Mandatory destination-aware proxy download, validation, and selection before every run
- Editable JSON providers for HTTP, SOCKS4, and SOCKS5
- Private/reserved IP filtering and bounded size, count, timeout, and concurrency
- Hard failure instead of silently exposing the direct IP
git clone https://github.com/ZamaniDeveloper/wordpress-load-test.git
cd wordpress-load-testWindows:
winget install k6 --source winget
k6 version
Copy-Item .env.example .envDebian/Ubuntu:
sudo gpg -k
curl -fsSL https://dl.k6.io/key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/k6-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update
sudo apt-get install k6 python3 curl
cp .env.example .env
chmod +x run-load-test.shFedora/CentOS:
sudo dnf install https://dl.k6.io/rpm/repo.rpm
sudo dnf install k6 python3 curl
cp .env.example .env
chmod +x run-load-test.shEdit .env and set at least the target URL and paths:
TARGET_URL=https://example.com
MODE=vus
VUS=10
RAMP_UP=1m
HOLD=3m
RAMP_DOWN=1m
PATHS=/,/pricing,/contactWindows:
.\run-load-test.ps1Linux:
./run-load-test.shDirect execution without a launcher:
TARGET_URL=https://example.com PATHS=/,/about k6 run site-load-test.jsFor WordPress, simply use WordPress-specific paths:
PATHS=/,/blog/,/?s=wordpress,/wp-json/| Variable | Purpose | Example |
|---|---|---|
TARGET_URL |
Target site's base URL | https://example.com |
PATHS |
Comma-separated paths | /,/pricing,/contact |
MODE |
vus or rps execution mode |
rps |
SLEEP |
Delay between VU iterations | 1 |
VUS |
Virtual-user count | 10 |
RAMP_UP / HOLD / RAMP_DOWN |
VU stages | 1m / 3m / 1m |
RATE / TIME_UNIT / DURATION |
RPS rate and duration | 100 / 1s / 3m |
PRE_ALLOCATED_VUS / MAX_VUS |
RPS-mode capacity | 80 / 250 |
This mode is independent of the existing vus and rps modes. At minimum, set the mode and starting rate:
MODE=capacity
RATE=10By default, the rate increases by RATE and each step evaluates at least 50 requests. Full configuration:
MODE=capacity
RATE=10
CAPACITY_RATE_STEP=10
CAPACITY_MAX_RATE=500
CAPACITY_REQUESTS_PER_STEP=50
CAPACITY_P95_LIMIT_MS=3000
CAPACITY_FAILURE_RATE_LIMIT=0.05
PRE_ALLOCATED_VUS=100
MAX_VUS=1000The test starts at 10 requests per second and evaluates 20, 30, and subsequent rates. A step is unhealthy and stops discovery when any of these conditions occurs:
- any HTTP 500, 502, or 503 response
- p95 response time exceeds
CAPACITY_P95_LIMIT_MS - failure rate exceeds
CAPACITY_FAILURE_RATE_LIMIT - dropped iterations or insufficient emitted requests indicate load-generator saturation
The result reports the last healthy rate, first unhealthy rate, total requests, and stop reason. Detailed output is stored at:
results/capacity-YYYYMMDD-HHMMSS/capacity-report.json
Before capacity discovery, proxies are always revalidated against TARGET_URL. The launcher prints a conservative proxy-rate range, waits for the cancellation window, and then measures the actual proxied path capacity. The final number is end-to-end proxy-path capacity, not server-only capacity.
Proxy use is mandatory for every load-test request, with no fallback to a direct connection. At the beginning of every run, the launcher downloads candidates and validates them against the exact TARGET_URL:
PROXY_PROVIDERS_FILE=proxy-providers.json
MAX_PROXY_CANDIDATES=100
MAX_WORKING_PROXIES=5
PROXY_TEST_CONCURRENCY=10
PROXY_PREFLIGHT_DELAY_SECONDS=10
PROXY_FINAL_CHECK_TIMEOUT_SECONDS=5After preflight, the launcher prints the compatible proxy count, estimated minimum/maximum request rate, and fastest proxy. The range is derived from measured latency using a one-in-flight-request-per-proxy model, so it is guidance rather than a hard capacity limit. PROXY_PREFLIGHT_DELAY_SECONDS accepts 0–300 seconds and provides a cancellation window before load begins. After that window, the selected proxy is checked again and the launcher falls back to the next validated proxy if needed. The complete report is saved to .proxy-cache/working-proxies.txt.json.
proxy-providers.json includes the requested TheSpeedX HTTP, SOCKS4, and SOCKS5 sources plus Proxifly sources. Provider type mapping:
| Type | Protocol | Selectable by k6 |
|---|---|---|
1 |
HTTP | Yes |
4 |
SOCKS4 | Download, validation, and storage only |
5 |
SOCKS5 | Yes |
The standard k6 transport does not support SOCKS4, so SOCKS4 entries are validated and cached but never selected by the launcher. HTTP and SOCKS5 are selectable. Each k6 process selects the fastest compatible proxy found by that run's preflight.
Manual refresh on Windows:
.\Update-ProxyPool.ps1 -TestUrl "https://example.com" -MaxCandidates 50 -MaxWorking 10Manual refresh on Linux:
python3 proxy_pool.py --providers proxy-providers.json --test-url https://example.com --max-candidates 50 --max-working 10MAX_WORKING_PROXIES is the storage limit per protocol. Working proxies are stored in .proxy-cache/working-proxies.txt, which is excluded from Git. The launcher stops if it cannot find a working HTTP or SOCKS5 proxy.
Caution
Public proxies are neither trusted nor private. Never send login cookies, tokens, passwords, or sensitive data through them. Proxies also distort latency measurements, so report direct and proxied benchmarks separately.