基于MVC3与Telerik的网站上线后远程访问性能异常求助

Hey there, let’s work through this tricky performance issue you’re facing. The key clue here is that everything runs smoothly on the production server locally, but remote users are stuck waiting 40-50 seconds per page. Since you’ve already ruled out database issues and confirmed dev/QA environments work fine, we can focus on the gap between local and remote server behavior.

1. Network & Routing Checks #

• Verify DNS resolution for remote users: Have them run nslookup your-site-domain.com and compare the returned IP to the production server’s actual IP. Incorrect DNS records can send traffic down slow, indirect paths.
• Inspect proxies, firewalls, or load balancers: Any recent changes to these devices between remote users and your server could be throttling traffic or adding unnecessary latency. Look for rules that might be inspecting requests excessively.
• Run a traceroute from a remote machine: Use tracert your-site-domain.com (Windows) or traceroute your-site-domain.com (Linux/macOS) to pinpoint where the latency spikes occur—this tells you if the delay is in the network path or on your server.

2. Telerik Resource Loading Issues #

Since you’re using Telerik components, remote access might struggle with client-side resource delivery:

• Check if Telerik resources (scripts, styles, fonts) are served locally vs. from an external CDN. If using a CDN, confirm it’s reachable with low latency for remote users—some regions might have blocked or slow CDN access.
• Verify compression settings: Ensure your server sends gzip/deflate headers for Telerik resources. Some proxies strip these headers, forcing remote users to download uncompressed, larger files.
• Use browser dev tools (Network tab) from a remote machine: Identify which specific resources are taking the longest to load—you might find a stuck Telerik script or font request.

3. IIS & Application Pool Configuration #

You mentioned checking the application pool—here are specific details to validate:

• Confirm application pool identity permissions: Even if local access works, remote requests might trigger different resource paths (like temp folders for compiled views) that the identity can’t access efficiently.
• Check IIS request filtering: Look for overly strict rules (e.g., URL scanning, request length limits) that could delay remote requests.
• Enable detailed IIS logging: Turn on logging for "time-taken" and filter requests with >30s duration. This will show which parts of the request pipeline are dragging.

4. SSL/TLS Handshake Delays #

If your site uses HTTPS, SSL setup could be the bottleneck:

• Check TLS version and cipher suites: Outdated versions (TLS 1.0/1.1) or mismatched cipher suites between server and remote clients can slow down handshakes.
• Validate your SSL certificate: Expired or misconfigured certificates can cause clients to spend extra time validating trust.
• Test HTTP access temporarily: If remote users load pages faster over HTTP, the problem is definitely tied to SSL/TLS configuration.

5. MVC View Compilation & Caching #

MVC3’s view compilation can cause unexpected delays for remote users:

• Ensure web.config has <compilation debug="false" /> in production. Debug mode disables view caching and forces recompilation on every request, which kills performance for remote traffic.
• Check the temporary ASP.NET files folder: Verify the application pool identity has write access to C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files—corrupted or full folders can block view compilation.

内容的提问来源于stack exchange，提问作者Vladimir Semashkin