熱門Ptt文章

[爆卦]read用法是什麼？優點缺點精華區懶人包

雖然這篇read用法鄉民發文沒有被收入到精華區：在read用法這個話題中，我們另外找到其它相關的精選爆讚文章

在 read用法產品中有93篇Facebook貼文，粉絲數超過2,850的網紅矽谷牛的耕田筆記，也在其Facebook貼文中提到， ref: https://medium.com/swlh/quick-fix-sharing-persistent-disks-on-multiple-nodes-in-kubernetes-ef5541fd8376 這篇文章是 kubernetes 與 Storage 整合的經驗分享文，該文章包...

　同時也有13部Youtube影片，追蹤數超過11萬的網紅吉娜英文，也在其Youtube影片中提到，#歡迎分享你學到什麼用法 #吉娜生活英文實用句 輕鬆背5000單字會員課程 打字背單字課程 http://www.wordsgo-members.com/ 輕鬆背5000英文單字影片 如何快速背單字 https://youtu.be/wypSE6WTeBU 加入吉娜英文FB 粉絲頁 學習更多...

「read用法」的推薦目錄

read用法 在 Sherrie Yuu |美妝護膚✨コスメ?beauty? Instagram 的最讚貼文

2021-08-18 21:32:38

口罩妝容必備❣️持久不脫色＆具保濕力的唇彩🙆‍♀️（日本語レビューあり・English version⬇️） 𝗖𝗛𝗔𝗡𝗘𝗟 𝗟𝗘 𝗥𝗢𝗨𝗚𝗘 𝗗𝗨𝗢 𝗨𝗟𝗧𝗥𝗔 𝗧𝗘𝗡𝗨𝗘 𝗨𝗟𝗧𝗥𝗔 𝗪𝗘𝗔𝗥 𝗟𝗜𝗤𝗨𝗜𝗗 𝗟𝗜𝗣 𝗖𝗢𝗟𝗢𝗨𝗥 𝟰𝟴 𝗦𝗼𝗳𝘁 𝗥𝗼𝘀𝗲🌹 . ♡2 in 1的產品🙆‍♀️高顯色...

read用法 在 范范愛分享 Instagram 的最佳貼文

2020-09-07 19:30:57

雖然蛋黃酥大家都吃過， 但最近我發現一家蛋黃酥是很特別的， #如邑堂餅家 #餡金流蛋黃酥 是 #台灣唯一蟬聯五屆全國太陽餅冠軍 餅皮是使用法式鬆軟餅皮、內餡還有 #鹹鴨蛋奶皇流沙， 濃郁鬆軟的口感， 甜度降低55% ， 讓人享受美味少負擔 #主打減糖、高品質食材， 讓人食用起來更安...

read用法 在 與芬尼學英語 Finnie's Language Arts Instagram 的最佳貼文

2020-05-02 14:30:08

【文章重溫：要寫好文章，第一步是取材】  ✴️ 有興趣看我寫的其他文章，緊記在 Medium 上 Follow 我，多給Claps，支持我繼續寫作！✴️⁣  有學生請教我，話自己英文唔算差，文法與大多數情況下都用得唔啱，唯獨是寫作嘅時候諗埋idea、諗vocab，諗得非常之慢。就算諗到一篇...

  • 矽谷牛的耕田筆記

    read用法 在 矽谷牛的耕田筆記 Facebook 的精選貼文

    2021-07-29 08:01:11
    有 48 人按讚

    ref: https://medium.com/swlh/quick-fix-sharing-persistent-disks-on-multiple-nodes-in-kubernetes-ef5541fd8376

    這篇文章是 kubernetes 與 Storage 整合的經驗分享文，該文章包括了下列內容
    Cloud Storage, NFS, Kubernetes, PV/PVC.

    Kubernetes 內針對這些儲存相關的使用方式有
    1. 使用 ephemeral 的儲存設備
    ephemeral 只適合暫存資料使用，因為該儲存設備不是持久保存的，這意味 Container 如果重啟，資料就會消失。
    2. 使用 Bind Mount 的方式將資料從節點掛載到容器中
    就如同過往使用 Docker 時會使用 -v 的方式將同節點中的儲存目錄給掛載到容器中來使用。

    基本上有任何永久性儲存的需求都會採用(2) 這個方式來處理，而目前很多 Cloud Provider 都有提供相關的儲存裝置讓你的 VM(k8s Node)
    可以輕鬆存取與使用。

    舉例來說，AWS 有 EBS， GCP 有 GPD，這類型的 Block Storage Device 本身支援動態掛載與卸載，所以就算 Kubernetes 將目標 Container 重新部署到
    不同節點上也不需要擔心資料會不同，因為這些 Storage 可以隨者不同節點動態掛載上去，讓你的 Container 看到相同的資料。
    但是以上兩個裝置都有一個限制，就是並不支援同時多人寫入的動作，於 Kubernetes 只能使用 Read/Write 模式。
    這意味每個 Storage 同時只能有一個 Container 去進行讀寫操作(but Azure 的服務就沒有這個限制)

    作者假設今天有一個服務底層是由三個元件組成，這些元件會需要針對相同一個資料集一起處理。
    舉例來說有服務 A,B,C
    A: 將資料寫入到儲存系統中
    B: 從儲存系統中讀入資料進行二次處理，處理完畢再寫回去儲存系統中
    C: 將資料從儲存系統中讀出並且供外部使用

    上述情境簡單說就是一個儲存設備，會有三個服務同時想要讀取，一個專心寫，一個同時讀寫，一個專心讀。
    這種需求就沒有辦法單純使用 EBS/GPD等裝置來使用，因此作者接下來就會針對如何使用 NFS 這套網路儲存系統來搭建一個符合上述需求的用法。
    該解決方案流程如下
    1) 透過 EBS/GPD 的方式掛載一個儲存空間到 k8s 節點中
    2) 部署一個 NFS Server 的容器到 Kubernetes 中，該 NFS Server 會使用 EBS/GPD 作為其儲存空間的來源
    3) NFS Server 透過 service 分享服務
    4) 部署 PV/PVC 物件到 Kubernetes 中
    5) A,B,C 三種容器透過 PVC 的方式來存取 NFS Server

    因為 NFS 本身就是一個可多重讀寫的解決方案，作者透過這種方式讓多個應用程式可以同時讀寫，同時將這些資料保存到 EBS/GPD 的儲存空間中。
    不過這種用法帶來的問題可能就是速度問題，從同節點直接存取變成透過網路存取，所以如果本身對於存取有非常高的頻寬需求時，使用這種解決方案也許會遇到
    很難解決的瓶頸，畢竟大部分人的 k8s 叢集都是 data/control 兩種資料交雜於底層的網路架構中，沒有辦法將 data plane/control plane 給分開來。

    有興趣看作者如何一步一步搞定上述流程的可以參考全文

  • Hapa Eikaiwa

    read用法 在 Hapa Eikaiwa Facebook 的精選貼文

    2021-07-03 11:30:50
    有 81 人按讚

    =================================
    すぐに使える「Kind of」の便利な用法
    =================================
    　
    「Kind of」を「〜の種類」と覚えている人は大勢いると思います。決して間違いではないのですが、この「kind of」という表現は、それ以外の意味としてもネイティブの会話では頻繁に用いられていることはご存知ですか？今回ご紹介する用法は、誰でも簡単に身につけられるはずなので、是非マスターしちゃいましょう！
    　
    　
    --------------------------------------------------
    1) What kind of food do you like?
    →「どんな（種類の）食べ物が好き？」
    --------------------------------------------------
    　
    「What kind of _____?」は、「どんなビールが好きなの？」「どんな音楽を聴くの？」「どんなドレッシングがあるんですか？」など、人に何かの種類を訪ねる定番の質問の仕方です。スモールトークでよく使われ、会話を切り出す時や話題作りとしても使えます。
    　
    ✔その他、馬鹿げた質問や意味不明な質問に対して「What kind of question is that?（どういう質問だよ、それ？）」のように、イラッとしたり呆れたりする場合、もしくは皮肉の意味合いを込めて用いる場合もある。日本語でも用いられるパターンだが、話し手の声のトーンなどから判断する必要がある。
    　
    ✔日常会話では“Kind of”を“Kinda”と発音することが一般的。
    　
    ＜例文＞
    　
    What kind of books do you like to read?
    （どんな本を読むのが好きなの？）
    　
    What kind of cat is that?
    （あの猫って、どんな猫なの？）
    　
    You didn't help your student? What kind of teacher are you?
    （生徒の手伝いをしてあげへんかったんかいな？自分、なんちゅう先生やねん！）
    　
    　
    --------------------------------------------------
    2) I'm kind of hungry.
    →「ちょっとお腹が空いた」
    --------------------------------------------------
    　
    「I'm hungry.（お腹がへった）」を「I'm kind of hungry.（ちょっとお腹がへった）」と言うように、自分の発言を断定的に言うのではなく、微妙で曖昧なニュアンスにする役目として“kind of”を用いるパターンです。例えば、「ちょっと疲れた」は「I'm kind of tired.」、「今日はちょっと暑いね」は「It's kind of hot today.」という具合に使います。
    　
    ✔日常会話では、何かしらの質問に対して「Kind of」と一言で返答することもよくある。例えば、「Are you busy tomorrow morning?（明日の朝は忙しい？）」に対し「Kind of（多少ね）」と言ったり、「Did you have fun last night?（昨晩は楽しんだ？）」に対し「Kind of（ぼちぼちね）」などと言ったりする。
    　
    ✔この用法は、アメリカ人がよく使う傾向がある。
    　
    ＜例文＞
    　
    I'm kind of excited but nervous at the same time.
    ちょっとワクワクしているのと同時に、それなりに緊張もしてるよ。）
    　
    I kind of like this song. Who sings it?
    （この曲ちょっと好きかも。誰が歌っているの？）
    　
    He's kind of a jerk. He always makes fun of people.
    （彼はわりと嫌な奴やで。いっつも人のことをおちょくるしな。）
    　
    　
    --------------------------------------------------
    3) It tastes kind of like chicken.
    →「鶏肉のような味がする」
    --------------------------------------------------
    　
    “kind of like”は、何かを説明するときに「〜のような」や「〜みたいな感じ」など、“それらしい様”を表現する場合に用いられます。例えば、日本へ行ったことのない友達に、東京がどんな場所かを説明するときに「It's kind of like New York.（ニューヨークみたいな感じだよ）」と言うことができます。
    　
    ✔この用法は、アメリカ人がよく使う傾向がある。
    　
    ＜例文＞
    　
    "Manga Kissa" is kind of like a cafe where you can read manga.
    （漫画喫茶は、漫画が読めるカフェのような場所です。）
    　
    What's Snapchat? Is it kind of like Instagram?
    （スナップチャットって何？インスタみたいな感じ？）
    　
    "Okonomiyaki" is kind of like a pancake.
    （お好み焼きは、パンケーキみたいなもんやで。）
    　
    　
    --------------------------------------------------
    4) This is my kind of music.
    →「これが私の好きな類いの音楽です」
    --------------------------------------------------
    　
    “My kind of”は「私の好きな類いの〜」と訳すことができ、自分の好みのタイプや種類などを示す場合に使われます。人や場所、音楽など対してよく用いられ、口語的な表現になります。例えば、友達にジャズの生演奏が楽しめる、いい雰囲気のバーに連れて行ってもらったときに、「This is my kind of bar.（私はこういう感じのバーが好きです。）」と言うことができます。
    　
    ＜例文＞
    　
    This is my kind of weather. I love LA!
    （こういう天候、好っきやわ〜。ロス最高！）
    　
    She's really nice but not my kind of girl.
    （彼女はとても優しい子だけど、僕のタイプじゃないんだよね。）
    　
    I love to make no plans when I travel. That's my kind of vacation.
    （私は予定を立てずに行く旅行が好きです。そういう旅行が私の好みです。）
    　
    　
    　
    　
    　
    ブログ記事URL：https://hapaeikaiwa.com/?p=11518
    ～～～～～～～～～～～～～～～～～～～
    　
    無料メルマガ『1日1フレーズ！生英語』配信中！
    　
    通勤・通学などのちょとした合間を利用して英語が学べるメルマガ『1日1フレーズ！生英語』を平日の毎朝6時に配信中！ただ単にフレーズを紹介しているだけではなく、音声を使った学習プロセスが組み込まれているので、メルマガを読むこと自体が学習方法！
    　
    https://hapaeikaiwa.com/mailmagazine/
    　
    ～～～～～～～～～～～～～～～～～～～

  • 矽谷牛的耕田筆記

    read用法 在 矽谷牛的耕田筆記 Facebook 的最佳貼文

    2021-06-14 08:07:47
    有 198 人按讚

    本篇文章是個經驗談，作者想要聊聊是如何將一個 4vCPU 的VM給調整到可以達到每秒處理 1.2M(120萬)個 JSON Reuqest，本篇文章非常的長，所以會分多天來介紹。

    整篇文章探討的是各種 turning 的步驟，來聊聊如何從最初每秒 224k(22萬四千) 給調整到每秒 1.2M 的處理能力。

    整個過程分成九大步驟，後面同時標示每個過程後的每秒請求能力
    1. Application Optimizations (347k)
    2. Speculative Execution Migtigations (446k)
    3. Syscall Auditing/Blocking (495k)
    4. Disabling iptables/netfilter (603k)
    5. Perfect Locality (834k)
    6. Interrypt Optimizations (1.06M)
    7. The Case of the Nosy Neighbor (1.12M)
    8. The Battle Against the Spin Lock (1.15M)
    9. This Gost to Twelv (1.20M)

    作者強調，上述的過程不一定適合你的應用程式，但是透過這些步驟能夠讓你更佳瞭解應用程式的運作行為，同時也有機會發現一些潛在的瓶頸問題。

    環境介紹
    1. 團隊使用 Techempower 來進行 JSON Serialization 的測試
    2. 使用 libreactor(event-driven框架) 來搭建一個簡單的 API Server
    3. HTTP 的解析使用 picohttpparser，同時使用 libclo 來處理 JSON 的編碼
    4. 硬體環境
    - Server: 4 vCPU, c5n.xlarge AWS VM
    - Client: 16 vCPU, c5n.4xlarge AWS VM (clinet太弱會變成瓶頸)
    - Network: Server/Client 屬於同一個可用區域(AZ)
    5. 軟體環境
    - 作業系統: Amazon Linux2 (Kernel 4.14)
    - Server: 使用 libreactor (使用不同版本，分別是 Round18 以及 Round20)
    - Client: 修改 wrk 這個知名的工具並重新命名為 twrk，詳細差異自己看文章內部，主要都跟顯示有關
    6. 實驗方式
    - 每個測試跑三次，取中間值
    - 256 連線，16 threads，同時每個 thread 都會 pin 到一個固定的 CPU
    - 每個實驗都有兩秒的暖機時間來建立連線


    Ground Zero
    第一個要探討的就是什麼最佳化都還沒有使用前，到底當前應用程式可能的瓶頸在哪裏
    首先團隊將該應用程式與其他常見的應用程式或是開發框架比較，譬如 Netty, Nginx, Actix, aspcore 等， libreactor 的效能不錯，有中上水準。

    接者作者使用火焰圖(Flame Graphs)來 Profile 該伺服器，作者很好心地將文章中所有的火焰圖都調整了一下，讓所有的 user-space 相關的 function call 都轉成藍色，而剩下跟 kernel 相關都維持紅色。
    1. 大部分的時間都在 Kernel 處理
    2. 主要是花費在收封包與送封包
    3. 應用程式本身主要是分兩大部分，解析 HTTP 的封包以及處理請求與回應。
    從上述兩點來看，作者認為目前的應用程式寫得算不錯，因為瓶頸很明顯是卡在 Kernel 端

    接下來就正式進入到各種 Turning 的章節探討

    Application Optimizations

    長話短說:
    - 作者基於 libreactor Round18 的框架進行修改，並且所有的修改都已經被合併到 Round20 的版本中，而這些修改主要是實作方面的強化以及整個框架的最佳化。

    1. 作者首先透過 htop 觀察運行過程，發現 Server 只有使用 2vCPU 而已(系統有 4vCPU)，因此這是作者進行的第一個修改，讓 Server 使用了 4vCPU，這個簡單調整就讓效能提升 25%

    註: 作者特別強調，不要覺得從 2vCPU 變成 4vCPU 效能就可以變成兩倍，主要是1) 沒有使用的 vCPU 還有很多其他的工作要處理，因此不是完全都送給你應用程式處理。2)基於 hypter-thread vCPU 的架構，環境只有兩個真正的 CPU 而是透過邏輯的方式產生四個抽象的 CPU，所以全用一定會變快，但是基於很多資源還是要競爭與共用，數字不是單純翻倍

    2. 作者自己的應用程式本身使用 gcc 建置時有使用 "-o3" 的方式來最佳化處理，然而框架本身卻沒有使用 "-o3" 的方式來弄，因此作者也針對這個部分來處理，讓建制框架時能夠使用 -o3
    3. 從實作方面來看，作者觀察到 libreactor 1.0 版本使用的是 read/write 這兩個常見的方式來處理封包的送收，作者將其修改成 recv/send 整個效能就提升了將近 10%。

    註: write(針對 FD，更全面廣泛的用法) 與 send(針對 Socket，更針對的用法) 使用上差異不大，但是 write 於底層 Kernel 最終還是會呼叫到 send 來處理，所以基本上可以理解就是在沒有特別參數需求時，可以直接跳過幾個 kernel function 來達到加速的效果。

    write kernel 內的走向: sys_write -> vfs_write -> __vfs_write -> sock_write_iter -> sock_sendmsg

    send kernel 內的走向: sendto -> sock_sendmsg

    4. 作者觀察到火焰圖中有一些 pthread 相關的資料，進而發現 libreactor 會創造一個 thread pool 來處理非同步的 DNS 名稱解析問題。對於一個 HTTP Client 來說，如果今天要發送請求到多個不同的 domain，而每個 domain 都會需要進行一個 blocking 的解析過程，透過這種方式可以減少 DNS 解析造成的 blocking 問題。然而對於 HTTP Server 來說，這個使用情境帶來的效益似乎就稍微低了些，畢竟 Server 只有 Bind Socket 之前可能會需要去解析一次 DNS 而已。
    大部分的情境下， thread pool 都是應用程式初期會去創造而接者就不太會管她，但是對於錙銖必較的效能除錯人來說，任何能夠調整的部分都可能是個值得探討的地方。
    作者透過修改 Server 端(準確來說是 libreactor 框架內的程式碼)關於 Thread Pool 的一些用法，成長的讓整個效能提升了 2~3%

    結論來說，透過上述四個概念來提升的程式碼效能。
    1. vCPU 盡量使用: 25%-27%
    2. 使用 gcc -O3 來建置框架的程式碼: 5%-10%
    3. 使用 march=native 等參數來建置最後的 server 應用程式: 5%-10%
    4. 使用 send/recv 而非 write/read: 5%-10%
    5. 修改 pthread 的用法: 2%-3%

    註: 作者強調每個最佳化的結果並非是單純累積的概念，反而還會有互補的效果。
    可能前述的操作實際上也會讓後續的操作達到更好的效果，
    譬如如果先跑 vCPU 的調整，效能大概提升 25%，但是如果先執行別的最佳化過程，最後再來調整 vCPU，就可以達到 40% 的效果，主要是 CPU 可以共有效率的去執行程式。

    最後，這個部分讓整個處理封包能力從 224k 提升了 55% 到 347k (req/s)。
    從火焰圖來看，整個 user-space 的範圍縮小許多，同時 send/recv 的處理也有使得整體的高度下降一點點(大概四格..)

    為了避免文章過長，本篇文章就探討第一個最佳化的過程，剩下的就敬請期待後續!

    https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/

你可能也想看看

搜尋相關網站