We run our servers on Amazon Web Services and use their elastic load balancer (which is were we terminate SSL).
which is _why_ (?)
We run our servers on Amazon Web Services and use their elastic load balancer (which is were we terminate SSL).
which is _why_ (?)
But ELB is in no way a permanent part of our infrastructure (nothing is permanent) especially as we move to supporting technologies such as SPDY on spire.io or, for example for the right customer requirement, SSL throughout the network stack. We're also fond of Stud running on our internal servers. I do think ELB is the right tool for our cloud today.
https://forums.aws.amazon.com/thread.jspa?messageID=327283 https://forums.aws.amazon.com/thread.jspa?messageID=327715
We have seen issues with performance on ELB which is why we originally went with TCP mode HAProxy on the edge of our stack to a cluster of STunnel servers, but again reliability was an issue here and our ELB performance with up to 10K rps looks great in benchmarks. Past 10K we are considering separate dispatchers behind a separate ELB. But at that point I am also tempted to, frankly, switch to our own metal.
Curious: are you comparing ELB performance vs High I/O EC2 instances (say m1.xlarge) open to the world?
Regarding the comparison you suggest, we are too short-handed right know not only to do this kind of comparisons but even to think to manage our own load balancers ;) Thanks for the suggestion anyway.