Forum Discussion
satish_txt_2254
Cirrus
CirrusAWS ELB vs F5 SSL TPS calculation
We are running AWS ELB in cloud and now planning to bring it to our datacenter and it is going to be F5.
Now i need to understand ELB first to understand how much request we are processing and TPS i need to get new F5 box to handle that request.
AWS ELB cloudwatch has very strange metrics and not very clear to understand so may be you folks can help here.
ActiveConnectionCount per sec
Request Count per sec
Does above graph indicating i need to buy F5 which can handle 20k SSL TPS or 800k TPS?
Hannes_RappNimbostratus
Hello,
Reference: https://www.f5.com/pdf/products/big-ip-platforms-datasheet.pdf
- Based on first observation, I'd say i5800
800K SSL TPS is a definite overkill. I assume your apps are HTTP1.1 that can re-use same TCP and SSL session for multiple L7 requests. Can you also paste "EstimatedALBNewConnectionCount"? Currently it's greyed out in your upper graph.
That lower graph shows you "L7 Requests per second" that you can refer to in hardware datasheet. Graph shows a peak of 800K but you definitely need more to cover peak activity months/hours of the year. You also need some room for growth and not spend dollars for hardware that you outgrow in 1 year. Assume 1.6M L7 requests your requirement when making a decision.
satish_txt_2254Does 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
caching won't work right?SSL- Hannes_Rapp
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,
- satish_txt_2254
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?
Hannes_Rapp_162Nacreous
Hello,
Reference: https://www.f5.com/pdf/products/big-ip-platforms-datasheet.pdf
- Based on first observation, I'd say i5800
800K SSL TPS is a definite overkill. I assume your apps are HTTP1.1 that can re-use same TCP and SSL session for multiple L7 requests. Can you also paste "EstimatedALBNewConnectionCount"? Currently it's greyed out in your upper graph.
That lower graph shows you "L7 Requests per second" that you can refer to in hardware datasheet. Graph shows a peak of 800K but you definitely need more to cover peak activity months/hours of the year. You also need some room for growth and not spend dollars for hardware that you outgrow in 1 year. Assume 1.6M L7 requests your requirement when making a decision.
- satish_txt_2254
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
caching won't work right?SSL - Hannes_Rapp_162
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,
- satish_txt_2254
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?