比方说，我有一个应用程序，允许客户创build一个帐户，并在他们的网站上，允许人们创build票据的forms。 与475客户谁拥有forms的网站。 每个账户每天获得约100份表格提交（平均每天总计47500张 ）。 如果您认为所有这些都是在一天中的8个小时内进行的， 那么每秒只能获得1.6张左右的票数 。
如果我正在购买负载均衡器，这是否意味着我只需要一个可以处理5个SSL TPS的东西 ？ 这对我来说似乎是荒谬的？
你每秒的平均连接数并不重要， 这是你必须担心的高峰。 为此，您需要更好地统计您的加载模式的样子。 如果你没有这个，我通常在24小时的平均水平上使用4：1的峰值/平均比率（所以对于你来说，你看1.6 / 3 * 4` – 3到24小时平均4，从平均值得到峰值 – 在峰值时每秒钟超过两个连接点）。
顺便说一下，这个比例只是来自于我对使用地理本地化用户库的网站的经验（就像你所build议的）。 我还有其他比例的全球用户群和“已知峰值”网站。 如果你采取最坏的情况，一个真正高峰的网站，我使用10：1的比率，所以你仍然只是看每秒超过五个连接。
就像安德鲁所说的那样，在这样的体积下，你甚至不应该在一台机器上冒汗。 我有一个网站，每台机器每秒处理几百个HTTP（S）连接（一个dynamic的网站，有很多的SSL连接） – 显然，这将会有很大的代码库差异，但是如果你每秒需要负载平衡五个SSL连接，这是非常非常错误的。
就个人而言，我不喜欢SSL加速负载平衡器，就像我的经验，他们只是为了一个全新的瓶颈 – 当您的网站变得足够stream行时，SSL加速器将无法跟上（升级这些东西获取昂贵）。 我更喜欢一个简单的TCP负载均衡器，在这个负载均衡器中，我可以简单地扩展我的后端，因为它们达到了容量（无论是因为SSL连接还是仅仅处理请求）。
你的math是正确的。 你甚至需要一个负载均衡器在这个数量？