这是一创建于 2291 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，向各位前辈咨询一下
41 条回复 2019-07-10 10:00:18 +08:00
 | 1 dongrenwen 2019-07-09 16:07:55 +08:00 可以用钱解决，顶级的服务器和网络线路，高度优化的代码 |
 | 2 shawndev 2019-07-09 16:10:40 +08:00  1 localhost |
 | 3 dobelee 2019-07-09 16:11:08 +08:00 via Android 网络质量 服务器性能 业务逻辑 框架复杂度 依赖外部资源的服务质量 一个一个解决。 |
 | 4 guokeke 2019-07-09 16:11:30 +08:00 11 设置 timeout=1ms 毫秒级超时响应。 |
 | 5 learningman 2019-07-09 16:11:54 +08:00 用低级语言写，比如用汇编写 qwq |
 | 6 ys1992 2019-07-09 16:14:59 +08:00 via Android 别想了，除非接口数据不经过 MySQL 这种数据库，不然数据量大一点光 SQL 查询就得几十上百毫秒了 |
 | 7 liuzhedash 2019-07-09 16:16:59 +08:00 1 公网上个位数毫秒不太可能。几个优化建议： 1、dns 查询的时间是不稳定的，有时候至可能根本查不到，所以一定要做 dns 预解析 2、任何系统部署在 ssd 上都会有直接的性能提升 剩下就是网络、代码逻辑、数据库层面的优化了，这个没什么通用方案。 |
 | 8 silencefent 2019-07-09 16:17:17 +08:00 1 hello word |
 | 9 lzxz1234 2019-07-09 16:21:24 +08:00 分场景，如果是查询接口，数据异步扔缓存，接口只查缓存，毫秒级压力不大 |
 | 10 xiaopengzi 2019-07-09 16:26:16 +08:00 楼上老哥 设置 1ms 超时响应确实是个好主意。。100%空手接白 ~额不对 100%毫秒级响应 --- 响应时间越低，需要付出得人力和资源成本增长越陡 |
 | 11 azh7138m 2019-07-09 16:26:33 +08:00 |
 | 12 knightgao2 2019-07-09 16:35:52 +08:00 做缓存 |
 | 13 yulitian888 2019-07-09 16:36:09 +08:00 2 什么用途 /性质 /功能的 API ？ 一个请求的毫秒级响应还是并发请求的毫秒级响应？ 嘛都不说，没头没脑的问题，没法答 影响程序相应的最大瓶颈一般都是 IO。一般而言 IO 速度最慢的顺序是：网络>HDD>SSD>RAM>寄存器，自己分析哪块是你的 API 瓶颈，再具体想办法优化就是了。 不过我也见过有些啼笑皆非的负优化。 某人企图用 Redis 提升查询性能，但是把 Redis 部署在局域网另一台机器上。好巧不巧的是，路由器上被人插了一个百兆设备（路由器自适应降速到百兆了），然后在这个“百兆局域网”里的 Redis 不光没能提速，反而降速了。 |
 | 14 rb6221 2019-07-09 16:40:53 +08:00 2 那位大人呢，还没来吗 |
 | 15 lihongjie0209 2019-07-09 16:45:02 +08:00 1. 把数据库打包发送给客户 2. 把数据库的数据都加载到内存 3. 起一个本地服务器 4. 访问接口 |
 | 16 Tomorrowxxy 2019-07-09 16:58:38 +08:00 花钱 |
| 17 Tomorrowxxy 2019-07-09 16:58:46 +08:00 花大钱 |
 | 18 Windelight 2019-07-09 17:05:34 +08:00 via Android 1 一，网络延迟，加钱整买网、买 DNS 解决 二，硬件反应，加钱买服务器、买 SSD、买交换机解决 三，软件逻辑，加钱买程序员、少查询、多缓存解决 |
 | 19 starsriver 2019-07-09 17:08:04 +08:00 via Android 毫秒是不可能的，延迟主要发生在网络上面。就算计算机一毫秒处理完了数据，但是传输是个问题：等待、接收报文、应答都需要时间。 目前能够实现低延迟的只有硬件级别的 api,比如 gpu 和 fpga。 |
| 20 starsriver 2019-07-09 17:09:32 +08:00 via Android 接上 fpga 的延迟是皮秒级别的。 |
 | 21 pifuant 2019-07-09 17:11:03 +08:00 我去问下我同事， 他号称他前公司的接口效应时间为 0.1 毫秒级 |
 | 23 arrow8899 2019-07-09 17:17:54 +08:00 1 只要经过公网，基本上不可能，这个是物理定律决定的，1ms * 光速 = 300km，随便跨个城就不行了。 |
 | 24 undefinedList 2019-07-09 18:24:01 +08:00 排除代码问题，同意楼上的问题：世界加钱可及！ |
 | 25 x86 2019-07-09 18:24:58 +08:00 via iPhone 最好的优化就是钱 |
 | 26 janxin 2019-07-09 18:33:12 +08:00 先说一下几百毫秒算不算呗 |
 | 27 npe 2019-07-09 18:37:06 +08:00 via Android e.g. 清除缓存 alert （清除成功） |
 | 29 m9rco 2019-07-09 18:38:52 +08:00 哈哈哈哈哈 笑死 |
 | 30 pinews 2019-07-09 18:41:49 +08:00 大客户，花钱 |
 | 31 imycc 2019-07-09 18:48:17 +08:00 via iPhone 内部服务，走自建的内网，优化好，业务不复杂的情况，请求耗时在 1s 内是可以的。 普通用户访问的话，分业务本身的耗时跟 IO 的耗时去优化吧，你场景都不说清楚，是要我们自由发挥吗 |
 | 32 tomczhen 2019-07-09 18:52:43 +08:00 AI+大数据，在客户端发出请求之前就先返回不就可以把响应变成毫秒级了么 :doge: |
 | 33 xhinliang 2019-07-09 18:52:54 +08:00 秒杀接口，10ms 内响应没有问题（只有 Redis 访问）。 但到客户端那边可能就需要多些时间了，毕竟网络延时也是十位数毫秒级的。 |
 | 34 way2create 2019-07-09 18:53:05 +08:00 10000ms 就不是 ms 了吗 |
 | 35 blless 2019-07-09 18:56:01 +08:00 via Android https 握手就得几百 ms 了… |
 | 36 salmon5 2019-07-09 20:53:12 +08:00 返回“毫秒级” |
 | 37 lqzhgood 2019-07-09 20:55:36 +08:00 via Android 显示器响应时间不都要几 ms~十几 ms 么 |
 | 38 kizunaai 2019-07-10 02:06:58 +08:00 via iPhone 如果 1ms 以内的话，就别能走网线光纤了，短波欢迎你。 如果 10ms 以内的话根据客户端定制线路，（极端例子把服务器放到客户的局域网里）这个只要花钱就行。 如果 20ms 左右的话只要给机房塞够钱（多地机房多线路），客户端做好线路选择就行。 |
 | 39 xiaobai987 2019-07-10 08:41:34 +08:00 @yulitian888 这个百兆路由和响应速度没什么关系吧 难道说换成千兆就有质的飞跃吗 关键看响应速度 不能看带宽吧 |
| 40 yulitian888 2019-07-10 08:51:11 +08:00 @xiaobai987 百兆的效果属于肉眼可见差异水平，千兆就属于肉眼不可见了 |
Select Language