在部署Node.js Web应用程序时，最重要的统计数据是什么？
首先 – 关于我的背景一点点：我已经编程了一段时间（在这一点上是10年），而且在编写想法时，我相当有能力。 一年前，我开始从事networking应用程序的编程工作，并且幸运地发现了nodeJS，这使得networking应用程序的创build更像传统编程。 现在，我有一个node.js应用程序，我已经开发了一段时间，现在正在运行在网上生产。 我的主要困惑源于这样一个事实，即我对networking开发的世界很陌生，并且不知道在监视我的应用程序时什么是重要的，什么是不重要的。
我正在使用Joyent SmartMachine，查看他们提供的分析选项有点压倒性。 有很多不同的选项和configuration，我不知道每个分析的目的是什么。 对于下面的问题，我会很感激任何答案，无论是Joyent的云分析还是全面的一般。
问题一
现在，我主要关心的是弄清楚我的应用程序如何利用运行的服务器。 我想知道我的应用程序是否有足够的资源分配给它。 它收到的请求的数量是否使服务器过度杀伤，还是需要额外的资源？ 什么分析是非常重要的，以便为此目的查看NodeJS应用程序？ （如果这种做法有所不同，则可以在不同的服务器上同时使用MongoDB和Redis）
问题二
在pipe理正在生产的服务器时，还有哪些其他统计数据通常非常重要？ 我习惯于运行一次程序来执行一些特定的事情（例如，一旦它计算出图像，就结束运行的光线跟踪器），而不是连续运行并与许多客户端交互的networking应用程序。 我敢肯定有很多事情对于长期服务器pipe理员来说是显而易见的，而不是像我这样的新手。
问题三
在处理NodeJS时要特别注意什么？ 当处理NodeJS的单线程事件循环与更标准的服务器系统时，什么是统计/分析变得特别重要？
我还有其他关于数据库如何进入等式的问题，但我认为现在已经足够了…
我们一直在生产node.js，从0.4开始，现在是0.8系列。 Web应用程序是基于mongo，redis和memcached的expression式2和3。
几个事实。
- 节点不能处理大的v8堆，当它增长超过200MB，你会看到增加的CPU使用率
- 节点似乎总是泄漏内存，或者至less在没有实际使用的情况下堆大。 我怀疑内存碎片，因为V8分析或valgrind显示在js空间没有泄漏或驻留堆。 在这方面0.8早就糟糕了，rss可能是1GB，50MB堆。
- 挂起的请求很难跟踪。 我们编写了我们的中间件来监视这些，尤其是我们的应用程序是基于长轮询的
我的build议。
- 每台机器使用多个实例，每个CPU至less1个。 与haproxy，nginx或会话亲和力等平衡
- 写midleware报告挂起的连接，即代码从未回应或延迟超过门槛
- 经常重启实例，至less每周一次
- 写轮询器打印出内存统计与处理模块每分钟
- 使用supervisord和织物进行简单的stream程pipe理
监控cpu，报告内存统计信息并重新启动
无论是哪种types的Web应用程序，NodeJS或其他，加载testing都会回答您的应用程序是否具有适量的服务器资源。 我最近发现的一个很好的网站是Load Impact 。
真正要回答的问题是随着并发用户数量的增加，加载时间是否开始增加？ 当达到一定数量的并发用户时，达到了一个临界点，之后服务器性能开始下降。 因此，根据您预计在不久的将来有多less用户访问您的网站进行加载testing。
你如何估计你所期望的用户数量？
在您的网页上安装Google Analytics或其他分析软件包是必须的 ！ 通过这种方式，您将能够查看每日访问您的网站的用户数量，以及每月访问量的增长情况，这有助于预测未来的预期访问，从而预测服务器上的预期负载。
即使我知道用户的数量，我怎么估计实际的负载？
所有浏览器都提供了F12开发工具。 在任何浏览器中打开你的网站，并按下F12（或Ctrl + Shift + I），这应该打开浏览器的开发工具。 在Firefox上，确保你已经安装了Firebug，在Chrome浏览器和Internet Explorer上，它应该可以开箱即用。 转到“ networking”或“ networking”选项卡，然后刷新页面。 这将显示HTTP请求的数量，每页加载的带宽使用情况！
所以计算每日服务器负载的公式很简单：
每页加载的HTTP请求数量X每个用户每天加载的平均页面数量X期望的并发用户数量=每天向服务器发送的HTTP请求总数
和…
每页传输的MB数量X每个用户每天负载的平均页面数量X期望的并发用户数量=每天所需的总带宽
我总是发现每天计算这些数字比较容易，然后将其推算为数周和数月。
Node.js是单线程的，所以你肯定应该为你机器的每个CPU启动一个进程。 集群是迄今为止最好的方式，而且还能够重新启动死亡的工人和发现没有反应的工人。
你也想做负载testing，直到你的请求开始超时或超出你认为合理的响应时间。 这会给你一个关于你的服务器可以处理的上限的好主意。 闪电是众多选项之一。
我从来没有使用Joyent的统计信息，但是NodeFly和它们的node-nodefly-gcinfo是监控节点进程的好工具。