不同的人喜歡不同的框架,各自認爲所用框架比較順手,比較適合自己,同時又承認著各自框架的缺陷,卻以各有特性爲名。
這個星期用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,然後一個星期就過去了,當然,還有兩日入職培訓+一日拓展活動。