io密集场景测试

今天对于一个大量io的场景进行一个测试，来看不同的原理下的执行效率。

场景：调用https://jsonplaceholder.typicode.com/comments这个接口1w次，并把得到的数据存储到文件中。

这个场景中有两阶段的IO，一个是请求http接口，一个是写文件（文件最终有1.5G大小）。下面结果单位是秒

1 使用java

单线程串行执行的时间：500+s 去掉写文件部分：23

100个线程执行的时间： 50s 去掉写文件部分：5s

200个线程执行时间： 39s

500个线程执行时间： 85s 性能出现下降

mono执行出错，报错信息是netty的队列长度超过了1000，如果把1w个任务改成1k个执行时间是： 7s，依次类推1w个就是10倍，也就是70s左右，去掉写文件部分40s

2 使用nodejs

nodejs虽然是单线程，但是底层使用eventpool和epoll所以对于io场景具有天然的优势。

nodejs执行时间： 150+ 去掉写文件部分 99s

3 使用rust reqwest

reqwest使用了tokio本质是协程，应该能和golang执行效率差不多。

执行时间：404s worker线程调到100还是400s+ 怀疑是Future只有等到await的时候才执行导致的，还有就是debug模式比release慢很多。

use chrono;
use reqwest::Client;
use tokio::{fs::OpenOptions, io::AsyncWriteExt};

extern crate tokio;

#[macro_use]
extern crate lazy_static;


static URL: &str = "https://jsonplaceholder.typicode.com/comments";

lazy_static! {
    static ref CLIENT: Client = Client::new();
}

// 这里改不改的影响不大
// #[tokio::main(worker_threads = 100)]
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {

    let start = chrono::Utc::now().timestamp();
    let mut arr = vec![];
    for _i in 0..10000 {
        arr.push(run());
    }
    let end = chrono::Utc::now().timestamp();
    println!("任务添加完成时间: {}", end - start); // 0

    // 这种写法有400s+
    // for ele in arr.into_iter() {
    //     ele.await;
    // }

    // 改成这种降低至82s
    futures::future::join_all(arr).await;
    let end = chrono::Utc::now().timestamp();

    println!("执行时间: {}", end - start); // 
    Ok(())
}

async fn run() -> Result<(), Box<dyn std::error::Error>> {
    let str = CLIENT.get(URL)
        .send()
        .await?
        .text()
        .await?;
    let mut options = OpenOptions::new();
    let mut file = options
        .write(true)
        .read(true)
        .append(true)
        .create(true)
        .open("rust.txt")
        .await?;
    file.write_all(str.as_bytes()).await?;
    Ok(())
}

4 golang

golang用时：65s 提高线程数到100后，时间直接降低到20s左右，暴打java多线程

GOMAXPROCS=100 go run io-test.go

去掉写文件部分14s

5 结论

非极限情况下，线程池仍是一个性能极佳的选择。