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