Node.js的应用程序都是单线程的。这就意味着即使计算机是多核或多处理器的，node.js的应用程序也只能利用其中一个，大大限制了系统性能。
随着堆栈变大，Node.js的垃圾收集器变得非常低效。随着堆栈使用空间超过1GB，垃圾收集的过程开始变得非常慢，会严重影响程序的性能。
因为以上的问题，Node.js限制了堆栈所能使用的空间为1.5GB。一旦超过该范围，系统就会出错。
为了保证Jut系统的高效性，Jut团队想出了一些解决方案。
首先，针对Node.js单线程引起的性能低下问题，Jut团队采用了尽量避免利用Node.js进行计算的方式。JPC会把Juttle流图切割为一些子图，然后在Jut平台的更深层再进行高效执行。以ElasticSearch为例，在未优化之前，数据请求的流程为：ElasticSearch把相关数据从磁盘中取出->编码为JSON->通过HTTP协议发送给JPC->JPC解码JSON文件，执行预想的计算。然而，ElasticSearch拥有一种聚合（Aggregation）功能，能够跨数据集执行计算。这样，一次大的请求就可以优化为一个ElasticSearch聚合，避免了中间多次JSON转换以及Node.js针对大规模数据进行计算的过程。而且，ElasticSearch和Cassandra都是采用Java编写，可以有效利用多核或多处理器资源，实现高效率并行计算。总之，通过尽量避免在Node.js中进行计算的方式，Jut团队有效提高了系统的性能。
其次，关于堆栈空间问题。每当用户让Node.js服务器向其他服务器发送请求时，用户都会提供一些相应的函数，来对未来返回的数据进行处理。Node.js就会把这些函数放到event loop中，等待数据返回，然后调用相应的函数进行处理。这种类似中断的处理方式，可以大大提高单线程Node.js的效率。然而，一旦event loop中其中一个函数计算的时间过长，系统就会出现问题。以用户向Node.js发送从其他服务器中请求若干行的数据，然后对这些数据进行数学计算为例。如果请求的数据超过了1.5GB堆栈大小的限制，计算过程就会占用Node.js很长一段时间，甚至无法完成。由于Node.js为单线程，在这段时间内，新的请求或者新返回的数据只能放置在event loop的待办列表中。这样，Node.js服务器的反应时间将会大大增加，影响其他请求的正常处理。
为了解决该问题，Jut在任何可能的地方实现了分页（paging）。这就意味着，系统将不会一次读取大量数据，而是将其划分为若干小的请求。在这些请求中间，系统还可以处理器新的请求。当然，多次请求都需要一定的通信代价的。经过Jut团队的摸索，20000个点是比较合适的规模——系统仍然能够在若干毫秒中执行完毕，而且一般的请求也不需要进行大量分割。
针对这些问题，Galbraith分享了一个具体的使用案例。作为Jut的忠实客户，NPM一直伴随着Jut从alpha版本一直走到了现在的beta版本。NPM一个具体的任务就是找到所有包中过去两周下载量最大的前十名，然后在网站中以表格形式的显示。Juttle程序可以利用非常简单的代码完成该任务：
read -last :2 weeks: | reduce count() by package | sort count -desc | head 10 | @table
但是，Jut第一次跑该程序的时候就遇到了问题。经过调试发现，问题的原因在于JPC优化了read和reduce操作，将其合并为一个ElasticSearch聚合操作。由于聚合操作本身并不支持分页，而NPM的包数要超过数百万个，ElasticSearch就返回了一个超过百万个数组的巨大响应结果，总大小在几百MB。收到该响应后，JPC就试图一次处理完毕，导致内存空间使用超过了1.5GB的限制。垃圾收集器开始不断尝试回收空间。结果，处理时间超过了JPC内置的监控服务认为出现异常的阈值——60s。监控服务直接重启JPC，导致了NPM的任务一直无法完成。
为了解决该问题，Jut团队采用了模仿ElasticSearch针对聚合进行分页的方法。针对返回的包含大量信息的结果，JPC将其切分为可以方便处理的小块，一个个处理。
内容全部来源于网络收集，如有侵权，请联系网站删除：QQ：24596024