Keep provider connections alive: TLS handshake costs 4.2s and is paid twice per dictation

未关闭
  • 哪里不对？
#998 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
45/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
冷清
技术栈
rust
领域
networking, performance

调研方向

No files are named; start by finding where the provider HTTP client is built for each transcription/polishing request and for the LLM channel-health check (likely a client constructed per call). Confirm connections are torn down after each dictation. Done means a pooled client with a multi-minute idle timeout, a warm-up at startup and on provider/model change, and a configurable request timeout — the issue's 4.2s cold vs 0.18s warm timings are the acceptance signal.

由索引模型根据 Issue 内容生成。

描述

Summary

On networks where the TLS handshake to the provider is slow, every dictation pays the handshake
cost twice — once for transcription and once for LLM polishing — because connections are not
kept alive between dictations. On this machine that is the single largest latency term.

Measurements (Windows 11, OpenLess 1.3.18, BYOK OpenAI)

Two requests in a row, the second reusing the connection:

request 1: tcp connect 0.125s | TLS handshake 4.194s | total 4.410s
request 2: tcp connect 0.000s | TLS handshake 0.000s | total 0.183s

The TLS handshake alone costs ~4.2 s; a reused connection answers in 0.18 s, 24x faster.

Supporting numbers:

  • DNS resolution is fine: 259-369 ms, same as any other host. Not the bottleneck.
  • TCP connect is fine: 0.125 s.
  • chatgpt.com behaves identically (~4.1 s on first hit). The ChatGPT website feels instant only
    because the browser keeps one connection open for the whole session.
  • Upload is not the bottleneck: 300 KB takes 2.3 s warm vs 5.4 s cold. The delta is the handshake.

This looks like SNI-based traffic inspection on the ISP side. It is outside the control of the app,
but the app decides how often that cost is paid.

What it looks like in the app

Avg per segment on this machine showed 9.5 s; individual dictations 3.1-5.7 s. The channel
health check for the LLM provider reported 5292 ms. Local ASR was tried as well (Foundry Local and
sherpa-onnx, several Whisper sizes), but with a cloud provider the handshake cost is paid on every
dictation and dominates everything else.

Requests
  1. Keep provider connections alive between dictations — a connection pool with a multi-minute
    idle timeout instead of closing after each request.
  2. Warm up the connection when the app starts, and after the provider or model is changed,
    so the handshake is paid once per session instead of before each dictation.
  3. If a request timeout exists, make it configurable. With a 4 s handshake plus a long
    recording, a fixed short limit produces confusing timeout errors.
Why this is worth doing

For users behind traffic inspection this term is larger than model choice or prompt size.
Two connection settings would cut several seconds off every dictation without changing any
product behaviour.

Related: #994 (plain-text insertion mode).

主要语言
Rust
星标
3.7k
派生
349
平均合并
2 天 14 小时
30 天内合并 PR
97

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

Open-Less/openless 的其他 Issue

查看 Open-Less/openless 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。