qrtt1 積分 0

選了啟動程式前設定 TMPDIR 變數,讓 tempfile 產生在適當的位置的做法

qrtt1 積分 0 編輯於

今天寫 python 時試著建了一個 tmp 後,把它用 os.rename 到另一個位置,跨 partition 時竟然就炸了 orz.

qrtt1 積分 2

所以,慢慢有些服務是做 cdn federation(用 multi CDN 為 keyword 就會看到很多),像是 MetaCDN1

qrtt1 積分 5 編輯於

單純以亞洲(不談中國,我們也沒有做中國啊)來看,目前 cloudfront 是每 GB 0.14 美金,GCS 是 0.12,有稍為便宜一點。

VPS 的計價策略是另一個世界,它給的是 1 筆錢,1 個定額的用量內,不會產生額外的費用。以 digitalocean 價目表1 為例,它 10 美金的 plan 可以用 2TB 的傳輸量,換句話說只要我整個月的用量沒超過,那幾乎是等於「網路流量免錢」。

那麼有人會接著問,為什麼不全都使用 VPS 呢?而這種 SSD 套裝的服務,幾乎都不給你擴充硬碟的,只能多租幾台來,但空間有限,快取檔案能存活的日子就少了。

最重要的是品質要顧啊,我們會在 Server 端偵測使用者品質,如果與它當前的載點流速過慢,會試著切換到其他載點。所以,目前是混合著多家的載檔來交替服務。

至於切換的方法還沒有好的計劃,目前是簡單的「工人智慧」,今年有閒的話得想辦法讓它變得「人工智慧」一點,不要像現在是靜態的規則。

PS. 其實國內最便宜是 HiCloud,可是向 S3 抓檔很慢,來不及邊播邊抓快取啊 (然後 OS 超舊,Ubuntu 還在 12.x,要裝 docker 塞 cdn-node service 也很麻煩)

PS. 先前也寫了一篇有關成本的優化2

qrtt1 積分 9 編輯於

目前 3 個主要雲端「存儲與內容遞送」服務在心中的順位為

  • GCS
  • S3/CloudFront
  • Azure Storage/CDN

因為公司有一個產品主要是做 video on demand,客戶大多數在台灣。順序是到客戶端的網路品質來排的,其中 Azure 其實是不知道品質,就先列在最後面。我們一開始只使用 CloudFront 來作為客戶端的主要載點,那個時期犯了一個「先入為主」的錯誤,將 AWS 與品質劃上等號,沒有考慮到台灣網路的特殊環境與 log data。

產品由正式運行後,我在計劃著「成本優化」的事情,試著導入了便宜的 VPS 像是 linode 或 digitalocean 這種等級的供應商,本質上這是一種 performance tuning 的活動,那就規矩的蒐集 log 並將它整理起來存入資料庫讓我們方便能後續分析。

一開始只有針對 VPS 的 access log 資料存入 DB 流程,後來順手也將 CloudFront 的 log 也放入處理,由於被其他任務打斷就只做到將 log 存起來一直放著,就再也沒有人去理過 log 了,除了用來計算某區域的流量之外,它沒有發揮到作為 profiling data 的角色。

在這改變的初期,常被抱怨有些時使用「連線非常不順暢」,又剛好遇上什麼種花海纜又斷了,就先當成是一種「原因(藉口)」。不過,連續幾個星期都出現一個比例的使用者連線品質低落,這實在太不合理了!趁著沒有其他 issue 要解的空檔,先弄個圖出來,至少能將使用者分為三組:極好、佳、劣,能一目了然的圖表,令人感到驚訝的是在免費活動大量使用者湧入的時間,有超過三分之一的被分入「劣」的那一組。

實在無法確定是免費吸引了更多網路品質不佳的使用者,或是我們使用了品質不佳的 VPS?不管問題是什麼,都得解決它。在 Server 端做了個開關,可以決定使用者的載點是以 CloudFront 為主或者 VPS 為主,在下一個活動大量人潮擠進服務的期間,試著切換它 15 分鐘一輪,二種載量輪流服務。單純看出圖的結果,走勢不會因為切換載點而有所變更。所以,能有個簡單的概念:CloudFront 沒有想像中的好,VPS 沒有我們想像中的差。

既然二者在台灣的網路環境中比較起來沒有明顯的差異,就得找第三個服務加入比較,一開始鎖定的是 Azure,可是研究後有二個主要原因無法使用它:

  • private content 還沒有正式釋出 (signed url 的功能過去有放出來一小段時間,後來又被關起來)
  • access log 沒有釋出的時間表(沒有 log 就沒有 profiling data,直接放棄)

那麼,只剩下 GCS 足以成為第 3 人選,為何一開始沒有選擇它呢?這是因為一開始我並不知道 GCS 有 CDN 的效果,直到我在文件上看到 Google Cloud Storage behaves essentially like a Content Delivery Network (CDN) with no work on your part because publicly readable objects are, by default, cached in the Google Cloud Storage network. 才比較有信心能將它當 CDN 使用。

加入了 GCS 後的 log 影響了出圖的比例,連線品質最差的部分大幅減少,這也是為何目前它會排最高的原因。

qrtt1 積分 3

glacier 遲頓到被戲稱「這一定是人工的」

qrtt1 積分 0

嘿壓 150 還可能比星巴克便宜,只是沒有路人可以看。

qrtt1 積分 1

在 create bucket 的介面多了 nearline 可以選了 :)

qrtt1 積分 1

硬大濕應該沒在用 FB 啊,他以 twitter 為主的樣子。

qrtt1 積分 3

另外推薦這本書 金字塔原理:思考、寫作、解決問題的邏輯方法1,它由一份難以被理解的交待事項開頭談文章的結構,並花了許多章節在講解怎麼去安排你的文章、演說,讓它令人容易理解、減少誤會的情況

qrtt1 積分 3

發完了牢騷,回到正題。寫作與說話一樣是種傳達訊息的途徑,別把它看得太過嚴重,已經不再需要考試了。這回至少得練出一種「精確傳達」的技能。

先由反向來想,所謂的精確是「失誤」極少(由多漸少,最終沒有失誤),那麼失誤是什麼情況?說出去的話、寫下的文字與自己打算向接收者傳遞的「概念」有所偏差。偏差常是對「材料」的誤解,像是自己使用了容易誤解的詞語,或對方沒有進入正確的語境。

在日常工作中,有些同事常喜歡用「代名詞」或不精確的「主詞」,像是「這個」「那個」是不是怎麼樣?或是「就跟上次一樣嗎?」這時作為受話者通常就會反問「它」到底是哪一件事,請他具體的舉出來,實事上對方有可能偷懶而省略,為了避免誤會我會再進一步問清楚。

而寫作就比較不會像「言語溝通」這麼糢糊,但仍讀者可能進入不了「情境」的問題,或是進入了誤錯的情境。這多半是段落安排失當所致,常常文章寫完,或投影片做完,試著移動一下前後順序,看能不能看起來更容易理解。

qrtt1 積分 5

有計劃的寫作是需要練習的,不過在我們學習的歷程沒有太大的心力在這上面,倒是學到一些「如何寫出高分作文」的技巧。一是看文意「猜心」只要猜中審閱者的點,那就往高分的一方傾斜;二是選擇行為公式,開門見山、前後呼應、鏡框式結構;三是文字間引用修辭、典故、成語。除了考試技巧,多數的人寫不出實用的文章,例如為自己記錄些什麼事或是抒發當下的心情。想到要寫些什麼,只會聯想起作文的痛苦回憶,如同「說話」課不被重視一般,「誰不會說話呢?」這些養成的「歷程」太著重在單向的表述,沒有仔細思量「做這些動作」的目標。

qrtt1 積分 1

只要我們持續提問,就會有持續深度的回應 xd

qrtt1 積分 0

看起來無法決定,沒有特別開的需求就作罷唄 xd

qrtt1 積分 0 編輯於

就不是閒聊啊.. 不過單純拿求才來說,直接叫 job-description 好了....

qrtt1 積分 0 編輯於

info 消息?或是情報什麼的...

qrtt1 積分 1

回到未來的新任務看來除了回到 1995 年阻止某個語言誕生,看來也得回到 2003 年阻止 groovy 誕生了..

qrtt1 積分 1

因為第 1 份工作就用 diigo1 習慣了,就把 link 丟上去存起來(有時太冷門的 tag 會忘記就是了xd)