有點離題.. 不過我還是說說心得好了。你這份的結果跟我最近測的差不多，我有測純 container 的部份，但也有追加跑應用程式時的實測，大致上來說分幾層：
servlet container 現在都很快，不論是 tomcat/jetty/nio... 什麼的組合。如你的測試結果，每一種組合每秒都能達上千次的 request。但這先決條件是對象是個純 html 檔，或是一個沒邏輯的純 servlet。如果測試只跑到這個階段，那結果通常只受限於硬體和網路。
container 外，再加掛 http proxy 大概會讓效能掉 10~20% 左右 (我測 nginx)，不過還是能維持在 千/秒 這個量級。我想只要參數沒調壞一般不用太擔心這層的 cost。
如果網頁開始有邏輯，即網頁是由動態 template 產生，這時第一點的 千/秒 這個量級，會降到 百/秒 這個量級。端看用的 component 有多複雜 (例如 jsp tag 或是 freemarker macro 之類的)，越複雜的頁面效能越差。一般網頁東西都塞滿多的，所以都會降 10 倍左右。如果採用的網頁是用 jsp 寫的，那麼測 server 效能就要多測這一項。如果不是 jsp 那大概換什麼 server 結果都差不多。要小心有一些 template 效能很爛 (例如 thymeleaf，會掉到 十/秒 以下的量級)。
再下來是資料庫，測試中如果包含了資料庫存取，會發現效能會掉到 十/秒 這個量級了。而資料庫存取複雜的，掉到 個/秒 以下也很常見。
經過上面的實測，結論跟大家的經驗一樣，真正效能殺手是資料庫。如果資料庫解決了 (比方說加 cache)，就是直接快 10 倍以上。而這時候，下一個調整的目標會落在 template 上，不過 template 很難提升的 (複雜的網頁就是這麼複雜...)。等到克服了這關，效能又上升了 10 倍。而這時才有機會進入最後一層，即 container 的 nio/bio 之類的選擇和調整。也就是你這篇測試關心的題目。
由於前兩層的瓶頸太高，我現在只在意它們的調整，而不會在意選什麼牌的 server，我建議選自己熟悉的就好。而 nio/bio/apr，也都用預設的就好，頂多 bio 的 connection 上限數調高一點就是。如果未來有幸，能遇到需要 千/秒 這個量級以上的服務，那時候我會跳過 servlet container，直接用 netty 去處理，去做最細部的最佳化，以求得最高的效能。
題外話，我現在都改用 wrk1 ，而不是 ab，wrk 這個 client 比 ab 更快，可以壓搾更多 server 效能出來。
oauth 有個重要目的在於帳密不需經過 third party 處理 (只交給官方經手)
如果有個第三方 app 用 kaif 帳密直接登入，那這個第三方就能收集到使用者的帳密了。使用者信任 kaif 所以願意留帳密 (不然就不會註冊)，但不見得該信任第三方，尤其 kaif 管不到第三方軟體時。
因此現階段上面列的 API 只限自用。
先用 web 的登入方式頂著吧，有興趣的人可以看看：
[2015/04/08] 更新，原本這則討論有說明怎麼 hack kaif 的 web api。但我刪掉了，因為現在 kaif 已經有 open API 可用，請見 kaif Open API 說明1
最想要的就是 iOS 的 Share Extension ，所以要有 post link 的 API。
長遠來說就是可以做 http://hn.premii.com/1 樣子的 reader ，所以要 list 、like 和 mark read 的功能 (純練習某玩具用，所以也不一定做的出來... XD)