zoukankan      html  css  js  c++  java
  • 关于性能的一些想法

    dccmx 于 2011年 一月 12日 发表 | 最后修改于 2011年 一月 12日

    经常会反反复复想一个问题:究竟什么样的程序才算得上是性能最优的程序。对应用的优化做到什么程度就已经没有优化的余地了,再想提高性能就只能加硬件,并行化了。

    想来想去竟成了一块心病。现在把我的一些不成熟的观点抛出来,希望能有技术圈的朋友们一起讨论讨论。

    个人觉得做到下面两点就差不多了。

    1.别让CPU闲着。

    2.别把CPU忙坏。

    先别骂我,听我把话说完。

    第一句的意思是,别让CPU闲着等资源。其实重点在“等”上。对于服务器端的linux程序来说,CPU如果闲了,最常见的就是等磁盘,等网络的IO了,当然也有等共享资源的锁啊什么的。为什么说让CPU闲着就不好了呢,因为CPU、网卡和硬盘本是(某种程度上)三个完全独立的硬件,它们本是并行的,都可以独立运行。而出现CPU等网卡或者等硬盘的化,说明我们的程序逻辑上将它们串行了。这样,本来可以同时拉货的三辆卡车变成了接力一样了,浪费计算资源,性能当然不是最优。

    对于这样的情况,解决方法便是CPU、网卡和硬盘之间的交互异步化。让所有的设备在等待上一个请求的时候可以做现在不做以后还是要做的事情。这样应该会好了吧。好了,这句话是从各种计算资源的合作的角度来看的。

    第二句话的意思,别把CPU给忙坏了,一直满负荷。如果这样,说明CPU已经尽全力来处理请求了,这是如果请求再多点就很可能不能及时处理完了。这应该是因为交给CPU计算的东西太多了。或者是做了重复的计算,或者是做了多余的计算。这就要从我们应用的逻辑设计上下功夫了。看看数据的设计是否合理,是否会造成重复或多余的计算。

    综合起来看,我认为,性能最优的程序应该是在设计的性能指标达标的同时,CPU不忙,硬盘、网络等数据吞吐100%。应该差不多了吧。你说呢?

  • 相关阅读:
    条形码:Code93
    MSSQL 又一个行列转换
    PowerShell查看Sharepoint日志
    SharePoint Meeting Workspace
    Developer Dashboard in SharePoint 2010
    SPUtility.SendEmail
    处理sharepoint 列表中的 person or group类型字段
    SharePoint Issue: Unable to oben the Site (Object null reference Error) Solution
    import a Microsoft SharePoint 2010 site definition
    SPListTemplateType 枚举 (Microsoft.SharePoint) 创建列表时的ListTemplate Type属性
  • 原文地址:https://www.cnblogs.com/lexus/p/2247545.html
Copyright © 2011-2022 走看看