Tag: concurrent

Python Flask 框架的并发能力及线,进程模型

2023-02-18 | 阅读(3,616)

本文旨在测试 Python Flask 框架的默认并发能力，即同时能处理多少个请求，以及请求等待队列大致有多大; 并找到如何改变默认并发数。虽然网上或许很容易找到它们的默认并发数，但通过实验的方式可以得到更感性的认识。

本文写作时使用的环境为

  1. 测试机器为 MacBook Pro, CPU 6 核超线程，内存 16 Gb
  2. JMeter 5.5 -- 连续发送请或压力测试
  3. Python 3.10.9
  4. Flask 2.2.2

从 JMeter 每半秒发送一个请求，连续发送 1000 个，程序中 API 方法接受到请求后 sleep 800 秒，保证在全部 1000 个请求送出之前一直占着连接，以此来找到同时被处理的请求数目，并且有足够的时间统计当前的 TCP 连接数。在测试极端规模的并发数时，由于在 Mac OS X 很难突破 5000 个线程的限制，这时就让 JMeter 分布到远程 Linux(Docker 或虚拟机) 上执行。

请求的 URL 是 http://localhost:8080/?id=${count}, 带一个自增序列用以识别不同的请求， JMeter 的 Thread Group 配置为 Number of Threads (users): 1000, Ramp-up period (seconds): 500 阅读全文 >>

Akka Actor: 从最简单的例子开始

2018-02-11 | 阅读(2,249)

Akka 是什么？它提供了 JVM 上的 Actor 编程模型 -- 同时兼顾了并发与分布式。它由 Scala 编写的，替代了 Scala 本身的 Actor。Actor 视线程为重量级的资源，能够以少量的内存胜任更高的并发，类似的东西有纤程，协程。有一个数据对比是同样的 1GB 内存，可以创建 2.7M 个 Actor, 而线程只能创建 4096 个，仅供参考，当然 Java 也是会基于线程池来执行的。

Actor 增加了程序的灵活性，并减轻了复杂度(标准的赞美之辞)。

所谓 Action 编程模型兼顾并发与分布，是由于让你编程时可以不用考虑线程，线程配置成为部署的范畴; Actor 之间通信只能发送异步消息，Actor 可以分布在同一 JVM, 不同 JVM, 或是不同物理机器上。

因为 《Akka IN ACTION》中提供了第一个例子起点着实有点高，所以网上找来了一个了解 Akka Actor 的最简单例子，来自于 Simple Scala Akka Actor examples (Hello, world examples)。并非纯属翻译，主要是为了练手，所以不完全一致： 阅读全文 >>

CountDownLatch 协调线程

2013-10-19 | 阅读(661)

JDK8 都快要出来了，在 JDK 5 中仍有许多好宝贝值得去挖掘。提到 JDK5 我们或许只知道它给了我们泛型，其实还有那个并发包 java.util.concurrent 却不那么引人注目，其实就是 NIO。

若是并发包是在某个 JDK 版本中单独奉上，反响就不同了，想想 JDK 6 似乎未带来多少改变--至少对于编程者来说没有明显感受。java.util.concurrent 包中的东西对于我们处理线程带来了很大的便利，例如线程池，线程同步，Future, Callable 等。

这里我记录一下 CountDownLatch 的使用，在此之前在处理

线程 A 等待线程 B，C，D 全部执行完后才继续执行 （比如要每个线程都访问一个 Web 服务，等所有的请求响应成功后进行结果处理）

这样场景的时候，我一般能想到的办法是，初始一个计数器，线程 B，C，D 各自初始化的时候，计数器加一，然后 A 线程等待，每个线程执行完后计数器减一，当计数器为 0 时表明所有任务执行完毕，就通知 A 可以开始运作起来。但这样的方案还是得小心的处理好同步的问题。 阅读全文 >>