摘要：第一次寫項目，用的，也沒啥經驗，前期開發比較緊所以以實現功能為主，下面記錄自己的一些性能優化筆記。如果是在不使用數據庫連接池的情況下，必須在使用完數據庫之后關閉連接。所以使用數據庫連接池勢在必行，不然就是費代碼了。

第一次寫 java 項目，用的 netty5.0，也沒啥經驗，前期開發比較緊所以以實現功能為主，下面記錄自己的一些性能優化筆記。
以某接口為例，該接口是 feed 流，里面包含的信息有：

30條 feed 信息 
每條 feed 下的最近的5條評論，和該評論總數
每條 feed 屬主的用戶信息
每條 feed 屬主和瀏覽者的好友關系
每條 feed 屬主和瀏覽者的地理位置距離

先不做壓測了，直接在 chrome 里打開看響應耗時，
請求時間可以忽略不計，等待時間和文檔下載時間都太長了

將上面所有的信息都在 redis 緩存后的耗時

后端服務我直接用 netty 做服務和 api，沒有設置壓縮導致 api 文本很大
調試一個類似大小的之前項目的 api 做了壓縮處理的，發現文檔大小變化很大，如下圖 124k 被壓縮到了9.4k
返回的頭信息

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 25 Aug 2015 04:14:54 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Content-Encoding: gzip
Vary: Accept-Encoding

而我目前卻還沒做壓縮處理,
直接請求 netty 返回的頭信息

HTTP/1.1 200 OK
content-length: 126792
connection: keep-alive

走前端 nginx 轉發到后端 netty 返回的頭信息

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 25 Aug 2015 04:21:39 GMT
Content-Length: 126792
Connection: keep-alive

添加transfer-encoding頭信息

response.headers().set(TRANSFER_ENCODING,HttpHeaderValues.CHUNKED);

雖然不能縮短請求時間，但是能在接受到第一個 chunked 包就可以開始解析 api 文檔了。理論上可以縮短了客戶端加載的時間（不對請拍磚）解釋：http://blog.haohtml.com/archives/4777

我嘗試著在 netty 里添加了壓縮

response.headers().set(CONTENT_ENCODING, HttpHeaderValues.GZIP);

但是不好使，找了半天也沒找到資料，最后只能把壓縮轉 nginx 里做的處理。
nginx 里的 gzip 配置如下：

  gzip on;
  gzip_min_length  1k;
  gzip_buffers     4 4k;
  gzip_http_version 1.0;
  gzip_comp_level 2;
  gzip_types       text/plain application/x-javascript text/css application/xml text/javascript;
  gzip_vary on;

在不聲明文檔類型的時候，通過 nginx 反向代理之后的 http 返回頭信息如下：

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 25 Aug 2015 07:49:39 GMT
Transfer-Encoding: chunked
Connection: keep-alive

在 netty 里添加了文件類型聲明之后

response.headers().set(CONTENT_TYPE,HttpHeaderValues.TEXT_PLAIN);

再看 nginx 返回的信息則有壓縮了

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 25 Aug 2015 07:55:57 GMT
Content-Type: text/plain; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Content-Encoding: gzip

發現文本有了很大的壓縮，下載時間大大減少了（在我做筆記的時候api 的文檔大小因為數據變化而減少了3k）

今天在來公司的路上想到，我們大 PHP 在使用數據庫的時候基本上是使用了就不用關(在析構函數里釋放數據庫連接),在同一個請求里面使用的數據庫連接是同一個，在請求完畢的時候就釋放該數據庫連接。

做了如下測試，模擬一個 api 需要做30次數據庫查詢

for ($i=1; $i < 30; $i++) { 
    $sql = "select 1 from user limit where id=".$i;
    $res = $db->query($sql);
    echo "查詢了".$i."次
";
}

zhoumengkang$ mysql -uroot -pzmkzmk -e "show global status"|grep "Connections"
Warning: Using a password on the command line interface can be insecure.
Connections    30198
zhoumengkang$ php 2.php
查詢了1次
查詢了2次
查詢了3次
查詢了4次
查詢了5次
查詢了6次
查詢了7次
查詢了8次
查詢了9次
查詢了10次
查詢了11次
查詢了12次
查詢了13次
查詢了14次
查詢了15次
查詢了16次
查詢了17次
查詢了18次
查詢了19次
查詢了20次
查詢了21次
查詢了22次
查詢了23次
查詢了24次
查詢了25次
查詢了26次
查詢了27次
查詢了28次
查詢了29次
查詢了30次
數據庫連接關閉了
zhoumengkang$ mysql -uroot -pzmkzmk -e "show global status"|grep "Connections"
Warning: Using a password on the command line interface can be insecure.
Connections    30200

加上上面終端請求查詢數據庫，共增加了兩個連接，也就是說上面的30次請求就連接了一次數據庫。

如果是 java 在不使用數據庫連接池的情況下，必須在使用完數據庫之后關閉連接。類似的方法測試發現 java 會連接30次數據庫。所以使用數據庫連接池勢在必行，不然就是費代碼了。

弄了半天，使用的是apache.commons.dbcp，做了下壓測對比，還是在一個 api 里做30次數據庫插入操作。
在不使用連接池的情況下

zhoumengkang$ ab -c100 -n1000 "http://localhost:8081/?method=test"
Requests per second:    17.24 [#/sec] (mean)
Time per request:       5800.506 [ms] (mean)

連接數直接增加了3萬。耗時58秒。使用了連接池后，

Requests per second:    158.87 [#/sec] (mean)
Time per request:       629.462 [ms] (mean)

設置的最小連接數20，耗時6秒。相差還是很大的。