Rust で Windows のパフォーマンスカウンターをとってみる

前回作った車輪の再発明!! 言い訳はしない!

GitHub - ROki1988/perf_client

色々頑張った結果…

fn main() {
    let path_list = vec!["\\Memory\\Available Mbytes"];

    if let Some(pdhc) = PdhController::new(path_list) {

        let m = pdhc.current_values();

        println!("{:?}", m);
    }
}

main 関数がこうなりました。だーいぶ隠せたかな?

大まかな流れ

とりたいメトリクスの PATH 配列を入力として、カウンター取得のための構造体を作成。
current_values() を呼び出すたびにそのタイミングでの値が Vec で返ってくる寸法。
PDH_HQUERY の開放も、 PdhController がスコープ外になって消えるタイミングでやるように trait を実装。

改善すべき点

• 一番最初の HCOUNTER 取得から PdhController 生成の部分が胡散臭い。
• PATH の部分を文字列でなく PDH_COUNTER_PATH_ELEMENTS の wrapper なりにすれば、もうちょい使いやすくなるかも。
• 値を返すのでなく、値を順繰りとれる iter は実装中。

iter ができたら、送信部分つくってみるかー

OOP の勉強がてら Windows の Graphite クライアント書いた

動機

Windows のパフォーマンス計測をしたかったのです。
で、クライアントの計測なので、ランタイムインストールはよけたい所でもあったのです。
インストールする物が多かったり大きかったりすると、協力して貰いにくく…

C# 製の↓のがあったんで展開してみたわけです。
CryptonZylog/carbonator: Windows service that collects performance counters and reports metrics to a Graphite server

結果、CPU 使用率が 5% とかで、思った以上にくってたんですよ。

OOP とか色々勉強したけど、素振りばっかだなーってこともあったので、書きました。

ROki1988/PerfSrv

お仕事の環境と同じ、Delphi で書きました。
Rust で書こうとも思ったんですが、まず Windows の API 定義からだったので、とりあえず後回し。

何かちょうど良い感じのブログ があったので、ここで計測していた23個のメトリクスで負荷計測。
取得周期は 1 秒毎。

結果

• CPU 使用率: 0.05%
• メモリ使用量(ワーキングセット): 15MB
• ディスク IO: 0
• ネットワークIO: 1KB/s

ディスクは書いてないですからね。そらそうだ。
結構かるい? と思ってます。
この辺は Rust や Golang の勉強を兼ねて作ってみて、比較できるようにしたいです。
需要が何処にあるかは定かでないですが。

動作確認等々

ローカルの動作確認では、下のアプリを使用しました。
Packet Sender - The Free UDP and TCP Network Test Utility

で、本番との接続は下のサービスを使用しました。

Hosted Graphite - Graphite and StatsD as a service, Grafana and Alertinghttps://t.co/Upk5uKZOm6

ここであそんでる

— rohki (@r_ohki) September 3, 2016

環境もっかい構築とか苦行ですし。

ただ…

社内で動かないという･･･
どーもネットワーク関係っぽいんですが、特定には至らず。
Hosted Graphite に繋がってよっしゃーとおもったらこのざまですよ。

(追記)Graphite の UDP 受信がデフォルト OFF のままだっただけでした orz

上は特定して直すとして、さらに色々粗々なので、直します。名前とか、設定ファイルとか。
OOP 的にもっと整理できそうですし、テストコードとかもちゃんと書かないとです。

OOP の話

は、土曜日にとっときます。話すネタがなくなる!!

rad-studio-osaka.connpass.com

Rust + Windows でウィンドウタイトルとかとってみる

なにしてんねん

社会人生活4年目で、Windows に染まりきってしまいました･･･
ShellScript で GCC ビルドをしていたあの頃にはもう･･･

さて

Rust をこのごろ触ってます。
で、Windows でも API がちょろっとあったので、試しにやってみました。

ROki1988/active_window_logger

で、僕的に おー と思ったのが、この部分。

    let mut title = vec![ 0u16; (length + 1) as usize ];
    unsafe {
        user32::GetWindowTextW(whdl, title.as_mut_ptr(), length + 1);
    }

unsafe 何ていうから malloc/free なのかなーなんて思ってたんですが、するっと確保出来ました。
言われてみれば、たしかになー。頭固かった。
mut vec! の as_mut_ptr() を返せば、変更可能なメモリ領域ですよ。
僕みたいな API べたべた触る人間にはありがたい限りです。

つぎー

構造体がサンプルの哲学者ぐらいでしか書いてないので、そろそろちゃんと書きます。
trait とかもまだ。
構造体配列をとってきてとかも面白そうですね。

Lifetime? HAHAHA!

参考 URL

• RustとWindowsのワイド文字列（LPCWSTR / LPWSTR） | d.sunnyone.org
• klutzy/rust-windows: work-in-progress Win32/Win64 wrapper for Rust (INACTIVE PROJECT: has no proper goal right now)

トラックボール生活 -1週目-

Bash on Windows の流行にのれてない rohki です。
試す時間が･･･

ELECOM マウス トラックボール 有線 6ボタン ブラック M-XT3URBK

さて、使っていたマウスがなにやら不良になってきたので、上のトラックボールを購入してみました。
ので、使用感等々を書いてみます。

良かった点

• 肘がいたくならない
• 握りが良い感じ
• ボール転がすって結構気持ちいい

下2つについては、メリットというより感覚ですけど、こと毎日使う道具だからこの辺の直感は大事な気がします。

悪かった点

• 細かい操作に慣れるまで大変
• 戻るボタンが押しづらい
• 1週間たってボールが引っかかるようになった

細かい操作については、慣れの問題ですから良いんです。どうにかなってきました。
が、1番下がきつい･･･
さっきの感覚の話で言うなら、操作したのにカーソルが動いてくれないので、イラッとするんです。
ボールを代えるなり何なりで対策する予定。

ボールの引っかかりがどうにかなれば、おおむねよい買い物でした。
どうにかせねば。

ややこしい COM とスレッドの初期化(?)をコードにする

Windows に相も変わらずどっぷりの rohki です。

Windows には COM という便利な、便利な仕組みがあります。

この COM とスレッドが絡むと、アパートメントという仕組みが出てきます。
COM ライブラリを初期化する (Windows)
上記を参照すると、以下のように使い分けるとよい、とのこと。

• スレッドでウィンドウを作成するなら、アパートメント スレッド(COINIT_APARTMENTTHREADED)
• 持たないなら、マルチスレッド(COINIT_MULTITHREADED)

まぁ、だいたいはマルチスレッドでしょう。*1
この切り替えは、スレッドに対して CoInitializeEx で設定します。*2

で、これ設定したら CoUninitialize で解除しなきゃなんですが、いちいち気にしたくないです。
なんで、以下のようなクラスを作ってみるとよいかなーって考えてます。

COMUtils

TThread.Execute は final でこのクラス以降で override 出来ないようにして、実質的な処理をかく関数を別に用意する形です。
こうすると利用する人はいちいち気にしなくても良いことになります。

Create に CoInitializeEx を書けば、って僕も一番最初思ったんですが、この設定は先ほどもあげたようにスレッドに対してする必要があるんです。
Create 処理を行うのは当然呼び出し元スレッドなので、生成されたスレッドに設定が適用されないままとなります。
だからわざわざこんなことしてます。

あー、ややこし。

*1:Delphi でフォームを持つと暗黙的に COINIT_APARTMENTTHREADED と聞いた気がしないでもないです

*2:設定なのに Initialize…

プロセスごとの Disk IO がパフォーマンスカウンターの Process からじゃあとれない悲しみ

パフォーマンスカウンターでの性能計測は、テストや開発で行います…よね?
そこでタイトルの話ですよ。

GW 読書強化週間!

の予定だった

GW の間に積み本消化してやるぜ!といきごんでいたのです。
ところがどっこい、読み切れたのは2冊でした。

その紹介と感想をば。

エッセンシャル スクラム

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)

精神的ダメージを多分に負いました。GW 中でなければ読み切れなかった気がしますw
スクラムについてのこうあるべき、なぜなら～をざらっと知れたので読んでよかったかなーって所です。 で、やっぱり3役に求められるスキルセットは各々だいぶちがうな、ってのが明確になりました。
この辺の責任境界はしっかりした方がいいんでしょうね。

あとですね、政治のにほいがそこはかとなく…
というのも、結構なページを割いて、経営レベルでのスクラム的な方法論や組織論への言及があったからです。
この辺のレベル感は DDD でも近しいものがありました。戦術と戦略やったと思います。
スクラムで定義されているのは戦術レベルまでやけど、戦略レベルやってるところも多いし書いとくねーてかんじです。
政治は分からないです。

技術的負債という皆大好きなワードもありました。
かくいう僕もがっつり読んだんですが、考え方は良いなーってところです。 スケジュールを詰めれば、その詰めた分だけの負債をコード上で背負うわけで。 で、利子ついた負債の返済額と遅延コストを比較してどうのってやつです。

いずれにしても、僕自身開発一辺倒な輩なので視点を広げる意味ではよかったです。

闘うプログラマー

闘うプログラマー［新装版］　ビル・ゲイツの野望を担った男達

こいつはだいーぶ積んでましたな。
Windows NT なんてばかでかいもの作ればそらもう紆余曲折あるわけですが、そいつの開発記です。bash on Windows に思いをはせながら読みました。
で、すっごい人間くさい話でした。おそらく、登場人物の誰がしかに自分を重ねるでしょうし、周りの誰かも重なるでしょう。

闘うプログラマー読了

なんかねー、想起させられた。
一番はあれやね、マグリア氏の話。

— rohki (@r_ohki) 2016年5月4日

僕はこうでした。ネタバレになるので、詳細ははしょります。

読んでる途中

数学パズル

自分の劣化具合に愕然としているところ。ちょくちょく解いてます。Rustで。

ﾏﾀﾞﾏﾀﾞｲｯﾊﾟｲ

積み本を整理した結果、いっぱいあるということがわかりました
まる

— rohki (@r_ohki) 2016年5月7日

エッセンシャル スクラムは内容的にも分量的にもきつかたです。 次のときにはうすめの本から手を出します。
ただ、祝日がとおいんだよなぁ…