首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  程序员

api 接口如何做到毫秒级响应?

  •  
  •   shuAS · 96 天前 · 4424 次点击
    这是一个创建于 96 天前的主题,其中的信息可能已经有所发展或是发生改变。

    如题,向各位前辈咨询一下

    41 回复  |  直到 2019-07-10 10:00:18 +08:00
        1
    dongrenwen   96 天前
    可以用钱解决,顶级的服务器和网络线路,高度优化的代码
        2
    shawndev   96 天前   ♥ 1
    localhost
        3
    dobelee   96 天前 via Android
    网络质量
    服务器性能
    业务逻辑
    框架复杂度
    依赖外部资源的服务质量
    一个一个解决。
        4
    guokeke   96 天前   ♥ 11
    设置 timeout=1ms 毫秒级超时响应。
        5
    learningman   96 天前
    用低级语言写,比如用汇编写 qwq
        6
    ys1992   96 天前 via Android
    别想了,除非接口数据不经过 MySQL 这种数据库,不然数据量大一点光 SQL 查询就得几十上百毫秒了
        7
    liuzhedash   96 天前
    公网上个位数毫秒不太可能。几个优化建议:
    1、dns 查询的时间是不稳定的,有时候甚至可能根本查不到,所以一定要做 dns 预解析
    2、任何系统部署在 ssd 上都会有直接的性能提升
    剩下就是网络、代码逻辑、数据库层面的优化了,这个没什么通用方案。
        8
    silencefent   96 天前   ♥ 1
    hello word
        9
    lzxz1234   96 天前
    分场景,如果是查询接口,数据异步扔缓存,接口只查缓存,毫秒级压力不大
        10
    xiaopengzi   96 天前
    楼上老哥 设置 1ms 超时响应确实是个好主意。。100%空手接白 ~额不对 100%毫秒级响应
    ---
    响应时间越低,需要付出得人力和资源成本增长越陡
        11
    azh7138m   96 天前
    @liuzhedash 每个市一个机房勉强可以个位数毫秒,这就要求钱加足了(
    不过楼主应该指 1s 以内的意思吧
    不过没有场景也没有 mvp 也没有数据量
    这种就叫开放式吹*吧
        12
    knightgao2   96 天前
    做缓存
        13
    yulitian888   96 天前   ♥ 2
    什么用途 /性质 /功能的 API ?
    一个请求的毫秒级响应还是并发请求的毫秒级响应?
    嘛都不说,没头没脑的问题,没法答
    影响程序相应的最大瓶颈一般都是 IO。一般而言 IO 速度最慢的顺序是:网络>HDD>SSD>RAM>寄存器,自己分析哪块是你的 API 瓶颈,再具体想办法优化就是了。

    不过我也见过有些啼笑皆非的负优化。
    某人企图用 Redis 提升查询性能,但是把 Redis 部署在局域网另一台机器上。好巧不巧的是,路由器上被人插了一个百兆设备(路由器自适应降速到百兆了),然后在这个“百兆局域网”里的 Redis 不光没能提速,反而降速了。
        14
    janus77   96 天前   ♥ 2
    那位大人呢,还没来吗
        15
    lihongjie0209   96 天前
    1. 把数据库打包发送给客户
    2. 把数据库的数据都加载到内存
    3. 起一个本地服务器
    4. 访问接口
        16
    Tomorrowxxy   96 天前
    花钱
        17
    Tomorrowxxy   96 天前
    花大钱
        18
    Windelight   96 天前 via Android   ♥ 1
    一,网络延迟,加钱整买网、买 DNS 解决
    二,硬件反应,加钱买服务器、买 SSD、买交换机解决
    三,软件逻辑,加钱买程序员、少查询、多缓存解决
        19
    starsriver   96 天前 via Android
    毫秒是不可能的,延迟主要发生在网络上面。就算计算机一毫秒处理完了数据,但是传输是个问题:等待、接收报文、应答都需要时间。

    目前能够实现低延迟的只有硬件级别的 api,比如 gpu 和 fpga。
        20
    starsriver   96 天前 via Android
    接上 fpga 的延迟是皮秒级别的。
        21
    pifuant   96 天前
    我去问下我同事, 他号称他前公司的接口效应时间为 0.1 毫秒级
        22
    maichael   96 天前
    @ys1992 #6 只要不超过秒就算毫秒级吧,几百毫秒也算毫秒吧。
        23
    arrow8899   96 天前   ♥ 1
    只要经过公网,基本上不可能,这个是物理定律决定的,1ms * 光速 = 300km,随便跨个城就不行了。
        24
    undefinedList   96 天前
    排除代码问题,同意楼上的问题:世界加钱可及!
        25
    x86   96 天前 via iPhone
    最好的优化就是钱
        26
    janxin   96 天前
    先说一下几百毫秒算不算呗
        27
    npe   96 天前 via Android
    e.g. 清除缓存
    alert (清除成功)
        28
    wenzhoou   96 天前 via Android
    @janus77 笑死了
        29
    m9rco   96 天前
    哈哈哈哈哈 笑死
        30
    pinews   96 天前
    大客户,花钱
        31
    imycc   96 天前 via iPhone
    内部服务,走自建的内网,优化好,业务不复杂的情况,请求耗时在 1s 内是可以的。

    普通用户访问的话,分业务本身的耗时跟 IO 的耗时去优化吧,你场景都不说清楚,是要我们自由发挥吗
        32
    tomczhen   96 天前
    AI+大数据,在客户端发出请求之前就先返回不就可以把响应变成毫秒级了么 :doge:
        33
    xhinliang   96 天前
    秒杀接口,10ms 内响应没有问题(只有 Redis 访问)。
    但到客户端那边可能就需要多些时间了,毕竟网络延时也是十位数毫秒级的。
        34
    way2create   96 天前
    10000ms 就不是 ms 了吗
        35
    blless   96 天前 via Android
    https 握手就得几百 ms 了…
        36
    salmon5   96 天前
    返回“毫秒级”
        37
    lqzhgood   96 天前 via Android
    显示器响应时间不都要几 ms~十几 ms 么
        38
    kizunaai   96 天前 via iPhone
    如果 1ms 以内的话,就别能走网线光纤了,短波欢迎你。
    如果 10ms 以内的话根据客户端定制线路,(极端例子把服务器放到客户的局域网里)这个只要花钱就行。
    如果 20ms 左右的话只要给机房塞够钱(多地机房多线路),客户端做好线路选择就行。
        39
    xiaobai987   95 天前
    @yulitian888 这个百兆路由和响应速度没什么关系吧 难道说换成千兆就有质的飞跃吗 关键看响应速度 不能看带宽吧
        40
    yulitian888   95 天前
    @xiaobai987 百兆的效果属于肉眼可见差异水平,千兆就属于肉眼不可见了
        41
    wuchujie   95 天前
    @guokeke 优秀啊 兄 dei
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   860 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 22ms · UTC 20:06 · PVG 04:06 · LAX 13:06 · JFK 16:06
    ♥ Do have faith in what you're doing.