#食況轉播 #蘭餐廳
一週前，新北市宣布禁止餐廳內用七天，我大慌。急急去訊Nobu主廚：「明天中午去找你吃飯可以嗎？」
愛要及時，吃飯也是，疫後時代講求當下。踏進「蘭餐廳」，也見到幾張熟面孔，懷抱相同心思的人，不只有我。
五月中疫情升級時，蘭餐廳剛換菜單。恢復內用後，這份菜單重新登場，也因應季節做了微調。非常喜歡開頭一道山羊凝乳，像是鹹的義式奶酪（panna cotta），浸泡過月桂葉的山羊奶揚起木質調的雅香，綻放鮮鹹，文旦與葡萄柚嗶嗶剝剝，粒粒酸亮，還有百合根脆脆的甘甜，在口中既和諧，又醒舌，風味上乘。
另一道新亮相的菜色是胭脂蝦，蝦肉本身用薄鹽醃過，吹彈可破，蝦殼蝦頭則拿去做了澄清湯，質地透明而風味緊緻；更有意思的是配菜，用來幫襯紅蝦濃味的米苔目，是用帕瑪森起司、乳清、雞蛋與在來米米粉製成，像是義大利pastatelli麵條的台灣版，無筋性，而香軟黏糯，和稠而甜的胭脂蝦融為一體，相當有趣。
幾道夏季菜色依舊討喜。厚切花枝帶刀紋，經油封，軟中有彈，酸鮮明朗，酸味一方面來自酸豆水，二方面來自鹽膚木，脆的口感對比則是梅醋漬苦瓜，另以芝麻葉油、金蓮花葉賦予清涼辛嗆；熱燙鬆化的拇指馬鈴薯，點綴以酵母脆片和血腸粉末，也有烤馬鈴薯佐培根與酸奶的趣味；季末的綠竹筍，用米湯煮熟，去殼後再以乾香菇高湯煨煮，嚐得到細肉厚甜，醬汁也是米湯，越光米與昆布高湯的溫柔暖滑，躍現山葵的清新嗆香，簡潔優雅。
主菜是日本F1國產牛紐約客，佐以洋蔥泥醬汁、小青椒、奶油炒菠菜，是中規中矩的一道；真正有趣的是主菜登場前的清口冰沙，洋溢玉米的甜味與香氣，卻不只是玉米，青豆、紅蘿蔔也在場......這是「三色豆的逆襲」！將三者融為一體，隱藏外觀，而釋放香甜，爆米花與鴨肝的冰沙更增添芬芳與鮮味，的確，讓人欣然接受呢。
最後的冬瓜茶甜點，以蘋果、薑、薏仁去襯托冬瓜茶冰淇淋的帶有焦糖味的甜，爽口宜人。
好在，至今一週，疫情未再延燒。可以坐在自己喜歡的餐廳裡吃飯，總是開心的。
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
... <看更多>