AWS ELB vs F5 SSL TPS calculation

Are you sure AWS

RequestCount

Where did you read that? As I already said this is "L7 Requests per second" counter not SSL TPS. Your SSL TPS can't be over 25k.

If you want to be safe and reserve some room for growth, go for i5800. If tight on budget, i5600 or even i4800 might be enough. i4600 will not suffice because it can only handle 650K L7 requests per second. We do not know if all your TCP connections are encrypted for HTTPS or if some are plain HTTP. With such TCP connection counters we can only make rough guesses.

My answer is i5800 is the appliance to go for. If you are unsure with my recommendation, go to AWS community forums or ask their support. Try to figure out exact numbers you can refer to in F5 product datasheet. Once you have numbers, cherry-picking your appliance is straight forward. If you prefer not make decision yourself, just open a thread here or turn to your local F5 reseller.

3 Numbers should suffice.

During peak hours:

1. SSL TPS. (Take note that hardware SSL TPS numbers are different for ephemeral keys and RSA. Perhaps something to keep in mind if your company policy is to only use ephemeral key suites)
2. TCP Connections per second
3. L7 Requests per second

Regards,

Totally agreed with your answer here, i am planning to get F5 10200v so handle future growth too. we are only handling very small API calls, its very small piece of data every client makes, our application isn't browsable, all it does make API call and get xml data back.

Any specific suggestion for tuning?

Seems like you're all set then. 10200v will cover capacity needs for years to come.

Go with DNS/FQDN or raw IP?

With any short-lived connection applications, DNS name-resolution delay should not be taken as lightly as with your typical long-lived web frontend. In AWS, you have Route53 which should be replaced with similar enterprise DNS provider to not lose those valuable milliseconds. If you have any significant number of clients that are not isolated to a single state, go with a DNS service provider that has good global spread.

On the other hand, if you have a few major clients and no minor ones, don't even use DNS/FQDN name. Go solely with IP-port combo API calls for best outcome. When given a choice, a heavy client of your API would much prefer any performance gains over the benefit of using FQDN target in their API calls. Another flaw of using DNS is exposure to risk of service downtime due to DNS problems. The risk is minimal but a DNS provider can go down (i.e. to a DOS attack) and bring down your service with itself. This happened on a massive scale to Dyn DNS clients not too long ago.

BigIP configuration?

Let's look at this once you're past initial setup phase. There are a number of settings to consider, most notably TCP profile, HTTP compression profile, cache (Web Acceleration) profile. Depending on how much response payload there is, and how dynamic it is, we can determine best settings to use. To figure out best configuration, I normally start with default configuration that "just works", and then capture ~50 API calls and responses with full payload and headers to have a reference to work with.

Regards,

Does F5 cache XML style data? we have many clients coming all over the world and they ask for piece of info in xml format amd 90% they ask for same call and same data they get back it would be good if F5 do some caching magic so it will offload work from web servers but i believe in

SSL