100毫秒其实指的是DSP给ADX的响应时间（大多ADX的要求其实是80毫秒），并不包含客户端（浏览器、移动端等）到ADX的时间。如果DSP出价的时间超过80毫秒，就会被ADX忽略掉，DSP就无法参与此次竞价。如果DSP与ADX的机房不在同一个地区的话，通常会有30毫秒的网络消耗，此时DSPServer的响应时间就剩50毫秒了。通常来说DSP的响应时间在10毫秒内是比较理想的。DSP系统会有很多广告主在上面投放广告活动，通常一个ADX的竞价请求到达DSP系统后，DSP系统需要处理逻辑会包含：根据活动排期过滤活动。根据广告位属性过滤活动（广告位宽高、物料类型、屏次、媒体、底价等等）。根据客户端信息过滤活动（浏览器、操作系统类型等）。根据地区过滤活动。根据用户看过广告的频次过滤活动。查询CookieMapping得到访客在DSP系统的唯一ID。根据访客的人群属性过滤活动、根据活动的出价选择胜出的活动。根据访客的人群属性选择需要投放的物料，其他更细致的过滤条件（注：活动指的是广告投放活动）根据接入ADX流量的多少，DSP的竞价系统每天需要处理几十亿甚至上百亿的竞价请求。像投放的活动信息这些能放到内存的都会预先加载到进程内。其他的像CookieMapping数据这些会严重依赖类似Redis这样的内存存储。例如我们用了Redis，集群当然少不了，考虑到Server端的Redis集群没有成熟方案、中间代理的方式虽然管理方便但是要牺牲一点性能，所以我们选择了在客户端实现Redis集群的方式。总之就是任何一个方面，都尽量做到最优。做DSP系统的，大内存的服务器肯定是少不了的。补充一点我们DSP的竞价系统部分目前是完全由GO语言实现的，下图是百度BES系统后台看到的我们DSP系统的响应时间：