Settings
Enter your FedEx API credentials. These are held in memory only and will be purged when you close the browser.
This portal stores no data. Credentials and test results are held in server memory only during your active session. When you close the browser or session expires, all data is purged. No database, no files persisted.
FedEx API Credentials
Run Test
Configure the API payload filters and run the stability test.
Payload Filters
Run Options
Stateless Request-per-Page
Each API page request establishes a new TCP connection, sends the request, receives the response, then closes the connection. The next page opens a fresh connection using the continuation token from the previous response.
Pros: Surfaces connection-level errors (Error 104, TCP handshake failures) at every page boundary — accurate per-page reliability metrics. Maximizes exposure to connection-reset conditions.
Cons: Slightly slower due to TCP handshake overhead on each request. May produce higher error rates since no warm connection is reused.
Persistent Connection (HTTP Keep-Alive)
Maintains a single TCP connection across all page requests. The first request establishes the connection; subsequent requests reuse it via HTTP keep-alive, avoiding repeated TCP handshakes.
Pros: Faster overall throughput. Fewer connection-level errors since the warm connection is reused. Simulates how a production application with a connection pool would behave.
Cons: May mask intermittent connection resets that occur at connection establishment. Error 104 events will be underreported compared to real-world stateless usage patterns.
Diagnostic value: Running the same test in both modes lets you compare error rates between connection strategies. Differences in results may indicate where connection resets are occurring, but further investigation would be needed to determine the root cause.
Each API page request establishes a new TCP connection, sends the request, receives the response, then closes the connection. The next page opens a fresh connection using the continuation token from the previous response.
Pros: Surfaces connection-level errors (Error 104, TCP handshake failures) at every page boundary — accurate per-page reliability metrics. Maximizes exposure to connection-reset conditions.
Cons: Slightly slower due to TCP handshake overhead on each request. May produce higher error rates since no warm connection is reused.
Persistent Connection (HTTP Keep-Alive)
Maintains a single TCP connection across all page requests. The first request establishes the connection; subsequent requests reuse it via HTTP keep-alive, avoiding repeated TCP handshakes.
Pros: Faster overall throughput. Fewer connection-level errors since the warm connection is reused. Simulates how a production application with a connection pool would behave.
Cons: May mask intermittent connection resets that occur at connection establishment. Error 104 events will be underreported compared to real-world stateless usage patterns.
Diagnostic value: Running the same test in both modes lets you compare error rates between connection strategies. Differences in results may indicate where connection resets are occurring, but further investigation would be needed to determine the root cause.
Tracking Detail
Browse tracking results from the last run. Data is paginated for performance.
No results available. Run a test first.
Jump to:
| No data |
|---|
Dashboard
Visual analysis of tracking results from the last run.
No data available. Run a test first.
Technical Summary
Detailed reliability metrics from the last run.
No run data available. Run a test first.