This is Devon Bleak's Typepad Profile.
Join Typepad and start following Devon Bleak's activity
Join Now!
Already a member? Sign In
Devon Bleak
Recent Activity
Awesome updates :-) @Johann - TCP window size/scaling only governs incoming data to the system in question. In this case it's allowing the origin (or end-user, in the case of a large request payload) to send ~64MB of data to CF all at once rather than the previous value of ~256kb. Receiving data faster from the origin means CF can better saturate the link to the end-user for stuff that's not already in its cache, but the window size to the end-user is still governed by their TCP stack settings which is why you were probably not seeing much of an improvement in your tests. @Alex Smithq - You should see a drop in overall load times for your use case due to the persistent origin connections - your users wouldn't be having to wait on a lengthy three-way handshake back to your origin, instead making a much faster three-way handshake to CF's closest cache. For users that are very remote from your origin but very close to a CF cache you can expect to see upwards of .5s shaved off overall request time (assuming the CF cache node in question already has a persistent connection open to your origin). For smaller dynamic payloads that generally fit within the initial tcp window for the connection you're not likely to see much of an improvement beyond that. You could achieve similar results using HTTP keep-alives between your origin and end-users, but this has the advantages of also caching your static content, giving you the option of setting/tuning short non-zero TTLs on things that are dynamic but don't need to be real-time, and being able to keep way fewer idle connections open to your origin.
Devon Bleak is now following The Typepad Team
May 14, 2012