worker thought again

在
http://blogger.godfat.org/2009/05/event-driven-rails.html
提到一些關於 resizer 的事情，而在放棄 kestrel 改用 active-mq 後，
因為架構不同了，在今天昏昏欲睡的情況下... zzzz.....

總之原本我是希望可以做成依照優先順序取得 job,
這樣忙碌的時候可以讓最低優先的 job 完全不做。

而 active-mq 搭配 ruby stomp, 似乎是沒辦法做這件事，
因為他用 blocking i/o, 對 socket 直接用 gets.
雖然我是有在想要不要用 IO.select 重寫... 但這真的要三思 XD

另一方面則是先不要想變成等 job 會造成哪些麻煩事，
原本一直 check 的作法對嗎？或許這也是 trade off 吧？
因為原本的作法變成如果 queue 本身是空的，那 client
就會一直對 server 做 request, 目前是 sleep 0.2, 或許應該改高，
but it doesn't matter anymore...

也就是說，原本這種作法，對於 worker 不忙碌的狀況下，
是浪費多餘資源在詢問是否有 job 的。反過來說，stomp 這種
server 通知的方式，變成在忙碌的時候是不利的，因為優先權
變得比較難管理。而如果是不忙的情況下，就只是 idle 而已。
而說是比較忙碌下的時候不利，也只是某些 worker 會 idle,
那把他原本的 cpu 資源分配給其他 worker, 那似乎也是很合理的。
除非這邊是跨機器，那資源才沒辦法有效利用。

因此，stomp 這樣的作法變成要考慮 process 與 job 間的分配，
還有機器上的分配。而原本 kestrel 那樣則不用考慮這些，
就是猛丟 worker 就對了，然後要小心不要讓無效請求太多。

仔細想想，stomp 這樣的架構可能才是對的吧 @@
雖然說對 deploy 而言會多出一些麻煩，但也只是浪費到記憶體而已，
如果 idle 的話。再想想完全找不到 kestrel 的資源，
跑起來莫名其妙的問題，還有大多 message queue 都是用 active-mq
那種方式，那到底誰才是對的，或許也是一目瞭然吧？

zzz

我想我最需要的是調整作息，其他問題搞不好都能不用解就解決了...