【问题标题】:Capture timing within parallel stream procesing在并行流处理中捕获时间
【发布时间】:2019-07-23 09:11:56
【问题描述】:

我有一个计时器类,用于捕获我的一个进程的解压缩时间和反序列化时间。我正在使用并行流来执行上述操作,并想知道我所有对象的总解压缩时间和反序列化时间

我正在调用 getVersionedRawDealNew(),它会为每个交易解压缩和反序列化。

转换时间比整个方法处理我的所有对象所花费的时间要长得多,这似乎是不正确的。如果以下转换时间的计算方式正确,您能告诉我吗?

    ProcessTimer timer = new ProcessTimer();
    List<VersionedRawDeal> versionedRawDeals = compressedVersionedRawDeals
            .parallelStream()
            .map(vrd -> getVersionedRawDealNew(vrd, timer))
            .collect(Collectors.toList());

    LOGGER.info("Time taken to process zipping : " + timer.getZipTime());
    LOGGER.info("Time taken to process transformation :" + timer.getTransformTime());

//getVeronedRawDealNew 方法

private VersionedRawDeal getVersionedRawDealNew(CompressedVersionedRawDeal compressedVerDeal, ProcessTimer timer){
    CompressedRawDeal compressedDeal = compressedVerDeal.rawDeal();
    DealVersion dealVersion = compressedVerDeal.dealVersion();

    long zipStartTime = System.currentTimeMillis();
    final String dealXml = unzip(dealVersion, compressedDeal.getDealXmlBytes());
    long zipTime = System.currentTimeMillis() - zipStartTime;
    timer.addZipTime(zipTime);

    long transformStartTime = System.currentTimeMillis();
    final RawDeal rawDeal = RawDealTransformers.getRawDealTransformerFor(compressedDeal.getSourceSystem())
            .transformDeal(compressedDeal.getSourceEvent(), dealXml);

    long transformTime = System.currentTimeMillis() - transformStartTime;
    timer.addTransformTime(transformTime);
    return ImmutableVersionedRawDeal.builder().dealVersion(dealVersion).rawDeal(rawDeal).build();
}

//进程定时器

public class ProcessTimer {

    private AtomicLong zipTime;
    private AtomicLong transformTime;

    public ProcessTimer(){
        this.zipTime = new AtomicLong();
        this.transformTime = new AtomicLong();
    }

    public void addZipTime(long time){
        this.zipTime.addAndGet(time);
    }

    public void addTransformTime(long time){
        this.transformTime.addAndGet(time);
    }

    public long getZipTime(){
        return zipTime.get();
    }

    public long getTransformTime(){
        return transformTime.get();
    }
}

输出

我没有得到正确的时间计算,因为我有一个包含上述调用的计时器,即在父方法中,运行整个过程所需的时间小于我的转换时间。包含解压缩和转换时间的父方法的计时器应该大于我的转换时间,但事实并非如此。

【问题讨论】:

    标签: java multithreading parallel-processing java-stream


    【解决方案1】:

    转换时间大于整个方法时间,因为您使用的是创建并行任务(同时运行的任务)的并行流。您将同时运行的并行任务的时间相加。

    0--------------------------------------------------------  
       |                        |                             |
       |                        |                             | 
       |(1 parallel taks 3sec)  |                             |  
                                | (2 parallel task 4sec)      | 
    5---------------------------------------------------------|(the whole metod took 5 sec)
    

    该方法耗时 5(秒),其中一个并行任务耗时 3 秒,第二个耗时 4 秒,因此转换时间为 7,大于整个方法时间 5 秒。

    【讨论】:

    • 这很有趣,那么单独计算实际转换时间的最佳方法是什么?有什么建议吗?
    • @megan 分别测量每个的执行然后聚合,或者只是切换到顺序流并查看序列化操作的总时间
    • 这取决于,您现在拥有的是您的转换所花费的“实时”时间。如果您想知道“一次”转换是如何进行的,您可以将时间除以交易数量,您将获得一次转换的平均时间。
    • 感谢@HPCS 的建议。我遇到的问题是我的交易可能有不同的规模,转换两个不同交易所需的时间可能会有很大差异。因此,将一两笔交易作为基准并在多笔交易中进行推断可能效果不佳。总的来说,当我将其并行化为顺序执行时,我的方法更快,但转换时间与我并行化时完全不同,因为线程交错并在稍后完成。
    • @GrzegorzPiwowarek 我想我无法计算并行流中的转换时间。我想知道在我的并行处理中,转换与解压缩占用了总时间的百分比。
    猜你喜欢
    • 1970-01-01
    • 2018-07-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-03-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多