Check Nginx & Apache Response Time with curl and ab
Check Nginx & Apache Response Time with curl and ab
Monitor Nginx and Apache response times to track web server performance, identify slow responses, and optimize server configuration. This guide shows you how to check response times and set up automated monitoring.
For comprehensive web server monitoring, see Application Performance Monitoring. For troubleshooting web server issues, see Nginx Apache 502 Bad Gateway Error.
Why Checking Response Times Matters
Web server response times directly impact user experience. Slow response times cause poor user experience, increased bounce rates, and potential SEO penalties. Monitoring response times helps maintain optimal server performance.
Method 1: Check Response Times with curl
Measure Response Time
# Basic response time check
time curl -o /dev/null -s -w "%{time_total}" http://localhost/
# Check response time with details
curl -o /dev/null -s -w "Time: %{time_total}s\nHTTP Code: %{http_code}\n" http://localhost/
# Check multiple endpoints
for url in http://localhost/ http://localhost/api http://localhost/health; do
echo -n "$url: "
curl -o /dev/null -s -w "%{time_total}s\n" $url
done
Monitor Response Times Over Time
# Monitor response time continuously
while true; do
TIME=$(curl -o /dev/null -s -w "%{time_total}" http://localhost/)
echo "$(date): $TIME seconds"
sleep 5
done
Method 2: Check Response Times from Access Logs
Analyze Nginx Access Logs
# Check response times from Nginx logs
tail -100 /var/log/nginx/access.log | awk '{print $NF}' | sort -n
# Calculate average response time
tail -1000 /var/log/nginx/access.log | awk '{sum+=$NF; count++} END {print "Average:", sum/count, "seconds"}'
# Find slow requests
tail -1000 /var/log/nginx/access.log | awk '$NF > 1.0 {print $NF, $7}'
Analyze Apache Access Logs
# Check response times from Apache logs
tail -100 /var/log/apache2/access.log | awk '{print $NF}' | sort -n
# Calculate average response time
tail -1000 /var/log/apache2/access.log | awk '{sum+=$NF; count++} END {print "Average:", sum/count, "seconds"}'
# Find slow requests
tail -1000 /var/log/apache2/access.log | awk '$NF > 1.0 {print $NF, $7}'
Method 3: Check Response Times with ab (Apache Bench)
Benchmark Response Times
# Install Apache Bench
sudo apt-get install apache2-utils # Debian/Ubuntu
sudo yum install httpd-tools # CentOS/RHEL
# Benchmark response time
ab -n 100 -c 10 http://localhost/
# Get detailed timing information
ab -n 100 -c 10 -v 2 http://localhost/
Method 4: Automated Response Time Monitoring with Zuzia.app
Manual checks work while you are looking. To keep running them without you, Zuzia uses its agent and scheduled tasks.
How it works in Zuzia
- Install the Zuzia agent on the server with one command. CPU, RAM, disk, load and network metrics start reporting on their own, with alerts on a threshold, on drift from the server's normal, or on a disk fill-up forecast.
- Save the commands from this guide as a scheduled task and choose how often it runs, from every minute to once a year. The agent runs it on every host you pick.
- If a command fails, you get an alert right away by email, Slack, Discord, push (through your Pushover account) or SMS (through your Vonage account).
- The output of every run is kept, so you can look back at what changed. On paid plans, AI can read the output and alert you only when it spots a problem.
Setting it up
- Add the server in the Zuzia dashboard and install the agent.
- Create a scheduled task with the check commands below, then choose the hosts and how often it runs.
- Choose your notification channels. Turn on maintenance mode during planned work so it doesn't trigger alerts.
Best Practices for Response Time Monitoring
1. Monitor All Critical Endpoints
- Track response times for main pages
- Monitor API endpoint response times
- Check health check endpoints
- Track admin panel response times
2. Monitor Response Times Continuously
- Track response times regularly
- Alert when response times exceed thresholds
- Monitor response time trends
- Optimize based on data
3. Set Appropriate Thresholds
- Set thresholds based on application requirements
- Adjust thresholds for different endpoints
- Monitor response time percentiles (P95, P99)
- Alert on response time degradation
4. Correlate Response Times with Other Metrics
- Compare response times with server resources
- Correlate with application errors
- Monitor response times during peak traffic
- Identify performance bottlenecks
Troubleshooting Slow Response Times
Step 1: Identify Slow Response Causes
When response times are slow:
# Check current response time
curl -o /dev/null -s -w "%{time_total}" http://localhost/
# Check server resources
top -b -n 1 | head -5
# Check web server status
systemctl status nginx
systemctl status apache2
Step 2: Optimize Response Times
Based on investigation:
Optimize Web Server Configuration:
- Tune worker processes
- Optimize caching settings
- Adjust connection limits
Optimize Application Performance:
- Optimize database queries
- Implement caching
- Optimize application code
Scale Infrastructure:
- Add more web servers
- Implement load balancing
- Optimize server resources
FAQ: Common Questions About Response Time Monitoring
What is considered slow response time?
Slow response time depends on your application type. Generally, response times under 200ms are excellent, 200-500ms are good, 500ms-1s are acceptable, and over 1s are slow. Set thresholds based on your requirements.
How often should I check response times?
For production web servers, continuous automated monitoring is essential. Zuzia.app can check response times every few minutes, storing historical data and alerting you when response times exceed thresholds.
How do I improve response times?
Improve response times by optimizing web server configuration, implementing caching, optimizing database queries, optimizing application code, and scaling infrastructure if needed.
Can response time monitoring impact server performance?
Response time monitoring commands have minimal impact on server performance when done correctly. Use appropriate monitoring frequency and avoid monitoring during peak traffic periods.
Related guides, recipes, and problems
Related guides
guides--monitoring-application-performance-linux.mdguides--server-performance-monitoring-best-practices.md
Related recipes
recipes--check-api-endpoint-response-status.mdrecipes--check-web-server-error-rate-4xx-5xx.md
Related problems
problems--nginx-apache-502-bad-gateway-error.mdproblems--api-endpoint-slow-response-times.md