単純に特定のURLに対してミドルウェアの性能を計測したい場合などには、今でもabやwrk、h2loadのようなシナリオベースではないシンプルなベンチマークはとても有用です。
一方で、最近ではgatlingやtsungといった、豊富な機能やリッチな計測結果を取得できるベンチマークソフトウェアも豊富になってきました。
ただ、例えば、単に「Webサーバのベンチマーク結果をレスポンスタイムの時系列データとして計測したい」時に、僕のようなめんどくさがりの人間はcliで適当にオプションを渡して1回の実行でシュシュシュっと取りたいものですが、それができるツールが見当たらず、うーむ、gatlingやtsuningでやるかなぁとおもっていたところ、なんとApache Bench(ab)で簡単にシュシュシュっとできてしまうことに気づいたのでした。
続きを読むLet’s EncryptやACMEプロトコルによるDV証明書取得の自動化に伴い、証明書の取得と設定が簡単になってきました。
一方で、ACMEをツール化したものが増えるに従って、ACMEってそもそもどういう動きになっているのか、とか、自分たちの用途でどういう使い方がありえるのかとかが余計にわかりにくくなってきており、どこまで自動化できるかもよくわからない場合が多いのではないでしょうか。
続きを読むまずは前回の記事で盛大な誤認をしていたことを訂正しなければなりません。
前回の記事では、高速にリモートホストのポートチェックを3パケットで実現する実装を行うために、RAWソケットとユーザランドの簡易TCPスタックを実装してパケットを放出しましたが、カーネルのTCPスタックによって自動的にRSTパケットが返されるため、RSTパケットが返されるよりもはやくrecvfromしないとSYN+ACKを受け取れないと述べました。
続きを読む以下のエントリは一部誤認が含まれていたので、上記エントリにその旨をまとめましたので御覧ください。
とある事情でミドルウェア上から高速にリモートホストのポートのListenチェックをしたくなりました。ローカルホストのポートであれば、/procやnetlinkなどを使って素早くチェックする方法がありますが、今回は対象がリモートホストなのでソケットでなんとかする必要があります。
そこで、誰もがまず思いつくのは、connect()システムコールによってリモートホストのポートに接続しにいって、connectできればOK、できなければNGと判定する方法があり得るでしょう。（高負荷時に接続できないパターンはListenしていないと判定してよい）
小中高と自分のいた環境には、当時は悔しくて言えなかったけど、勉強についてはもうなんというか圧倒的な才能の差としか言えないような人達が沢山いた。
一緒に同じことをやっていても何もかもが速いし、理解力、そこから出す結果もすごかった。自分が楽しいと思えたことでも、多少の差は埋まってもその圧倒的差を埋めることは到底不可能に感じた。その頃から、ああ、こんなにも違う人達がいるのかをというを日々実感していた気がする。
だから今の僕は、ハッキリ言ってそういう意味で才能は無いだろう。いたって普通だろうという自覚はある。あの時の彼らが自分と同じように今ここにいて、同じ内容をやっていたら到底かなわないだろうと思う。
だから、僕がやれることはたった一つしかないと思っている。それは、自分がやると決めたことをとにかく継続的にやっていく、ただそれだけなのだ。周りを気にせず、一つのことを諦めずやり続け、そこから寄り道することがあったとしても全力で継続的に寄り道する。すると、玉ねぎの形のようなイメージで、下の芯からはじめた様々な寄り道が膨らみながら、芯の先でまた繋がり大きな実となる時が来る。芯が通ったその実がもたらす価値は線の繋がりとは比べ物にならないほどに自分に進化をもたらす。
人が持つ時間は一握りだ。だから僕は寄り道も含めて、やろうと決めたことをとにかく継続的にやり続けることに時間を使い続けるしかない。そうすると、そうやって思うがままに取り組んできたことが一つぐらいは実(身)になるかもしれない。それが自分だけのスタイル、自分だけの才能を作り上げることにもなるのだろう。
実はとても難しいことなのである。
上記エントリで述べた通り、僕は結局コードを書き、コンピュータサイエンスを学び、フィードバックを頂きながら試行錯誤してOSSを作り続けることが好きで楽しいからずっと続けられているといった。でもそれは決して、好きなことだから楽に人生を過ごしてこれたというわけではない。好きなことだから仕事が楽であるわけでもない。
好きなことをして生きていくために、僕は大学の時から自分のキャリアを明確に定め、企業に就職した後に、そこで得た社内の評価、そして、毎月の給料を全て捨て、大学院の博士課程に飛び込んだ。その上、最初は審査で不合格になっている。なぜそれができたのか。それは、好きなことをして生きていきたいからだ。以前、その人生をキャリア・キーノートとしてまとめた。
技術者と研究者の狭間で得たたったひとつの教訓 2016 / career-keynote-2016 // Speaker Deck
好きなことをして生きていく。それは言いかえれば、自分の好きなことによって与える自分以外への影響とその価値を最大化することである。好きなことをすることで、身近な人が幸せになり、お世話になっている人々、そして、コミュニティや組織が幸せになり、自分自身もそこで得られる報酬によって生かされている。好きなことをして生きていくこととは、試行錯誤しながら、その道を模索し、学び、行動し続けることにある。時には、好きなことをするために、好きなこと以上に別のことをやらなければいけない時もあるだろう。でも、好きであるからこそ、情熱を持って行動できるであろうし、好きなことをして生きていく道を見つけられるかもしれないということを以前まとめた。
好きなことをして生きていくことはとても難しいと冒頭で言った。しかし、もし、幸運にも人生の中でその道を見つけることができたのであれば、自然と自分の生産性を最大化可能な生活が得られ、最後にはきっと幸せが待っているだろうと思う。是非ともそういう人達が増えることを願う。自分は何をやりたいのか、それを忘れてはいけない。
確かに、自分が欲しいもの・他者が必要とするものを作りたい、とか、承認欲求を満たしたい、エンジニア・研究者のアピールとして、とかあるんだけど、それらはやっぱりあくまで付加的な理由であって、僕にとっての一番の理由であり根源的な理由は、「面白いから」である。ただそれだけ。誰にも邪魔されない唯一の感情でもある。
コードを書いたり、コードを書くために腕組んで考えたり、他者からのフィードバックを経て試行錯誤しながらOSSを育てていったりすることがとにかく面白いと感じるし、その感覚がこれまでずっと長い間続いている。だからこそ、夜遅くなっても、眠くてしんどくても、なかなかすぐには手を止められないし、明日の用事と向き合いながら、あと少し、4時間寝たらいける、あと少し、と引き伸ばし続け、いずれ朝を迎えてしまう。きっと僕は死ぬまでOSSを書き続けるだろうと思う。
コードを書くことは、きっかけは業務だったり、自分の思いつきだったりするけれど、コードを書いているうちにふと気づくと、書いている行為そのものを楽しんでいる。徐々に形になって動きそうな雰囲気が出てきて、やがて不完全ながら動く、そしてエラーを取り除いて初めて想定通り動く、その過程がとにかく楽しい。それを公開して、フィードバックを受けてまたコードを書いて同じ過程を経ていくのも同様に楽しい。面白い。仮に他の諸々の付加的な理由が失われたとしても、面白いと思える感情は恐らく相当の時間変わらないだろうから、きっと僕にとってのゲームと同様、ずっとやり続けられるだろうと思っている。
学ぶこと、それをもとにコードを書いて思いを形にすること、それらはとにかく僕にとって最高の娯楽である。
