4.1)算法调优。算法非常重要，好的算法会有更好的性能。举几个我经历过的项目的例子，大家可以感觉一下。
　　● 一个是过滤算法，系统需要对收到的请求做过滤，我们把可以被filter in/out的东西配置在了一个文件中，原有的过滤算法是遍历过滤配置，后来，我们找到了一种方法
可以对这个过滤配置进行排序，这样就可以用二分折半的方法来过滤，系统性能增加了50%。
　　● 一个是哈希算法。计算哈希算法的函数并不高效，一方面是计算太费时，另一方面是碰撞太高，碰撞高了就跟单向链表一个性能(可参看Hash Collision DoS 问题)。我们
知道，算法都是和需要处理的数据很有关系的，就算是被大家所嘲笑的“冒泡排序”在某些情况下(大多数数据是排好序的)其效率会高于所有的排序算法。哈希算法也一样，广为
人知的哈希算法都是用英文字典做测试，但是我们的业务在数据有其特殊性，所以，对于还需要根据自己的数据来挑选适合的哈希算法。对于我以前的一个项目，公司内某牛人给
我发来了一个哈希算法，结果让我们的系统性能上升了150%。(关于各种哈希算法，你一定要看看StackExchange上的这篇关于各种hash算法的文章 )
　　● 分而治之和预处理。以前有一个程序为了生成月报表，每次都需要计算很长的时间，有时候需要花将近一整天的时间。于是我们把我们找到了一种方法可以把这个算法发成
增量式的，也就是说我每天都把当天的数据计算好了后和前一天的报表合并，这样可以大大的节省计算时间，每天的数据计算量只需要20分钟，但是如果我要算整个月的，系统则
需要10个小时以上(SQL语句在大数据量面前性能成级数性下降)。这种分而治之的思路在大数据面前对性能有很帮助，就像merge排序一样。SQL语句和数据库的性能优化也是这一策
略，如：使用嵌套式的Select而不是笛卡尔积的Select，使用视图，等等。

4.2)代码调优。从我的经验上来说，代码上的调优有下面这几点：
　　● 字符串操作。这是最费系统性能的事了，无论是strcpy, strcat还是strlen，最需要注意的是字符串子串匹配。所以，能用整型最好用整型。举几个例子，第一个例子是N
年前做银行的时候，我的同事喜欢把日期存成字符串(如：2012-05-29 08:30:02)，我勒个去，一个select where between语句相当耗时。另一个例子是，我以前有个同事把一些状
态码用字符串来处理，他的理由是，这样可以在界面上直接显示，后来性能调优的时候，我把这些状态码全改成整型，然后用位操作查状态，因为有一个每秒钟被调用了150K次的
函数里面有三处需要检查状态，经过改善以后，整个系统的性能上升了30%左右。还有一个例子是，我以前从事的某个产品编程规范中有一条是要在每个函数中把函数名定义出来，
如：const char fname[]=”functionName()”, 这是为了好打日志，但是为什么不声明成 static类型的呢?
　　● 多线程调优。有人说，thread is evil，这个对于系统性能在某些时候是个问题。因为多线程瓶颈就在于互斥和同步的锁上，以及线程上下文切换的成本，怎么样的少用锁
或不用锁是根本(比如：多版本并发控制(MVCC)在分布式系统中的应用 中说的乐观锁可以解决性能问题)，此外，还有读写锁也可以解决大多数是读操作的并发的性能问题。这里多
说一点在C++中，我们可能会使用线程安全的智能指针AutoPtr或是别的一些容器，只要是线程安全的，其不管三七二十一都要上锁，上锁是个成本很高的操作，使用AutoPtr会让我
们的系统性能下降得很快，如果你可以保证不会有线程并发问题，那么你应该不要用AutoPtr。我记得我上次我们同事去掉智能指针的引用计数，让系统性能提升了50%以上。对于
Java对象的引用计数，如果我猜的没错的话，到处都是锁，所以，Java的性能问题一直是个问题。另外，线程不是越多越好，线程间的调度和上下文切换也是很夸张的事，尽可能
的在一个线程里干，尽可能的不要同步线程。这会让你有很多的性能。
　　● 内存分配。不要小看程序的内存分配。malloc/realloc/calloc这样的系统调非常耗时，尤其是当内存出现碎片的时候。我以前的公司出过这样一个问题——在用户的站点
上，我们的程序有一天不响应了，用GDB跟进去一看，系统hang在了malloc操作上，20秒都没有返回，重启一些系统就好了。这就是内存碎片的问题。这就是为什么很多人抱怨STL
有严重的内存碎片的问题，因为太多的小内存的分配释放了。有很多人会以为用内存池可以解决这个问题，但是实际上他们只是重新发明了Runtime-C或操作系统的内存管理机制，
完全于事无补。当然解决内存碎片的问题还是通过内存池，具体来说是一系列不同尺寸的内存池(这个留给大家自己去思考)。当然，少进行动态内存分配是最好的。说到内存池就
需要说一下池化技术。比如线程池，连接池等。池化技术对于一些短作业来说(如http服务) 相当相当的有效。这项技术可以减少链接建立，线程创建的开销，从而提高性能。
　　● 异步操作。我们知道Unix下的文件操作是有block和non-block的方式的，像有些系统调用也是block式的，如：Socket下的select，Windows下的WaitforObject之类的，如
果我们的程序是同步操作，那么会非常影响性能，我们可以改成异步的，但是改成异步的方式会让你的程序变复杂。异步方式一般要通过队列，要注间队列的性能问题，另外，异
步下的状态通知通常是个问题，比如消息事件通知方式，有callback方式，等，这些方式同样可能会影响你的性能。但是通常来说，异步操作会让性能的吞吐率有很大提升
(Throughput)，但是会牺牲系统的响应时间(latency)。这需要业务上支持。
　　● 语言和代码库。我们要熟悉语言以及所使用的函数库或类库的性能。比如：STL中的很多容器分配了内存后，那怕你删除元素，内存也不会回收，其会造成内存泄露的假像
，并可能造成内存碎片问题。再如，STL某些容器的size()==0 和 empty()是不一样的，因为，size()是O(n)复杂度，empty()是O(1)的复杂度，这个要小心。Java中的JVM调优需要
使用的这些参数：-Xms -Xmx -Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold，还需要注意JVM的GC，GC的霸气大家都知道，尤其是full GC(还整理内存碎片)，他就像“恐龙
特级克赛号”一样，他运行的时候，整个世界的时间都停止了。
　　4.3)网络调优
　　关于网络调优，尤其是TCP Tuning(你可以以这两个关键词在网上找到很多文章)，这里面有很多很多东西可以说。看看Linux下TCP/IP的那么多参数就知道了(顺便说一下，你
也许不喜欢Linux，但是你不能否认Linux给我们了很多可以进行内核调优的权力)。强烈建议大家看看《TCP/IP 详解 卷1:协议》这本书。我在这里只讲一些概念上的东西。
　　A) TCP调优
　　我们知道TCP链接是有很多开销的，一个是会占用文件描述符，另一个是会开缓存，一般来说一个系统可以支持的TCP链接数是有限的，我们需要清楚地认识到TCP链接对系统的
开销是很大的。正是因为TCP是耗资源的，所以，很多攻击都是让你系统上出现大量的TCP链接，把你的系统资源耗尽。比如著名的SYNC Flood攻击。
　　所以，我们要注意配置KeepAlive参数，这个参数的意思是定义一个时间，如果链接上没有数据传输，系统会在这个时间发一个包，如果没有收到回应，那么TCP就认为链接断
了，然后就会把链接关闭，这样可以回收系统资源开销。(注：HTTP层上也有KeepAlive参数)对于像HTTP这样的短链接，设置一个1-2分钟的keepalive非常重要。这可以在一定程度
上防止DoS攻击。有下面几个参数(下面这些参数的值仅供参考)：
1
2
3
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 20
net.ipv4.tcp_fin_timeout = 30

对于TCP的TIME_WAIT这个状态，主动关闭的一方进入TIME_WAIT状态，TIME_WAIT状态将持续2个MSL(Max Segment Lifetime)，默认为4分钟，TIME_WAIT状态下的资源不能回收。有
大量的TIME_WAIT链接的情况一般是在HTTP服务器上。对此，有两个参数需要注意，
1
2
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
　　前者表示重用TIME_WAIT，后者表示回收TIME_WAIT的资源。
　　TCP还有一个重要的概念叫RWIN(TCP Receive Window Size)，这个东西的意思是，我一个TCP链接在没有向Sender发出ack时可以接收到的最大的数据包。为什么这个很重要?因
为如果Sender没有收到Receiver发过来ack，Sender就会停止发送数据并会等一段时间，如果超时，那么就会重传。这就是为什么TCP链接是可靠链接的原因。重传还不是最严重的
，如果有丢包发生的话，TCP的带宽使用率会马上受到影响(会盲目减半)，再丢包，再减半，然后如果不丢包了，就逐步恢复。相关参数如下：
1
2
3
4
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
　　一般来说，理论上的RWIN应该设置成：吞吐量 * 回路时间。Sender端的buffer应该和RWIN有一样的大小，因为Sender端发送完数据后要等Receiver端确认，如果网络延时很大
，buffer过小了，确认的次数就会多，于是性能就不高，对网络的利用率也就不高了。也就是说，对于延迟大的网络，我们需要大的buffer，这样可以少一点ack，多一些数据，对
于响应快一点的网络，可以少一些buffer。因为，如果有丢包(没有收到ack)，buffer过大可能会有问题，因为这会让TCP重传所有的数据，反而影响网络性能。(当然，网络差的情
况下，就别玩什么高性能了) 所以，高性能的网络重要的是要让网络丢包率非常非常地小(基本上是用在LAN里)，如果网络基本是可信的，这样用大一点的buffer会有更好的网络传
输性能(来来回回太多太影响性能了)。
　　另外，我们想一想，如果网络质量非常好，基本不丢包，而业务上我们不怕偶尔丢几个包，如果是这样的话，那么，我们为什么不用速度更快的UDP呢?你想过这个问题了吗?
　　B)UDP调优
　　说到UDP的调优，有一些事我想重点说一样，那就是MTU——最大传输单元(其实这对TCP也一样，因为这是链路层上的东西)。所谓最大传输单元，你可以想像成是公路上的公交
车，假设一个公交车可以最多坐70人，带宽就像是公路的车道数一样，如果一条路上最多可以容下100辆公交车，那意味着我最多可以运送7000人，但是如果公交车坐不满，比如平
均每辆车只有20人，那么我只运送了2000人，于是我公路资源(带宽资源)就被浪费了。 所以，我们对于一个UDP的包，我们要尽量地让他大到MTU的最大尺寸再往网络上传，这样可
以最大化带宽利用率。对于这个MTU，以太网是1500字节，光纤是4352字节，802.11无线网是7981。但是，当我们用TCP/UDP发包的时候，我们的有效负载Payload要低于这个值，因
为IP协议会加上20个字节，UDP会加上8个字节(TCP加的更多)，所以，一般来说，你的一个UDP包的最大应该是1500-8-20=1472，这是你的数据的大小。当然，如果你用光纤的话，
这个值就可以更大一些。(顺便说一下，对于某些NB的千光以态网网卡来说，在网卡上，网卡硬件如果发现你的包的大小超过了MTU，其会帮你做fragment，到了目标端又会帮你做
重组，这就不需要你在程序中处理了)
　　再多说一下，使用Socket编程的时候，你可以使用setsockopt() 设置 SO_SNDBUF/SO_RCVBUF 的大小，TTL和KeepAlive这些关键的设置，当然，还有很多，具体你可以查看一
下Socket的手册。
　　最后说一点，UDP还有一个最大的好处是multi-cast多播，这个技术对于你需要在内网里通知多台结点时非常方便和高效。而且，多播这种技术对于机会的水平扩展(需要增加
机器来侦听多播信息)也很有利。
　　C)网卡调优
　　对于网卡，我们也是可以调优的，这对于千兆以及网网卡非常必要，在Linux下，我们可以用ifconfig查看网上的统计信息，如果我们看到overrun上有数据，我们就可能需要
调整一下txqueuelen的尺寸(一般默认为1000)，我们可以调大一些，如：ifconfig eth0 txqueuelen 5000。Linux下还有一个命令叫：ethtool可以用于设置网卡的缓冲区大小。在
Windows下，我们可以在网卡适配器中的高级选项卡中调整相关的参数(如：Receive Buffers, Transmit Buffer等，不同的网卡有不同的参数)。把Buffer调大对于需要大数据量的
网络传输非常有效。

　D)其它网络性能
　　关于多路复用技术，也就是用一个线程来管理所有的TCP链接，有三个系统调用要重点注意：一个是select，这个系统调用只支持上限1024个链接，第二个是poll，其可以突破
1024的限制，但是select和poll本质上是使用的轮询机制，轮询机制在链接多的时候性能很差，因主是O(n)的算法，所以，epoll出现了，epoll是操作系统内核支持的，仅当在链
接活跃时，操作系统才会callback，这是由操作系统通知触发的，但其只有Linux Kernel 2.6以后才支持(准确说是2.5.44中引入的)，当然，如果所有的链接都是活跃的，过多的
使用epoll_ctl可能会比轮询的方式还影响性能，不过影响的不大。
　　另外，关于一些和DNS Lookup的系统调用要小心，比如：gethostbyaddr/gethostbyname，这个函数可能会相当的费时，因为其要到网络上去找域名，因为DNS的递归查询，会
导致严重超时，而又不能通过设置什么参数来设置time out，对此你可以通过配置hosts文件来加快速度，或是自己在内存中管理对应表，在程序启动时查好，而不要在运行时每次
都查。另外，在多线程下面，gethostbyname会一个更严重的问题，就是如果有一个线程的gethostbyname发生阻塞，其它线程都会在gethostbyname处发生阻塞，这个比较变态，要
小心。(你可以试试GNU的gethostbyname_r()，这个的性能要好一些) 这种到网上找信息的东西很多，比如，如果你的Linux使用了NIS，或是NFS，某些用户或文件相关的系统调用
就很慢，所以要小心。