用50个并发线程模拟1万在线用户的逻辑

1不管是大颗粒度（多接口事务构成一个事务型业务）还是单接口，目前系统的性能对应的tps就在那里，它是不变的

2  100的tps可以认为是100的并发数，可以用100个并发线程去压测，给几分钟的压测压力，让服务端真正能够达到每秒处理了100个并发请求；但是，更应该注意的是，并非必须用100个并发线程去压，你只要压测出最高的tps后，再根据你设定的最大响应时间，这个最大并发请求可以计算出来。比如你预计最大能接受的响应时间是4s，那么实际的并发数就是最大并发数的基础上乘以4所以如何选取压测的并发模拟线程，唯一的参考数据不断加压，加压到系统平均响应时间达到1s左右，这时候你就得到了系统最大tps了，那么真实的并发用户数是多少，再根据你定义的最大响应时间乘以这个数就行，它也可以是小于1s，也可以是大于1s

最大tps（每秒请求数）产品经理约定的最大响应时间=并发用户数

3:问题：

    1万用户，并发度5%，得到最大要求的tps是500，最大响应时间要求是01s，那么初始定义压测线程是多少？

01 rt 表示 服务器每个线程需要执行的时间，tps表示每秒要处理的线程数，那么50001表示服务端每秒能够处理的线程数为50

小结：

1单接口最大tps，可以通过一个基本的线程数/响应时间得到，并不需要一定压到1s才能知道

2预定的tps和响应时间确定的话，那么给出的预压测线程可以轻易计算 =tps响应时间

线程数就是核心数，跟人的脑子一样，核心数2就说明CPU有两个脑子。脑子越多解决问题速度越快。CPU的核心数越高处理速度就越高。核心数2通俗地说就是双核CPU了。但自超线程技术问世后，一个核心可以同时2个线程了。使CPU性能上升百分之40。

假设从服务端传送数据到用户端，把用户端和服务端比做两个小岛，线程数比做连接两个小岛之间的桥梁，架桥越多，单位时间内传送的数据越多，但如果桥梁架设超过双方所能承受的数量时，用户端将无法接受其他服务端的数据，而服务端将无法为其他用户端传送数据，因此，线程数的多少，要根据服务端和用户端的具体情况而定。

扩展资料

线程可以为操作系统内核调度的内核线程，如Win32线程；由用户进程自行调度的用户线程，如Linux平台的POSIX Thread；或者由内核与用户进程，如Windows 7的线程，进行混合调度。

同一进程中的多条线程将共享该进程中的全部系统资源，如虚拟地址空间，文件描述符和信号处理等等。但同一进程中的多个线程有各自的调用栈（call stack），自己的寄存器环境（register context），自己的线程本地存储（thread-local storage）。

一个进程可以有很多线程，每条线程并行执行不同的任务。在多核或多CPU，或支持Hyper-threading的CPU上使用多线程程序设计的好处是显而易见，即提高了程序的执行吞吐率。

在单CPU单核的计算机上，使用多线程技术，也可以把进程中负责I/O处理、人机交互而常被阻塞的部分与密集计算的部分分开来执行，编写专门的workhorse线程执行密集计算，从而提高了程序的执行效率。

-线程

-线程数

云渲染的优势包含以下几点：

比如有100个任务需要渲染，特别是影视任务会拆分很多任务进行制作，最后汇总，每个任务的渲染时间是一个小时，本地一台电脑渲染100个任务就是100个小时，10台电脑渲染就需要10个小时，使用云渲染100台服务器同时处理，只需要一个小时就可以看到成果，对于项目量庞大的来说选择云渲染是最高效的，使用云渲染不耽误本地的电脑做其它的创作，能更好的让时间花费在创作创意上面，大幅度的提升效率。

云渲染可以解放用户的本地电脑。用本地电脑渲染通常会导致设计师电脑的cpu处于满负荷状态，无法做其他事情，经常会出现卡顿、蓝屏甚至死机的情况，极大的消耗了本地电脑的寿命。如果最终完成渲染，因为需求的一点点变化，需要很长时间的修改和重新渲染。不过使用云渲染比较方便，可以随时修改。修改完后，提交到云渲染平台就可以了。本地电脑可以解放出来做其他事情或者重新修改，甚至关机，大大减少了电脑的损失。

云渲染收费标准是按照用户选择的机器配置、项目耗费的算力资源和渲染时长来收取费用，公开透明的价格机制让用户渲的放心，不管任何时候有需要，都能帮助用户在业务类型、提交方式、支持系统、支持软件、流程区别等的对比信息中，快速地选择出适合自己的产品。

一般在准备使用云渲染时，我们选择使用的云计算资源越多渲染的速度就越快，根据不同需求进行不同收费。这里有个误区，很多以为免费的云渲染有很多，其实不然，因为‘’免费‘’的才是最贵的，毕竟一个云渲染平台在搭建时的成本，就包含了云服务器资源和人工运维成本、平台技术运营成本等。按需求收费是一种很明确的方式。

3dmax进行云渲染的步骤：

在“渲云”菜单下点击“一键渲染”提交任务

选择需要渲染的相机

相机可多选

双击相机可以修改参数，如下图所示：

选择渲染模式，不同模式收费不同

选择光子比例

若使用本地光子，该设置不生效，优先调用本地光子文件，相机后的光子模式显示为光子文件名称，如截图所示：

若首次反弹模式使用BF，该设置不生效（置灰状态），相机后的光子模式显示为硬渲，如截图所示：

该步骤设置的光子比例，仅对光子模式为“先渲光子”的镜头生效

根据需求选择渲染元素

渲染元素可选色彩通道、AO通道、材质通道

AO通道支持修改半径值和细分值。其中半径值越大，线条阴影效果越重，如截图所示，AO通道效果同时受到文件单位设置影响（厘米、米、英寸等）

合成PSD通道： 将正图、渲染元素（包含勾选的色彩通道、AO通道、材质通道）等出图合成为一张PSD格式。若希望在下载时仅下载PSD文件，可在客户端渲染设置中勾选“仅推送PSD通道”，PSD文件可能较大，根据需要决定是否勾选

设置输出Gamma

若文件需要按照Gamma10输出，此处设置10。默认为22，多数情况下使用默认参数即可

若文件未开启Gamma，此处设置是置灰的状态，不可选

确认出图格式

若需更改格式，可以在文件中更改，然后重新提交

也可以点击格式后的省略号进行更改，更改的方式，与在文件中更改格式的方式相同

VFB文件

通常情况下，渲云能识别到VFB窗口中指认的外部资产文件，无需使用该功能

vray的50版本，及vray51中的vray51000版本中存在的接口错误问题，导致以上版本获取不到VFB窗口中指认的外部资产文件，如lut文件

此时需要通过该功能，人工指认资产文件，否则相应资产无法上传，影响最终渲染效果

提交渲染

插件面板的信息确认无误后，点击“提交渲染”，客户端开始分析场景中使用到的工程文件，如贴图、代理、光域网等文件，分析完成后任务开始上传

点击提交渲染等待片刻后，客户端提示提交成功

客户端可以查看提交的任务

等待渲染完成会自动回传到本地，渲染期间不占用本地的电脑做其它的工作，将更多的时间花费在创作和创意上。

1 实验目的：

使用线程池的时候，有时候需要考虑服务器的最大线程数目和程序最快执行所有业务逻辑的取舍。

并非逻辑线程越多也好，而且新的逻辑线程必须会在线程池的等待队列中等待 ，直到线程池中工作的线程执行完毕，

才会有系统线程取出等待队列中的逻辑线程，进行CPU运算。

2 解决问题：

如果不考虑服务器实际可支持的最大并行线程个数，程序不停往线程池申请新的逻辑线程，这个时候我们可以发现CPU的使用率会不断飙升，并且内存、网络带宽占用也会随着逻辑线程在CPU队列中堆积，而不断增大。

如果我们想在主程序有200个http网络通讯需要执行，如何每次循环用10个线程并发处理10个网络http通讯回话，下一次循环只有在上一次循环的10个线程都执行完毕后才会执行下一次循环，并且主程序监听和等待200个http网络通讯都在CPU线程池中执行完毕后，才会退出主程序。

3 实现逻辑：

我们通过两个AutoResetEvent和线程监听器Monitor，分别实现：

<a>wait_sync: 任务线程的 并发执行，每次循环只处理最大10个线程分别对网络做http通讯回话。并且当前循环的10个线程都执行完毕后，才会进行下一次循环处理。

<b> wait_main: 主程序线程的监听和等待，只有所有任务线程都执行完毕后，主程序线程才会退出程序。

<c> list_Thread: 负责记录每次循环，CPU实际分配的系统线程的个数。和Monitor配合使用，MonitorEnter(list_Thread)=占用共享线程资源的占用锁，MonitorExit(list_Thread)释放共享线程资源的占用锁。

码：

线程池控制代码，如下：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

/// <summary>

/// 多线程调用WCF

/// </summary>

/// <param name="select">调用WCF的方式，1=Restful，2=Tcp</param>

/// <param name="num"></param>

static void DoTest_MultiThread(string select, long num)

{

int n_max_thread = 10; // 设置并行最大为10个线程

int n_total_thread = 0; // 用来控制：主程序的结束执行，当所有任务线程执行完毕

ILog log_add = new LogHelper("Add_Thread");

ILog log_del = new LogHelper("Del_Thread");

ILog log_wait = new LogHelper("Wait_Thread");

ILog log_set = new LogHelper("Set_Thread");

ILog log_for = new LogHelper("For_Thread");

ConsoleTitle = stringFormat("调用WCF的方式 => {0}, 调用次数=> {1}"

, select == "1" "Restful" : "Socket"

, num);

List<int> list_Thread = new List<int>();

SystemThreadingAutoResetEvent wait_sync = new SystemThreadingAutoResetEvent(false); // 用来控制：并发最大个数线程=n_max_thread

SystemThreadingAutoResetEvent wait_main = new SystemThreadingAutoResetEvent(false); // 用来控制：主程序的结束执行，当所有任务线程执行完毕

DateTime date_step = DateTimeNow;

for (long i = 0; i < num; i++)

{

Num_Query_Static++;

if (i >0 && (i+1-1) % n_max_thread == 0) // -1 表示第max个线程尚未开始

{

//log_waitInfo(stringFormat("thread n= {0},for i= {1}", dic_ThreadCount, i + 1));

wait_syncWaitOne(); // 每次并发10个线程，等待处理完毕后，在发送下一次并发线程

}

log_forInfo(stringFormat("thread n= {0},for i= {1}", list_ThreadCount, i + 1));

SystemThreadingThreadPoolQueueUserWorkItem

((data) =>

{

int id = SystemThreadingThreadCurrentThreadManagedThreadId;

SystemThreadingMonitorEnter(list_Thread);

list_ThreadAdd(id);

SystemThreadingMonitorExit(list_Thread);

log_addInfo(stringFormat("id={0}, count={1}", id, list_ThreadCount)); // 日志

if (select == "1") // Restful方式调用

{

Query_Htty();

}

else

{

Query_Socket();

}

n_total_thread += 1;

if (list_ThreadCount == (n_max_thread) || n_total_thread == num)

{

list_ThreadClear();

//log_setInfo(stringFormat("thread n= {0},for i= {1}", dic_ThreadCount, i + 1));

//wait_syncSet();

if (n_total_thread != num)

{

wait_syncSet(); // 任务线程，继续执行

}

else

{

wait_mainSet(); // 主程序线程，继续执行

}

}

}, list_Thread);

}

wait_mainWaitOne();

ConsoleWriteLine(stringFormat("总测试{0}次，总耗时{1}, 平均耗时{2}"

, num

, (DateTimeNow - date_step)ToString()

, (DateTimeNow - date_step)TotalMilliseconds / num));

Query_Thread();

}

WCF后台服务代码

private static ILog log = new LogHelper("SeqService"); // 日志

private static Dictionary<int, DateTime> dic_thread = new Dictionary<int, DateTime>(); // 线程列表

private static long Num = 0; // 线程个数

private static object lock_Num = 0; // 共享数据-锁

/// <summary>

/// 在线申请流水号

/// </summary>

/// <returns></returns>

[WebGet(UriTemplate = "GetSeqNum/Json", ResponseFormat = WebMessageFormatJson)]

public string GetSeqNumber()

{

lock (lock_Num)

{

Num++;

int id_thread = SystemThreadingThreadCurrentThreadManagedThreadId;

DateTime now = DateTimeNow;

if (!dic_threadTryGetValue(id_thread, out now))

{

dic_threadAdd(id_thread, DateTimeNow);

}

}

string ret = DateTimeNowToString("yyyyMMdd") + NumToString(new string('0', 9));

logInfo(stringFormat("{0}, Thread={1}/{2}", ret, SystemThreadingThreadCurrentThreadManagedThreadId, dic_threadCount));

return ret;

}

5 实验结果

1 10000个WCF网络http请求，CPU分成每次10个（10可以按需求调整）线程并发执行，并且主程序在所有请求都执行完毕后，才退出主程序。