M*e
2 楼
【 以下文字转载自 JobHunting 讨论区 】
发信人: Myfuture (未来), 信区: JobHunting
标 题: 南加某公司招Firmware engineer-- staff engr level
发信站: BBS 未名空间站 (Mon Aug 26 17:47:45 2013, 美东)
组里招人，希望能继续壮大老中队伍！
头说要求Familiar with FPGA, Micro-controller, image processing
Master degree with over 6 years experience
PHD with over 3 years experience.
有兴趣的话请站内投条。
谢谢！
发信人: Myfuture (未来), 信区: JobHunting
标 题: 南加某公司招Firmware engineer-- staff engr level
发信站: BBS 未名空间站 (Mon Aug 26 17:47:45 2013, 美东)
组里招人，希望能继续壮大老中队伍！
头说要求Familiar with FPGA, Micro-controller, image processing
Master degree with over 6 years experience
PHD with over 3 years experience.
有兴趣的话请站内投条。
谢谢！
g*u
3 楼
昨天已经把机器找出来了，还没装系统。到时候用来测老魏的服务器。
有同学愿意一起折腾吗？
我好无聊。
有同学愿意一起折腾吗？
我好无聊。
b*6
4 楼
我情况和你一样（我也是牡丹江的）。北京可以。我在北京签过好几次H1b，都没问题
。
。
l*u
5 楼
难道不是BRCM？
【在 M******e 的大作中提到】
: 【 以下文字转载自 JobHunting 讨论区 】
: 发信人: Myfuture (未来), 信区: JobHunting
: 标 题: 南加某公司招Firmware engineer-- staff engr level
: 发信站: BBS 未名空间站 (Mon Aug 26 17:47:45 2013, 美东)
: 组里招人，希望能继续壮大老中队伍！
: 头说要求Familiar with FPGA, Micro-controller, image processing
: Master degree with over 6 years experience
: PHD with over 3 years experience.
: 有兴趣的话请站内投条。
: 谢谢！
【在 M******e 的大作中提到】
: 【 以下文字转载自 JobHunting 讨论区 】
: 发信人: Myfuture (未来), 信区: JobHunting
: 标 题: 南加某公司招Firmware engineer-- staff engr level
: 发信站: BBS 未名空间站 (Mon Aug 26 17:47:45 2013, 美东)
: 组里招人，希望能继续壮大老中队伍！
: 头说要求Familiar with FPGA, Micro-controller, image processing
: Master degree with over 6 years experience
: PHD with over 3 years experience.
: 有兴趣的话请站内投条。
: 谢谢！
t*1
6 楼
赞一个。我给你一个建议。mTCP的threading model完完全全错了。
你要是能给改对了，绝对是大成绩。当然了，这也是大工程。
你要是能给改对了，绝对是大成绩。当然了，这也是大工程。
k*o
7 楼
谢谢老乡。
l*n
8 楼
三星？
【在 M******e 的大作中提到】
: 【 以下文字转载自 JobHunting 讨论区 】
: 发信人: Myfuture (未来), 信区: JobHunting
: 标 题: 南加某公司招Firmware engineer-- staff engr level
: 发信站: BBS 未名空间站 (Mon Aug 26 17:47:45 2013, 美东)
: 组里招人，希望能继续壮大老中队伍！
: 头说要求Familiar with FPGA, Micro-controller, image processing
: Master degree with over 6 years experience
: PHD with over 3 years experience.
: 有兴趣的话请站内投条。
: 谢谢！
【在 M******e 的大作中提到】
: 【 以下文字转载自 JobHunting 讨论区 】
: 发信人: Myfuture (未来), 信区: JobHunting
: 标 题: 南加某公司招Firmware engineer-- staff engr level
: 发信站: BBS 未名空间站 (Mon Aug 26 17:47:45 2013, 美东)
: 组里招人，希望能继续壮大老中队伍！
: 头说要求Familiar with FPGA, Micro-controller, image processing
: Master degree with over 6 years experience
: PHD with over 3 years experience.
: 有兴趣的话请站内投条。
: 谢谢！
g*u
9 楼
我先跑起来再说。已有啥证据证明用户态stack将来有用吗？
我怎么觉得将来都是TCP offload啊。如果用户态stack+40G网卡的话，
CPU没有cycle可以用来干别的事情了吧？
【在 t**********1 的大作中提到】
: 赞一个。我给你一个建议。mTCP的threading model完完全全错了。
: 你要是能给改对了，绝对是大成绩。当然了，这也是大工程。
我怎么觉得将来都是TCP offload啊。如果用户态stack+40G网卡的话，
CPU没有cycle可以用来干别的事情了吧？
【在 t**********1 的大作中提到】
: 赞一个。我给你一个建议。mTCP的threading model完完全全错了。
: 你要是能给改对了，绝对是大成绩。当然了，这也是大工程。
A*A
10 楼
请问现在签证还分不分区，可以想去哪就去哪签不？
t*1
11 楼
用户态是必须的。TCP offload不矛盾，但是能做的有限。
CPU每秒能handle的IRQ少得可怜。你想处理大量packets，只能polling。
现在的网卡，好一点的都是PCI-E直接到LLC (Last Level Cache)。因此不是纯软件，
但是一定要100%用户态。
你要CPU干啥？I/O也就一个core。你有多少core?
【在 g****u 的大作中提到】
: 我先跑起来再说。已有啥证据证明用户态stack将来有用吗？
: 我怎么觉得将来都是TCP offload啊。如果用户态stack+40G网卡的话，
: CPU没有cycle可以用来干别的事情了吧？
CPU每秒能handle的IRQ少得可怜。你想处理大量packets，只能polling。
现在的网卡，好一点的都是PCI-E直接到LLC (Last Level Cache)。因此不是纯软件，
但是一定要100%用户态。
你要CPU干啥？I/O也就一个core。你有多少core?
【在 g****u 的大作中提到】
: 我先跑起来再说。已有啥证据证明用户态stack将来有用吗？
: 我怎么觉得将来都是TCP offload啊。如果用户态stack+40G网卡的话，
: CPU没有cycle可以用来干别的事情了吧？
g*u
12 楼
这个我不懂。我先玩两天再说。
【在 t**********1 的大作中提到】
: 用户态是必须的。TCP offload不矛盾，但是能做的有限。
: CPU每秒能handle的IRQ少得可怜。你想处理大量packets，只能polling。
: 现在的网卡，好一点的都是PCI-E直接到LLC (Last Level Cache)。因此不是纯软件，
: 但是一定要100%用户态。
: 你要CPU干啥？I/O也就一个core。你有多少core?
【在 t**********1 的大作中提到】
: 用户态是必须的。TCP offload不矛盾，但是能做的有限。
: CPU每秒能handle的IRQ少得可怜。你想处理大量packets，只能polling。
: 现在的网卡，好一点的都是PCI-E直接到LLC (Last Level Cache)。因此不是纯软件，
: 但是一定要100%用户态。
: 你要CPU干啥？I/O也就一个core。你有多少core?
j*a
13 楼
NAPI 2.6的kernel很早就有了，2.4.20也port了，在irq handle里都是关了中断，直接
poll包的
我还是没有领会用户态有什么逆天的优势
【在 t**********1 的大作中提到】
: 用户态是必须的。TCP offload不矛盾，但是能做的有限。
: CPU每秒能handle的IRQ少得可怜。你想处理大量packets，只能polling。
: 现在的网卡，好一点的都是PCI-E直接到LLC (Last Level Cache)。因此不是纯软件，
: 但是一定要100%用户态。
: 你要CPU干啥？I/O也就一个core。你有多少core?
poll包的
我还是没有领会用户态有什么逆天的优势
【在 t**********1 的大作中提到】
: 用户态是必须的。TCP offload不矛盾，但是能做的有限。
: CPU每秒能handle的IRQ少得可怜。你想处理大量packets，只能polling。
: 现在的网卡，好一点的都是PCI-E直接到LLC (Last Level Cache)。因此不是纯软件，
: 但是一定要100%用户态。
: 你要CPU干啥？I/O也就一个core。你有多少core?
t*1
14 楼
用户态latency最低，throughput最高。
网卡所做的就是pool packets，等用户poll就好了。
【在 j******a 的大作中提到】
: NAPI 2.6的kernel很早就有了，2.4.20也port了，在irq handle里都是关了中断，直接
: poll包的
: 我还是没有领会用户态有什么逆天的优势
网卡所做的就是pool packets，等用户poll就好了。
【在 j******a 的大作中提到】
: NAPI 2.6的kernel很早就有了，2.4.20也port了，在irq handle里都是关了中断，直接
: poll包的
: 我还是没有领会用户态有什么逆天的优势
b*s
15 楼
less copy
【在 j******a 的大作中提到】
: NAPI 2.6的kernel很早就有了，2.4.20也port了，在irq handle里都是关了中断，直接
: poll包的
: 我还是没有领会用户态有什么逆天的优势
【在 j******a 的大作中提到】
: NAPI 2.6的kernel很早就有了，2.4.20也port了，在irq handle里都是关了中断，直接
: poll包的
: 我还是没有领会用户态有什么逆天的优势
m*f
16 楼
10gbps，dpdk对64byte的包，处理能力直接到线速，大概双向28.88 million packets
per second,这个网上都查得到。同样纯linux内核协议栈只能处理到dpdk的零头，同样
双向，64 bytes的小包，印象中不到5 million packets per second。腾讯和阿里都有
dpdk现成的产品好多年
dpdk不完全是用户态这么简单，还有很多别的基于linux的技术，比如huge page，物理
页可以是2m或1g，大大减少了tlb的失败的可能性，通常标准linux的物理页只有4k
【在 j******a 的大作中提到】
: NAPI 2.6的kernel很早就有了，2.4.20也port了，在irq handle里都是关了中断，直接
: poll包的
: 我还是没有领会用户态有什么逆天的优势
per second,这个网上都查得到。同样纯linux内核协议栈只能处理到dpdk的零头，同样
双向，64 bytes的小包，印象中不到5 million packets per second。腾讯和阿里都有
dpdk现成的产品好多年
dpdk不完全是用户态这么简单，还有很多别的基于linux的技术，比如huge page，物理
页可以是2m或1g，大大减少了tlb的失败的可能性，通常标准linux的物理页只有4k
【在 j******a 的大作中提到】
: NAPI 2.6的kernel很早就有了，2.4.20也port了，在irq handle里都是关了中断，直接
: poll包的
: 我还是没有领会用户态有什么逆天的优势
T*i
17 楼
赞。我以前一直都用OpenIOnLoad。比latency DPDK没戏。throughput DPDK一点不差。
Hugepage和numa之类的优化我也玩了很多年了。
老兄貌似是搞这个方向的，有兴趣一起折腾么？
packets
【在 m*f 的大作中提到】
: 10gbps，dpdk对64byte的包，处理能力直接到线速，大概双向28.88 million packets
: per second,这个网上都查得到。同样纯linux内核协议栈只能处理到dpdk的零头，同样
: 双向，64 bytes的小包，印象中不到5 million packets per second。腾讯和阿里都有
: dpdk现成的产品好多年
: dpdk不完全是用户态这么简单，还有很多别的基于linux的技术，比如huge page，物理
: 页可以是2m或1g，大大减少了tlb的失败的可能性，通常标准linux的物理页只有4k
Hugepage和numa之类的优化我也玩了很多年了。
老兄貌似是搞这个方向的，有兴趣一起折腾么？
packets
【在 m*f 的大作中提到】
: 10gbps，dpdk对64byte的包，处理能力直接到线速，大概双向28.88 million packets
: per second,这个网上都查得到。同样纯linux内核协议栈只能处理到dpdk的零头，同样
: 双向，64 bytes的小包，印象中不到5 million packets per second。腾讯和阿里都有
: dpdk现成的产品好多年
: dpdk不完全是用户态这么简单，还有很多别的基于linux的技术，比如huge page，物理
: 页可以是2m或1g，大大减少了tlb的失败的可能性，通常标准linux的物理页只有4k
c*a
18 楼
很好奇。这方面商业产品很多。现在主要还剩下什么？
【在 T********i 的大作中提到】
: 赞。我以前一直都用OpenIOnLoad。比latency DPDK没戏。throughput DPDK一点不差。
: Hugepage和numa之类的优化我也玩了很多年了。
: 老兄貌似是搞这个方向的，有兴趣一起折腾么？
:
: packets
【在 T********i 的大作中提到】
: 赞。我以前一直都用OpenIOnLoad。比latency DPDK没戏。throughput DPDK一点不差。
: Hugepage和numa之类的优化我也玩了很多年了。
: 老兄貌似是搞这个方向的，有兴趣一起折腾么？
:
: packets
T*i
19 楼
我也是孤陋寡闻。用OnLoad轮子用惯了。
想看看其他user space的TCP stack。目前看mTCP做了大量工作，但是threading model
纯粹扯淡。
看来您是行家，能不能介绍下靠谱的商业产品？
【在 c*a 的大作中提到】
: 很好奇。这方面商业产品很多。现在主要还剩下什么？
想看看其他user space的TCP stack。目前看mTCP做了大量工作，但是threading model
纯粹扯淡。
看来您是行家，能不能介绍下靠谱的商业产品？
【在 c*a 的大作中提到】
: 很好奇。这方面商业产品很多。现在主要还剩下什么？
m*f
20 楼
我只能给魏老师提鞋了，过两个月吧，我有时间和你联系
【在 T********i 的大作中提到】
: 赞。我以前一直都用OpenIOnLoad。比latency DPDK没戏。throughput DPDK一点不差。
: Hugepage和numa之类的优化我也玩了很多年了。
: 老兄貌似是搞这个方向的，有兴趣一起折腾么？
:
: packets
【在 T********i 的大作中提到】
: 赞。我以前一直都用OpenIOnLoad。比latency DPDK没戏。throughput DPDK一点不差。
: Hugepage和numa之类的优化我也玩了很多年了。
: 老兄貌似是搞这个方向的，有兴趣一起折腾么？
:
: packets
T*i
21 楼
您过谦了。承受不起。等你消息。
【在 m*f 的大作中提到】
: 我只能给魏老师提鞋了，过两个月吧，我有时间和你联系
【在 m*f 的大作中提到】
: 我只能给魏老师提鞋了，过两个月吧，我有时间和你联系
g*u
22 楼
我看了mTCP的paper。这货的目的是要代替内核TCP。threading model和别的一系列
design decision都是按这个目的做出的。作为一个用户态的通用的TCP库，需要实现
两点：
- 库本身不能霸占着CPU不放。因为用户程序可能也要跑CPU。所以mTCP是基于event
而不是polling的。mTCP本来应该是从PSIO(event)开始做的。DPDK应该是后来加上去的。
DPDK是polling。
- 不能假设逻辑线程<=物理线程。对于有的应用，逻辑线程可能是物理线程的
好几倍，靠send/recv阻塞的时候操统调度来提高硬件利用率。我那个客户端就是
这么干的。
这个paper里提到了context-switch。这是很明显的一个indicator: paper里讲的
线程是逻辑线程。如果限制线程数绑定CPU，mTCP应该可以做成context-switch-free的。
不过得把pthread那套同步机制全都换掉才行。
关键还是通用 vs 专用的问题。如果做成专用的话，paper估计就发不出去了。
其实写paper的时候把PSIO换成DPDK，review就会出问题。
model
【在 T********i 的大作中提到】
: 我也是孤陋寡闻。用OnLoad轮子用惯了。
: 想看看其他user space的TCP stack。目前看mTCP做了大量工作，但是threading model
: 纯粹扯淡。
: 看来您是行家，能不能介绍下靠谱的商业产品？
design decision都是按这个目的做出的。作为一个用户态的通用的TCP库，需要实现
两点：
- 库本身不能霸占着CPU不放。因为用户程序可能也要跑CPU。所以mTCP是基于event
而不是polling的。mTCP本来应该是从PSIO(event)开始做的。DPDK应该是后来加上去的。
DPDK是polling。
- 不能假设逻辑线程<=物理线程。对于有的应用，逻辑线程可能是物理线程的
好几倍，靠send/recv阻塞的时候操统调度来提高硬件利用率。我那个客户端就是
这么干的。
这个paper里提到了context-switch。这是很明显的一个indicator: paper里讲的
线程是逻辑线程。如果限制线程数绑定CPU，mTCP应该可以做成context-switch-free的。
不过得把pthread那套同步机制全都换掉才行。
关键还是通用 vs 专用的问题。如果做成专用的话，paper估计就发不出去了。
其实写paper的时候把PSIO换成DPDK，review就会出问题。
model
【在 T********i 的大作中提到】
: 我也是孤陋寡闻。用OnLoad轮子用惯了。
: 想看看其他user space的TCP stack。目前看mTCP做了大量工作，但是threading model
: 纯粹扯淡。
: 看来您是行家，能不能介绍下靠谱的商业产品？
n*7
23 楼
最近可能有Cavium Networks的DPDK的工作机会。按他们的说法，Intel的DPDK很多做法
还是学他们的。想请教大家这个方面是不是技术已经成熟，还有值得深入专研的地方吗？
我的理解是这方面的工作主要是在bypass kernel，用专有的CPU和一些特殊的做法充分
利用CPU硬件特性，所以需要的知识都是些特殊硬件的细节。不知道专业做这些细节工
作是不是太窄了。
还是学他们的。想请教大家这个方面是不是技术已经成熟，还有值得深入专研的地方吗？
我的理解是这方面的工作主要是在bypass kernel，用专有的CPU和一些特殊的做法充分
利用CPU硬件特性，所以需要的知识都是些特殊硬件的细节。不知道专业做这些细节工
作是不是太窄了。
w*g
24 楼
你要看成是专搞DPDK的话确实比较窄。
你要看成是是用C语言写系统程序，只是要用到DPDK轮子的话，感觉就会好一点。
如果不是写网卡驱动只是用DPDK，其实没有多少特殊的细节。
DPDK用到的几个技术都可以用来优化别的软件。
现在搞系统的人还是很多的，只是本版bias太大，这里看不到而已。
吗？
【在 n*******7 的大作中提到】
: 最近可能有Cavium Networks的DPDK的工作机会。按他们的说法，Intel的DPDK很多做法
: 还是学他们的。想请教大家这个方面是不是技术已经成熟，还有值得深入专研的地方吗？
: 我的理解是这方面的工作主要是在bypass kernel，用专有的CPU和一些特殊的做法充分
: 利用CPU硬件特性，所以需要的知识都是些特殊硬件的细节。不知道专业做这些细节工
: 作是不是太窄了。
你要看成是是用C语言写系统程序，只是要用到DPDK轮子的话，感觉就会好一点。
如果不是写网卡驱动只是用DPDK，其实没有多少特殊的细节。
DPDK用到的几个技术都可以用来优化别的软件。
现在搞系统的人还是很多的，只是本版bias太大，这里看不到而已。
吗？
【在 n*******7 的大作中提到】
: 最近可能有Cavium Networks的DPDK的工作机会。按他们的说法，Intel的DPDK很多做法
: 还是学他们的。想请教大家这个方面是不是技术已经成熟，还有值得深入专研的地方吗？
: 我的理解是这方面的工作主要是在bypass kernel，用专有的CPU和一些特殊的做法充分
: 利用CPU硬件特性，所以需要的知识都是些特殊硬件的细节。不知道专业做这些细节工
: 作是不是太窄了。
n*7
25 楼
多榭wdong！
用DPDK做各种应用不窄。做DPDK的内部工作可能还是较窄的。
用C语言写系统程序，听起来很普适。但具体做起来，大多数是用具体硬件环境的
proprietary知识，而不用常见的轮子，所以虽然系统性能指标做高了，但在简历上看
起来较偏，反而比不上用轮子的适用面广。
【在 w***g 的大作中提到】
: 你要看成是专搞DPDK的话确实比较窄。
: 你要看成是是用C语言写系统程序，只是要用到DPDK轮子的话，感觉就会好一点。
: 如果不是写网卡驱动只是用DPDK，其实没有多少特殊的细节。
: DPDK用到的几个技术都可以用来优化别的软件。
: 现在搞系统的人还是很多的，只是本版bias太大，这里看不到而已。
:
: 吗？
用DPDK做各种应用不窄。做DPDK的内部工作可能还是较窄的。
用C语言写系统程序，听起来很普适。但具体做起来，大多数是用具体硬件环境的
proprietary知识，而不用常见的轮子，所以虽然系统性能指标做高了，但在简历上看
起来较偏，反而比不上用轮子的适用面广。
【在 w***g 的大作中提到】
: 你要看成是专搞DPDK的话确实比较窄。
: 你要看成是是用C语言写系统程序，只是要用到DPDK轮子的话，感觉就会好一点。
: 如果不是写网卡驱动只是用DPDK，其实没有多少特殊的细节。
: DPDK用到的几个技术都可以用来优化别的软件。
: 现在搞系统的人还是很多的，只是本版bias太大，这里看不到而已。
:
: 吗？
b*s
26 楼
现在这个经济趋势，互联网泡沫离破也快了，到时会平衡一点
【在 w***g 的大作中提到】
: 你要看成是专搞DPDK的话确实比较窄。
: 你要看成是是用C语言写系统程序，只是要用到DPDK轮子的话，感觉就会好一点。
: 如果不是写网卡驱动只是用DPDK，其实没有多少特殊的细节。
: DPDK用到的几个技术都可以用来优化别的软件。
: 现在搞系统的人还是很多的，只是本版bias太大，这里看不到而已。
:
: 吗？
【在 w***g 的大作中提到】
: 你要看成是专搞DPDK的话确实比较窄。
: 你要看成是是用C语言写系统程序，只是要用到DPDK轮子的话，感觉就会好一点。
: 如果不是写网卡驱动只是用DPDK，其实没有多少特殊的细节。
: DPDK用到的几个技术都可以用来优化别的软件。
: 现在搞系统的人还是很多的，只是本版bias太大，这里看不到而已。
:
: 吗？
N*m
27 楼
scylladb有dpdk的driver，有点意思
【在 w***g 的大作中提到】
: 你要看成是专搞DPDK的话确实比较窄。
: 你要看成是是用C语言写系统程序，只是要用到DPDK轮子的话，感觉就会好一点。
: 如果不是写网卡驱动只是用DPDK，其实没有多少特殊的细节。
: DPDK用到的几个技术都可以用来优化别的软件。
: 现在搞系统的人还是很多的，只是本版bias太大，这里看不到而已。
:
: 吗？
【在 w***g 的大作中提到】
: 你要看成是专搞DPDK的话确实比较窄。
: 你要看成是是用C语言写系统程序，只是要用到DPDK轮子的话，感觉就会好一点。
: 如果不是写网卡驱动只是用DPDK，其实没有多少特殊的细节。
: DPDK用到的几个技术都可以用来优化别的软件。
: 现在搞系统的人还是很多的，只是本版bias太大，这里看不到而已。
:
: 吗？
n*t
28 楼
latency呢？我觉得要追求pps这种东西可以做聚合就行，为什么要poll cpu啊？
总之我觉得dpdk是intel的思维方式，不太感冒。
packets
【在 m*f 的大作中提到】
: 10gbps，dpdk对64byte的包，处理能力直接到线速，大概双向28.88 million packets
: per second,这个网上都查得到。同样纯linux内核协议栈只能处理到dpdk的零头，同样
: 双向，64 bytes的小包，印象中不到5 million packets per second。腾讯和阿里都有
: dpdk现成的产品好多年
: dpdk不完全是用户态这么简单，还有很多别的基于linux的技术，比如huge page，物理
: 页可以是2m或1g，大大减少了tlb的失败的可能性，通常标准linux的物理页只有4k
总之我觉得dpdk是intel的思维方式，不太感冒。
packets
【在 m*f 的大作中提到】
: 10gbps，dpdk对64byte的包，处理能力直接到线速，大概双向28.88 million packets
: per second,这个网上都查得到。同样纯linux内核协议栈只能处理到dpdk的零头，同样
: 双向，64 bytes的小包，印象中不到5 million packets per second。腾讯和阿里都有
: dpdk现成的产品好多年
: dpdk不完全是用户态这么简单，还有很多别的基于linux的技术，比如huge page，物理
: 页可以是2m或1g，大大减少了tlb的失败的可能性，通常标准linux的物理页只有4k
相关阅读
最近两天打开快手观看java 就是一堆轮子， 太累赘， 让系统崩溃 (转载)是不是有的年轻朋友不知道捡瓶子的典故？芯片應該為軟件服務，譬如硬件加速的虛擬內存MMU、虛擬GPU、虛Golang 国内用的很多tensorflow.js關於JVM多線程的內存分配Restful API 怎么设计？golang為什麼語法和關鍵詞這麼冷門？众所周知，快手摊上大事了霉地最近5年左右， 50%-80%的人都转成码农了 (转载)[bssd] I will keep talking in Mastodoneval (expr, envir=, enclose=) 求解答技术純好奇，EECS最近50年哪個重要成果來自於學術界？uber车祸主要是sensor fusion的问题Fuck Oracle无人车怎么处理高密度人群场景请教怎么做End to End Performance Testfalloutboy ...