【问题标题】:Slowness of node/deno postgres client on macmac上node/deno postgres客户端的缓慢
【发布时间】:2020-06-29 18:44:58
【问题描述】:

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

准确地说,该表有 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) 上执行所有三个脚本时,我得到以下结果:

“从单元中选择 *”(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 和节点共享的东西。

那么,它会是什么?

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

但我不知道这可能意味着什么。

【问题讨论】:

  • 您正在尝试哪个区域以及您的数据库来自哪个区域?
  • 这不是 aws。或者你说的地区是什么?如果python脚本不受影响,您认为网络可能是问题吗?
  • 如果使用连接池会改变 Node:node-postgres.com/features/pooling 中的任何内容,你能试试吗?
  • 刚刚再次检查了所有脚本 - 看起来效果已经完全消失了。所以我猜这与我的macos环境有关,它现在已经消失了。如果问题再次出现,将检查池化。虽然不确定如果一个查询只有一个连接在使用,池化如何提供帮助。
  • 现在问题又回来了。感觉好像取决于一天中的时间:/

标签: node.js postgresql macos v8 deno


【解决方案1】:

好吧,我终于想通了。

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

这时我才恍然大悟——这是来自我的互联网提供商的某种流量整形。我打开了 VPN,一切都立即开始按预期工作。

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

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

【讨论】:

    猜你喜欢
    • 2020-05-27
    • 1970-01-01
    • 1970-01-01
    • 2012-10-31
    • 2022-08-24
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多