昨日晚餐：「胡同裡的蘭」。
「orchid restaurant 蘭」與「胡同燒肉」合作的新餐廳。法菜與燒肉的難得跨界之合，尤其素來欣賞的 Nobu 主廚那般對食材的精準直觀、思維手法兼容各地四方，表現於燒肉上會是什麼樣？讓人分外興味盎然。沒料到還沒來得及登門，便碰上三級警戒餐飲內用全停，直捱到此刻才終於一訪。
菜色以套餐方式呈現，形構與盛盤為法式，但技法與風味遊走兩方。其中，結合較緊密的，如以炭火烤出燻氣與甘甜、佐搭柚子山葵油醋汁的溫野菜沙拉，炙烤天使紅蝦佐手指檸檬蝦油美乃滋，簡簡單單，卻以風味質地紛呈的法風醬汁襯托高明火烤食材之美，很是對味。
海膽干貝蝦多士與皮蛋四季豆牛舌則形貌神髓都更偏法式，前者以澄清奶油酥炸吐司夾蝦肉餡並點綴生海膽，後者以耗時兩日先醃漬再低溫燉煮的牛舌搭配韓式辣醬調味的四季豆、皮蛋與香菜苗，口感與味道層疊豐富多端，穿插套餐中，簡與繁交錯相映，自成趣味。收尾的湯泡飯也有變化：三種蕈菇以和牛油炒，淋入牛高湯後，蕈與牛之鮮之香芳馥交織，熱騰騰暖味暖胃美好句點。
很有意思的橫跨國界與料理別的攜手聯彈，據說十月後還會換菜單，期待更多更緊密更活潑的交融與撞擊火花。
※ 更多外食分享 https://goo.gl/UJJNUf
nobu意思 在 [閒聊] kk 的onyx 寫的文章- 看板mud_sanc - 批踢踢實業坊 的八卦
出處
https://blog.csdn.net/mu_gong/archive/2005/02/19/293246.aspx
節錄其中幾段..
第一次嘗試這種類型的Mud，並沒有想到會如此受歡迎。在不到一年的時間，
甚至許多功能都尚未完成的時候，不停的有新人加入這個遊戲空間。原來是
不希望設上限人數的，我們希望 :「想玩就可以來玩。」。但是人數一再增
加，整個系統慢了下來，於是我們不停的嘗試各種方法來提高人數上限，包
括改寫Mud library、更換硬體、更新MudOS版本、修改linux kernel以突破
file descriptor上限256的限制等等。
聖殿以前人數常卡在 24x(不含 logon) 的原因應該是最後一個，其它該做
的大概都做了，大抵上人數不斷提高時，會遇到的問題以及初步會採取的做
法都大同小異。
改寫 mud library: Int、Satin 時期改寫過一次，nobu、myst 時期聽說又
改寫一次，nobu、laechan 時期則以最佳化為主。
更換硬體: 其實可以換成雙核心的 machine，nobu 的意思是雙核心對跑mud
在效能上助益不大，目前的主機是 P4。
更新 MudOS 版本: 目前的版本算蠻新的，將來考慮換成某一版可支援多port
登入的(啊，目前的不曉得可不可以..)
Mud OS可以看成是一個virtual machine，執行專屬的中間碼。在virtual
machine是single thread的，也就是說一次一定會把一個指令或物件裡的
一個method執行完畢，才輪到下一個。
Mud 需要處理以下三件事情 :
1. 每隔固定的間隔時間必須執行的 : 比如說每個生物的心跳。
2. call_out queue : 有些指令在執行的時候為了要造成延遲的效果，
會以call_out函數指定過了幾秒後要跳到哪個函數執行，有點像
sleep()。Mud OS會將call_out發出的請求依時間掛在一個queue,
每隔一陣子就去檢查是否到了執行的時間。
3. 使用者下的指令。
為啥要盡量減少 call_out 的使用, 上面有大致的說明. 但實際上目前大
量以其它方式替代 call_out 也會產生問題就是了.
目前的 mudos 不曉得有沒有非 single thread 的處理方式.
整個過程大概可以寫成 :
While (1) {
process_heart_beat(); // 心跳，每兩秒一次
process_call_out(); // call out queue
process_user_command(); // user command
}
response time = 網路傳輸時間(來回) + 執行指令的時間
而
執行指令的時間 = f ( 硬體的速度，virtual machine的效能，
指令本身的複雜度，物件數目，使用者數目)
其中物件的數目受直接受使用者數目的影響，而小心設計可以降低指令的複雜度。
一般情況下 loading 是平穩的, 而人數越多, 經過 process_heart_beat()
時要處理的量就越大.
其它是能省則省了, 像聖殿這樣在戰鬥中要狂按一些指令的情況其實是可以
再更省一點.
另外指令的最佳化也是未來的重點, 特別是常用指令如 heart、go、特攻指
令等.
如何提高人數上限
1. 提升硬體設備 :
a. 使用更快速的CPU
b. 使用高速記憶體與硬碟
這是最簡單的方法了，然而硬體升級的速度比不上進入網路世界的人口成長
，而且如果每次人數飽和就更新機器，將需要一筆可觀的費用。
以目前來說，P4 3.2G / 4G DDR2 800 / SCSI HDD，跑 mud 應該很嗆了,上
述花費大概 20000 以內就搞定, 在 onyx 寫上面文章的時代則是無法想像的
(如果拿 DDR3 的 ram 來插應該會更嗆)
像以聖殿目前主機的等級來看, 跑 3xx 人其實已經不太困難.
2. 加強virtual machine的效能，小心設計library
‥ 現在TAnet上的Mud多半是拿國外的virtual machine(Mud OS, driver)
來使用，使用新版本的virtual machine可以大幅提高執行速度。
‥ 小心設計library，盡量不要設計的太複雜，將最花時間的一些動作與
指令最佳化。
‥ 最佳化library能夠收到的效果有限，往往最多只能增加10~20個使用者。
最佳化的效果其實是很高的, 它的好處就在於更新機器時效果會更顯著,
以及當某一部份的系統檔案出問題時, 整個 mud 即使速度整體被拖慢,
也還能再撐一段時間(例如之前聖殿出現的大 lag 情況, lag 成那樣了,
還可以不 crash 繼續撐)
而且最佳化的過程也可以學習怎麼寫程式來盡量減輕系統的負擔.
onyx 之後的文章就提到了如何架構分散式系統, 簡單的說就是當一部
pentium 200 的主機最多只能跑 250 個玩家, 而 kk 想跑 1000 個玩
家同時在線時, 依 onyx 及 ruby 的說法就是, 只要把四部 pentium
主機「串接」在一起就行了。
(這種想法據說是 onyx 論文的基礎)
但科技真的是日新月異的, 而 mud 則逐漸凋零, 兩條線約在 kk 人數
還有 5xx 的時候交叉, 而以現況來說, kk 經常在線人數 3xx~4xx，一
般家用主機則已經進步到四核心時代...
目前的聖殿不需要搞分散式架構大概可以跑 400 人(我的預估)，超過
時有幾個備用方案..
一、把 user.c 的 heart_beat 最簡化
二、把常用指令最簡化
三、取消一些常用指令的週期性使用方式，改成上線後使用一次即可
四、減少 1 ip 可 login 的角色數
Laechan
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.65.137.33
... <看更多>