性能测试中调度详解

       对服务端而言,如果客户端高并发的所有请求任务进入到执行的阶段,必然会给服务端带来系统级的灾难,这是因为服务端的底层服务以及系统的集群计算能力它终究是存在可承载的能力是有限的,毕竟不管是服务的承载能力还是计算引擎的数据分析都是,都是存在它的边界能力的,而不可能无限制的来接受客户端的所有请求并对这些请求进行立刻马上的处理,如果真如此,这样带来的灾难是系统级的瘫痪。

      当雪崩的时候,没有一片雪花是漂亮的。在性能测试的过程中需要找到底层服务承载的边界处理能力,以及找到计算引擎可承载的最大计算能力,但是仅仅这些是不够的,既然任何的服务以及计算引擎可承载的能力是存在边界的,那么针对边界这部分的任务排队以及任务优先级的思路又是什么了?这就是调度来思考的。不管是操作系统还是常规的其他计算引擎以及服务,都存在内部的调度算法,针对操作系统而言,调度可以简单的理解为CPU时间划分给活跃的进程和线程,而且维护一套优先级的机制,这样更重要的工作可以获取优先执行的机会,同时调度器会跟踪所有的ready-to-run状态的进程。系统的最小粒度是线程,那么也就是说系统调度中粒度最细的是针对线程的调度。下面详细地阐述下抢占式调度和非抢占式调度。

      假设在一个单核的CPU下运行20个线程,同一个时间只能运行一个线程,调度算法负责筛选线程执行的优先级,指定了哪些线程优先在CPU上执行,哪些线程需要排队等待。事实上,很多的时候线程执行的速度是非常快的,具体点来就是一个线程执行结束后会切换到另外一个线程来执行,在这个过程中,每个程序执行的时间多少都是由调度算法来进行决策,通过这样的方式来保障调度的公平性。但是往往给我们的错觉是许多任务都是在同时执行中,以为所有的任务都是并发执行中。还是回顾到前面说的࿰

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值