How to Test Forward Proxy Performance

Question

I am using squid as forward proxy server . How Can I test performance of squid ? Is there any tools to test proxy server ? I am using ab2 tools for my test . Is it good enough to get trust-able Result ?

Answer 1

Theoretically you can use -X parameter so traffic will go through squid, however interpreting the results won't be that easy.

I would choose one of the following tools:

• Gatling
• Grinder
• Tsung
• Apache JMeter

See Open Source Load Testing Tools: Which One Should You Use? guide for more information on above options including sampler load reports.

Given you're asking about ab I guess you're Linux user, so the chance you go for Tsung is quite high. Check out Benchmarking a proxy server documentation chapter in that case.

Answer 2

Forward Proxy Performance

Performance

Performance can mean a lot of things. The least interesting but most widely cited benchmark for this kind of server is “how many 1k responses can it serve from memory per second?” but that doesn’t tell you how it will do serving 200K (or 200M) responses from disk, which is a much more difficult thing to manage.

Try looking at:

1. Persistent connections

   — support is necessary for good performance, and a good proxy server should be able to handle tens of thousands of idle connections with nearly no overhead. This means epoll, kqueue, libevent or similar under the covers. Make sure it supports HTTP/1.1 chunked encoding as well.

2. Hit rates

   — it’s necessary to test the code paths both to the cache and forward to the origin server.

3. Response sizes

   — seeing how a server handles large vs. small responses can be revealing about its internal pipeline; if the data is copied a lot, large responses will have a disproportionate effect.

4. Response latency

   — inter mediation means adding an extra layer, so it’s critical that it doesn’t add latency as well. A proxy should be able to serve a hit in less than a millisecond, easy.

5. Overload behavior

   — when the proxy gets overloaded, it should degrade gracefully.

6. Disk traffic

   — Disk caching is much more difficult to get right. Testing this is tricky, because you have to have a working set bigger than the memory cache. See polygraph for a start.

7. Cache efficiency

   — some implementations take shortcuts which improve benchmark speeds by making the cache less than perfectly efficient for a given workload. This may or may not be good for your use case, but you need to be aware of it.

8. Extra features

   — often, caches are bench marked with everything “extra” — e.g., logging, ACLs — turned off. If they’re in the critical path, these can affect performance greatly.

9. Per-object overhead

   — caches need to be able to find things quickly, and this means some level of per-cached-response overhead in memory. The amount of overhead can limit the overall Scalability of your cache (because it consumes too much memory), but sometimes having more metadata in memory helps the cache be more efficient.