|
|
|
|
@ -639,15 +639,22 @@ org.quartz.threadPool.threadPriority: 5
|
|
|
|
|
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread: true
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
XXL-JOB系统中业务逻辑在远程执行器执行，调度中心每次触发调度时仅发送一次调度请求，执行器会将请求存入执行队列并且立即响应调度中心；相比直接在quartz的QuartzJobBean中执行业务逻辑，极大的降低了调度线程占用；
|
|
|
|
|
XXL-JOB系统中业务逻辑在远程执行器执行，全异步化设计，调度中心每次触发调度时仅发送一次调度请求，执行器会将请求存入执行队列并且立即响应调度中心，异步运行；相比直接在quartz的QuartzJobBean中执行业务逻辑，极大的降低了调度线程占用时间；
|
|
|
|
|
|
|
|
|
|
XXL-JOB调度中心中每个JOB逻辑非常 “轻”，单个JOB一次运行平均耗时基本在 "10ms" 之内（基本为一次请求的网络开销）；因此，可以保证使用有限的线程支撑大量的JOB并发运行；
|
|
|
|
|
|
|
|
|
|
理论上采用推荐机器配置 "4核4G内存"情况下，单线程可以承担 100（quartz最小时间粒度1000ms/触发一次任务耗时10ms）个密集任务（每秒执行一次）的正常调度触发。因此，默认配置的15个线程理论上可以承担起1500个密集任务的正常运行。
|
|
|
|
|
理论支撑任务量公式如下：
|
|
|
|
|
|
|
|
|
|
实际场景中，调度请求网络耗时不同、DB读写耗时不同、任务密集或稀疏调度情况不同，会导致任务量上限会上下波动。
|
|
|
|
|
理论支撑任务量 = 线程数配置 / 平均调度频率（每秒） * 平均触发耗时（单位s）
|
|
|
|
|
|
|
|
|
|
如若需要支撑更多的任务量，可以通过 "调大调度线程数" 和 "提升机器配置" 两种方式实现。
|
|
|
|
|
理论上采用推荐机器配置 "4核4G内存" + "配置1s运行1次密集任务" + "调度中心与执行器ping延迟10ms（0.01s）" 的情况下，
|
|
|
|
|
|
|
|
|
|
- 单线程支撑任务量 ：1 / 1 * 0.01 = 100个任务
|
|
|
|
|
- 15个线程支撑任务量：15 / 1 * 0.01 = 1500个任务
|
|
|
|
|
|
|
|
|
|
实际场景中，由于调度中心与执行器ping延迟不同、DB读写耗时不同、任务调度密集程度不同，会导致任务量上限会上下波动。
|
|
|
|
|
|
|
|
|
|
如若需要支撑更多的任务量，可以通过 "调大调度线程数" 、"降低调度中心与执行器ping延迟" 和 "提升机器配置" 几种方式实现。
|
|
|
|
|
|
|
|
|
|
#### 5.4.5 @DisallowConcurrentExecution
|
|
|
|
|
XXL-JOB调度模块的“调度中心”默认不使用该注解，即默认开启并行机制，因为RemoteHttpJobBean为公共QuartzJobBean，这样在多线程调度的情况下，调度模块被阻塞的几率很低，大大提高了调度系统的承载量。
|
|
|
|
|
|
xuxueli
7 years ago