python框架碎言

　　不同的人喜歡不同的框架，各自認爲所用框架比較順手，比較適合自己，同時又承認著各自框架的缺陷，卻以各有特性爲名。

　　這個星期用webpy重寫了公司一個庫的數個接口，自己也想不到這麼快，1天就搞掂，原本是用django。並測試了nginx，uwsgi什麼的效率，其中調節somaxconn是一個重點。裸跑nginx係一個神一般的連接能力，輕而易舉上6、7千rqs，加入uwsgi+webpy也是輕易上2、3千的rqs，加入mysql查詢就即刻slow down，幾百的rqs，以上是4個uwsgi，2個nginx worker都有寫日誌的結果。寫不寫日誌對rqs性能影響十分之大，所以其實系統大了真的要將日誌系統單獨分離，磁盤性能真是受不了，特別是那數據庫。其實宏觀點看，無非就是一條條的數據流，哪裏有瓶頸了，就可以在那裏切開，分成幾條並行的線路。

　　現在來看，各個框架都有那麼一些問題吧，儘管tornado以其高性能著稱，但是寫起comet來還是十分醜陋，近期還想看看uliweb，然後由數據庫連接，小組件等開始，打造一個類似uliweb的東東。the5fire牛十分推崇django，但我卻覺得django真的是一件類似wordpress的陶瓷，你要畫畫很容易，想要改變一下形狀根本沒戲，當然，經過深入學習當然可以，但是走的路不是一般的多。像 https://github.com/ziyan/django-comet‎ 把它造成一個應用的樣子，是可以，引入tornado就不說了，這樣實現成一個app根本就是一朵奇葩，當然，是可以用的。

　　指出這樣的一些問題不是想針對什麼框架之流，而是有那麼一些新的底層技術的變更，頂層亦應該跟着變更，固守甚至認爲某些框架是完備的，只會使自己的視野變得狹窄。Tornado走了個先頭，但看一看tornado的風格，真心不想看第二遍，就像我看過一個用C++風格寫成的python項目一樣，添加什麼回調函數的，真是看着就想把它重新寫一遍。

　　再研究了一下SVM的imbalance dateset，然後一個星期就過去了，當然，還有兩日入職培訓+一日拓展活動。