测试Squid代理性能（Kerberos认证场景）

Got it, since you need to stress-test a proxy server that uses pure Kerberos auth (no NTLM) and JMeter isn't cutting it because it's hitting the Kerberos service directly instead of going through the proxy, here are some free, practical tools and approaches to get the job done:

• kinit + curl/wget + Shell/Python Scripting
  This is a lightweight, flexible approach if you want full control over the test flow.

  1. First, use kinit to obtain a Kerberos TGT for a test user:

     kinit testuser@YOUR.REALM
     

  2. Use curl to send requests through the proxy with Kerberos negotiation enabled:

     curl --proxy http://your-proxy:port --negotiate -u : http://target-service.example.com/
     

     The -u : triggers Kerberos auth without specifying credentials (it uses the cached TGT from kinit).
  3. Wrap this in a shell script or Python script to simulate concurrent requests. For example, use GNU parallel to run multiple curl instances in parallel:

     parallel -j 50 curl --proxy http://your-proxy:port --negotiate -u : http://target-service.example.com/ ::: {1..1000}
     

     Or use Python's threading/concurrent.futures module to build a more structured load test with metrics tracking.

• Locust
  Locust is an open-source load-testing tool that lets you define test scenarios in Python, making it easy to customize Kerberos+proxy flows.

  1. Install Locust and the requests-kerberos library:

     pip install locust requests-kerberos
     

  2. Write a test script that configures the proxy and Kerberos auth:

     from locust import HttpUser, task, between
     from requests_kerberos import HTTPKerberosAuth, OPTIONAL
     
     class KerberosProxyUser(HttpUser):
         wait_time = between(1, 3)
         proxy_url = "http://your-proxy:port"
         auth = HTTPKerberosAuth(mutual_authentication=OPTIONAL)
     
         def on_start(self):
             self.client.proxies = {
                 "http": self.proxy_url,
                 "https": self.proxy_url
             }
     
         @task
         def access_target_service(self):
             self.client.get("/", auth=self.auth)
     

  3. Run Locust and use its web UI to set concurrent user counts and spawn rates to stress-test the proxy.

• Gatling
  Gatling is a high-performance load-testing tool built on Scala, with good support for Kerberos and proxy configurations.

  1. Download Gatling's free open-source version and set up your test scenario in a Scala file.
  2. Configure the proxy and Kerberos auth (ensure you disable NTLM to enforce pure Kerberos):

     import io.gatling.core.Predef._
     import io.gatling.http.Predef._
     import scala.concurrent.duration._
     
     class KerberosProxyLoadTest extends Simulation {
         val httpProtocol = http
             .proxy(Proxy("your-proxy", port)
                 .httpsPort(port))
             .authorizationHeader("Negotiate ${kerberosToken}")
             .disableFollowRedirects
     
         val scn = scenario("Kerberos Proxy Stress Test")
             .exec(http("Request to Target Service")
                 .get("http://target-service.example.com/"))
     
         setUp(
             scn.inject(
                 rampUsers(100) during (10 seconds),
                 constantUsersPerSec(50) during (5 minutes)
             )
         ).protocols(httpProtocol)
     }
     

  3. Gatling will handle Kerberos ticket negotiation automatically (make sure your test machine has a valid krb5.conf and cached TGT via kinit).

• Apache Bench (ab)
  If you prefer a simple command-line tool, ab (Apache Bench) can work with Kerberos and proxies, provided it's compiled with Kerberos support (most default installations are).

  1. First, obtain a TGT with kinit.
  2. Run ab with the proxy, Kerberos negotiation, and desired load parameters:

     ab -X http://your-proxy:port -n 1000 -c 50 --negotiate http://target-service.example.com/
     

     The -n flag sets total requests, -c sets concurrent requests, and --negotiate enables Kerberos auth.

Key Notes for Testing #

• Ensure your test environment has a properly configured krb5.conf pointing to your KDC.
• Use multiple test users if possible (rotate TGTs with kinit for different users) to simulate real-world load more accurately.
• Monitor the proxy server's metrics (CPU, memory, auth request latency) and KDC logs during testing to identify overload points.

内容的提问来源于stack exchange，提问作者Nav Svarigi