在 EC2 上使用修改后的灯堆栈（Lighttpd 而不是 Apache）的网站随着其发展，最有可能遇到哪些扩展问题？
当您的用户数量增加时，EC2 上基于 Lamp 的站点通常会遇到哪些瓶颈（以及最先出现的瓶颈是什么）？
假设： -不错的数据库设计 - cron 上有一些 RAM 和 CPU 密集型进程，但在正常使用期间没有 RAM/CPU 密集型进程。
What are the usual bottlenecks (And what tends to break first) to Lamp based sites on EC2 when your number of users increase?
Assuming:
-Decent DB design
-There are some Ram and CPU intensive processes on cron but no ram/cpu intensive stuff during normal use.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好问题 - 我们用 Nginx 替换了 A，我们的 PHP 现在是 fpm 了。这使我们能够设置更多的应用程序平衡器来处理流量峰值等。我们还将主数据库移至 CouchDB (BigCouch)，但通常在不知道应用程序做什么的情况下没有避免灾难的方法。
EC2 瓶颈
EC2 瓶颈或问题更容易概括和确定。
磁盘 I/O
例如，一个非常普遍的瓶颈是磁盘 I/O。
尽管 EBS 比实例存储和持久性更快，但它也很慢。有多种方法可以提高 EBS 性能使用 RAID 设置，但它们永远无法让您接近 SAS 的速度。
网络延迟
另一个瓶颈是内部网络延迟。你不应该依赖任何即时的事情，我想这是云计算的一般经验法则。它最终确实是一致的，这也要求您的应用程序适应这一点并表现得不同。
容量
最后但并非最不重要的一点是容量错误。它们会发生 - 例如，您无法在同一区域中启动另一个实例。我也遇到过实例自行重启或消失的情况。所有这些事情都发生在云端，需要处理。
自动化，自动化！
迁移到 EC2 时最大的变化是放弃实际服务器并自动执行实例引导。之前我去DC搞了半天，架了新硬件，装了服务器等等。
能够启动和终止应用服务器，负载均衡器等是云最大的改变，也是最大的优势。它可以帮助您轻松处理很多很多问题。
Good question - we replaced the A with Nginx, our PHP is fpm'd now. And that allows us to setup more app balancers to handle traffic spikes and all that. We also moved the main database to CouchDB (BigCouch) but generally there is no recipe to avoid disaster without knowing what your application does.
EC2 bottlenecks
EC2 bottlenecks or issues are easier to generalize and pin down.
Disk i/o
E.g., a very general bottleneck is the disk i/o.
Even though EBS is faster than the instance storage and also persistence, it's also slow. There are ways to get more EBS performance using RAID setups, but they'll never get you near the speed of SAS.
Network latency
Another bottleneck is internal network latency. You shouldn't rely on anything being instant, and I guess that's the general rule of thumb with cloud computing. It really is eventually consistent, which also requires your app to adjust to that and behave different.
Capacity
Last but not least - capacity errors. They happen - e.g., you can't start another instance in the same zone. I've also had instances reboot themselves or disappear. All these things happen in the cloud and need to be dealt with.
Automate, automate!
The biggest change when moving to EC2 is to let go of actual servers and automate instance bootstrapping. Before I went to the DC for half a day and racked new hardware, installed servers, etc..
Being able to start up and terminate application servers, loadbalancers etc. is the biggest change and also the greatest advantage of the cloud. It helps you to deal with many, many issues easily.
您确实需要告诉我们更多有关您的申请的信息。什么破坏完全取决于它如何使用资源。
由于您已切换到lighttpd，因此网络服务器本身将使用比apache更少的资源，但Apache很少成为瓶颈，除非您耗尽了内存或严重配置错误。
您是否尝试过使用
ab实际测试您的应用程序？加载它，看看会发生什么。You really need to tell us more about your application. What breaks depends entirely on how it uses resources.
Since you've switched to lighttpd, the webserver itself is going to use fewer resources than apache would, but Apache is rarely the bottleneck unless you've run out of ram or seriously misconfigured it.
Have you tried actually testing your application using
ab? Load it up and see what happens.