Best practices for high traffic websites

Hi Luis. I'd not heard of the longtail issue before (it's very interesting) and I've not used WA in anger for a long time but just from a general TMOS and LTM perspective and the little research I've managed to do today;

1) Despite your CDN, I'd imagine you'd want as large a cache as possible

2) Enabling compression is essential - I'd also suggest you think hard around it's settings - I'll post more around this later

3) I was going to say think carefully about large files but I guess your CDN covers you there?

4) Pick your congestion control algorithm carefully based on the typical client profile

5) You may want to reduce the default TCP connection timeouts

6) Perhaps consider QoS or a similar mechanism to ensure smaller flows are not swamped

7) I'd imagine implementing OneConnect would be very worthwhile

8) I'd also image implementing SPDY would be of benefit

Apologies if this is all a bit obvious and generic. Perhaps you could provide more detail on the type of traffic, application and client profiles?

Thanks for your answer. Some of the suggestions apply to our site, some don't, but that's the kind of answer I tried to obtain.

I'm sure that most F5 systems are deployed on production by F5 specialists, but they will eventually be managed by the customer systems/operations team. That kind of users (as myself) may find these best practices useful when traffic grows unexpectedly or changes in backend applications require changes on many configurations. So even if your recommendations seem generic and obvious to F5 experts, they are useful and should be reminded from time to time.

Some more tips we've found:

• One connect is very helpful, when managing hundreds of simultaneous connections
• On the WA policy "Queue Parallel Requests" is also very useful to avoid the effects of popular media content, or new applications increasing the number of requests without previous warning.
• Also, on WA policy, "Cache only if the document contains matching begin and end tags" might avoid caching of internal applications' responses.
• Using a large cache is also required most of the times, and the default number of objects on wa profiles (1000) is very low for large sites.
• TCP connection timeouts should be in sync with those of the CDN. If your CDN will disconnect after 120 seconds, you shouldn't have larger timeouts.
• We are not using WA for large files (over 100MB), that would use resources from the F5 system, that can be better used serving and caching small files.

Regarding OneConnect @Stephan Manthey also provided some good evidence that it reduces client-side connections too.

"OneConnect works bi-directional regarding KeepAlive (along to connection multiplexing, de-multiplexing and request switching). In case your servers doesn´t allow KeepAlive, the KeepAlive on clientside will still be maintained. OneConnect simply replaces the server´s 'Connection: close' by an 'X-cnection: close'. This helps to keep the clientside KeepAlive open. In a real world scenario it lowered the clientside TCP connection rate and TPS rate by 50+ percent."