512內存，1M帶寬跑10並發，還有優化空間嗎？

伺服器環境：阿里雲最低配置，1核CPU，512M內存，1M帶寬。
測試頁面：純動態列表頁架構：Django ＋ uwsgi + PostgreSQL + memcache + Nginx

用webbench測試了一下，在10並發的時候，用戶可以勉強訪問網站，監視的時候發現CPU彪的最高的是uwsgi進程，我開了64個子進程
請問還有優化空間嗎，有沒有代替uwsgi更好的方案來提高並發數？正常訪問的時候，動態頁面響應時間在100ms左右

workers, processes

Argument: number

Spawn the specified number of workers/processes.

This option may be set with -p from the command line.

Set the number of workers for preforking mode.
This is the base for easy and safe concurrency in your app. More workers
you add, more concurrent requests you can manage.
Each worker corresponds to a system process, so it consumes memory,
choose carefully the right number. You can easily drop your system to
its knees by setting a too high value.
Setting workers to a ridiculously high number will not magically make your application web scale – quite the contrary.

沒記錯的話這個選項應該是CPU數量+1。你可以試著調整一下子進程數量

根據我的經驗，你犯的錯誤是沒有用一台單獨的伺服器來運行PostgreSQL。

Django 這個框架太慢了，可以嘗試著換別的試試。至於uwsgi，個人感覺在單核機器上跑64worker這個明顯不合理，可以研究一下gevent協程方式抗並發。

如果你說的64個子進程指的是os的進程的話，1核CPU，不卡才怪。worker進程最好跟CPU核數一致，至少不要超得太多。如果設置方面沒問題的話，你得從優化程序架構方面入手了，先找出瓶頸，再針對性地優化。另外，推薦用gevent這種協程來做wsgi的server，相對而言，資源消耗要小得多。

對那些架構不懂，我感覺是不是用的組件太多了？會造成一些不必要的運算，而耗費CPU？另外，你的進程也太多了吧？--我只能讓更多的人看到這個問題了。@vczh