node/deno postgres 客户端在 mac 上运行缓慢

Slowness of node/deno postgres client on mac

我在 mac 上使用 node-postgres 或 deno-postgres 时遇到了异常缓慢的问题。我有一个非常简单的 table,有两列,当我执行查询 select * from table 时,它发生得非常非常慢。我也尝试过 select 直接使用 SQL 客户端,速度非常快。

准确地说 - table 有 60 个条目。两列。在远程 postgres 服务器 (12.2)

我有以下三个脚本。

#node v13.12.0

const { Client } = require('pg')

const client = new Client({
  user: 'u',
  host: 'address',
  database: 'db',
  password: 'pw',
  port: 5432,
})

client.connect()

const start = Date.now();

client.query('SELECT * from unit', (err, res) => {
  const ms = Date.now() - start;
  console.log(`db call ${ms}`);
  
  console.log(res.rows.length);
  
  client.end()
})

#deno 1.1.2
#v8 8.5.216
#typescript 3.9.2

import { Client } from "https://deno.land/x/postgres@v0.4.2/mod.ts";

const client = new Client({
  user: "u",
  database: "db",
  hostname: "addr",
  password: "pw",
  port: 5432,
});

await client.connect();

const start = Date.now();

const dataset = await client.query("SELECT * FROM unit");
const ms = Date.now() - start;
console.log(`db call ${ms}`);
console.log(dataset.rowsOfObjects().length)


#python 3.7.7

import psycopg2
from datetime import datetime
#try:
connection = psycopg2.connect(user = "u",
                                password = "p",
                                host = "addr",
                                port = "5432",
                                database = "db")

cursor = connection.cursor()
a = datetime.now()
cursor.execute("select * from unit");
records = cursor.fetchall()    
b = datetime.now()
c = b - a 

print(len(records))
print(c.total_seconds() * 1000)

当我在 macos (10.15.5) 上执行所有三个脚本时,我得到以下结果:

"select * 来自单位"(60 条记录)

node   ~16'000ms
deno   ~16'000ms 
python    ~240ms

当我执行“select * from unit limit 5”时

node      ~480ms
deno      ~110ms
python    ~220ms

当我在安装了 postgres 的同一个 ubuntu 服务器上执行“select * from unit”时,所有 3 个脚本都在大约 10 毫秒内执行。

我在postgres服务器中启用了计时和全量日志记录,我看到我可以看到在所有中的查询都执行了上述情况低于一毫秒,大约 ~0.600 毫秒

此时,我感觉故障出在node/deno和我的macos的交集处,可能是v8。或者 deno 和 node 共享的其他东西。

那么,它会是什么?

p.s 我也试过节点分析器,我看到了这个:

[Summary]:
   ticks  total  nonlib   name
      0    0.0%    0.0%  JavaScript
    116   84.7%   99.1%  C++
     22   16.1%   18.8%  GC
     20   14.6%          Shared libraries
      1    0.7%          Unaccounted

 [C++ entry points]:
   ticks    cpp   total   name
     45   54.9%   32.8%  T __ZN2v88internal32Builtin_DatePrototypeSetUTCHoursEiPmPNS0_7IsolateE
     36   43.9%   26.3%  T __ZN2v88internal21Builtin_HandleApiCallEiPmPNS0_7IsolateE
      1    1.2%    0.7%  T __ZN2v88internal23Builtin_DateConstructorEiPmPNS0_7IsolateE

但我不知道那是什么意思。

好的,我终于明白了。

因为没有任何效果,我决定将我的 API 移动到远程服务器而不是本地 运行,启动它,很高兴看到 API 之间的即时通信和数据库...只是在我机器上的前端 运行 上看到完全相同的缓慢。

这就是我突然意识到的 - 这是我的互联网提供商的某种流量整形。我打开 VPN,一切立即开始正常工作。

难怪我不明白为什么会卡住。问题出在堆栈中,这对我来说是一个教训 - 总是必须跳出计算机本身的框框思考。

这解释了为什么它有时工作正常。然而,它并没有解释为什么这个问题从未影响 python 脚本——也许它以一种稍微不同的方式与 Postgres 服务器通信,没有触发提供者的过滤器。谁知道呢