我如何去寻找一个缓慢的基于Web的聊天应用程序的瓶颈

我正在制作一个一对一的聊天应用程序。 它使用StropheJS通过BOSH连接到Ejabberd服务器（使用ejabberd的默认连接pipe理器）。 我们面临的主要问题是，有时消息需要很长时间才能到达另一端（约30秒左右），否则很快就会到达另一端。 像这样的东西 –

用户A发送消息
用户B立即收到
—- [更多即时消息交换] —–
用户A发送消息
B没有收到消息
用户A发送另一个消息
B仍然没有收到消息
…
…
（20-30秒之后）B一起接收两个消息（不是作为单个消息，而是在它们之间没有任何明显的时间间隔）

除了聊天之外，Web应用程序的其他部分还可以正常工作。

我很难弄清楚什么是确切的瓶颈。 它运行在Ubuntu 10.04实例上（2 GB内存+ 4 GB交换）。

• LAMP – > Apache处理器的CPU使用率过高
• 一个更慢/更大的VS两个更快/更小的RAM
• rmem_max超过rmem_default
• Linux：SSD性能调整队列
• 增加nginx活动连接超过65535

我应该提到的一件事情是，一台机器用于托pipe所有的东西 – apache2，mysql，ejabberd，rabbitmq，mongodb，消息队列工作者以及由apache2使用mod_wsgi服务的python web应用程序。 此外，apache还提供一些（很less）静态文件，并将BOSH请求代理到ejabberd。 在任何时候，Apache的最大进程数（大约40），并使用700-800 MB的内存，所以我的猜测是，它正在做的大部分工作。 每天平均提供20万个请求（这个数字是从访问日志中获得的）

我们已经移动了CDN提供的静态文件（它显着提高了性能），并且还logging了缓慢的查询，并通过创build索引进行了优化，这些索引再次导致整体性能提升，尽pipe我打算明天再次做这个练习。

是否有系统的方法来解决瓶颈问题？

我也很困惑，

• 是否切换到nginx会提高性能
• 无论是把东西搬到自己的服务器上，他们可能会在单机上竞争资源？
• 升级机器上的内存
• 负载平衡的http服务器（虽然我有点怀疑，因为New Relic显示在请求排队几乎可以忽略不计的时间。）
• 可以在前端/后端上做什么样的测量来获得想法？

PS：为了理解服务器pipe理/体系结构/调优的基础知识，在书中提供一些build议也是非常好的。