システムコールについてどれくらいご存じですか？：知ってトクするシステムコール（1）（1/2 ページ） 「システムコール」と聞いて、どういう印象を受けますか？ 「難しくて、自分では手に負えない」とか「使う必要を感じない」という方は多いでしょう。しかし、コンピュータを使う人ならどんな人でも、システムコールについて知っておくといろいろトクをするんですよ。（編集部） システムコール？ 聞いたことはあるけど…… 企業情報システムや、Webアプリケーション、携帯機器向けアプリケーション、あるいはちょっとしたツールの作成など、なんらかの形でソフトウェア開発に携わったことのある方なら、一度は、「システムコール」という言葉を耳にしたことがあるはずだ。しかし、先に挙げたような分野のアプリケーション開発現場で、明示的にシステムコールを利用する開発者は多くない。 システムコールは、低レベルのプログラミングやカーネ
デブサミ2016登壇資料。サーバ技術の評価軸、HTTP/2、サーバプッシュ、HTTPS化の負荷、Brotli、サーバ内スクリプティングを俯瞰
前方秘匿性（forward secrecy）とは、以下のような性質を指します。 公開鍵暗号の秘密鍵のように、比較的長期に渡って使われる鍵が漏えいしたときでも、それまで通信していた暗号文が解読されないという性質 鍵が漏れることも想定せよ――クラウド時代における「楕円曲線暗号」の必然性 - @IT 鍵が攻撃者や諜報機関など第三者の知るところとなった場合でも、それまで通信していた暗号文が解読されないようにしないといけない、という考え方とともに、最近 HTTPS を利用するウェブサイトにおいても導入が求められるようになってきた概念です。 前方秘匿性を満たすウェブサイトの設定方法については、TLSの暗号化方式をECDH_RSAあるいはECDHE_RSAに設定すれば良い、と述べている文献が多いです。 ですが、ほとんどのウェブサーバにおいて、それは誤りです。 なぜか。 通信を暗号化する鍵（セッション鍵）
先月末の話になりますが、SAPジャパンさんを会場に開催されたデータ転送ミドルウェア勉強会で、私が中心になって開発しているHTTPサーバ「H2O」について話す機会をいただき、登壇してきました。 以下は当日使用したスライドです。なぜ今H2Oを開発しているのか、その背景にある現状認識と将来の方針について、日本語で説明してあるので、興味ある方はご覧ください。 発表の機会をくださった@repeatedlyさんと@frsyukiさん、会場を提供してくださったSAPジャパンさん、ありがとうございました。 H2Oの開発は順調に進んでおり、HTTP/2サーバプッシュへの対応も完了し、まもなく次のバージョンがリリースできるかと思います。今後ともよろしくお願いいたします。
本書のレビューアの方から頂いたので読んでみました。以下、感想です。 詳解 Tomcat 作者: 藤野圭一出版社/メーカー: オライリージャパン発売日: 2014/12/26メディア: 大型本この商品を含むブログを見る 最近、Twitterのタイムラインで『はじめてのXXXや、XXX 入門じゃなくて、もっと至高のXXXとか終焉のXXXみたいな書籍が欲しい』のような意見を目にした気がしますが、本書はまさに詳解Tomcatでした。設定方法を羅列するのではなく、Tomcatはどういくアーキテクチャで成り立っていて、各機能の詳細な挙動はどのような仕様なのかがまとめられています。 1章 Tomcatとは 〜 2章 Tomcatの基本 までは、背景やインストール方法などの色々な書籍で見かける導入部分の内容です。3章 アーキテクチャからが本番です。 Tomcatアーキテクチャの文書化が嬉しい 普段Tomc
“Hello World”なベンチマークでUnicornに比べ2倍高速に動作するRackサーバをリリースしました。 rubygems: http://rubygems.org/gems/rhebok github: https://github.com/kazeburo/rhebok PerlのGazelleをベースに作っています。Rackアプリケーションの運用経験がほぼないので、機能不足があると思います。issue等で教えて頂ければ幸いです。 なぜ高速に動作するアプリケーションサーバが必要なのか Unicornは高速に動作します。多くのアプリケーションにとっては十分でしょう。それでもRhebokでさらに上のパフォーマンスを出そうとしたのは、技術的なチャレンジの他に以下のようなアプリケーションで高速なアプリケーションサーバが必要とされると考えているからです。 ソーシャルゲーム、広告サーバ、
今年の初めくらいから個人的な技術検証にはSSDで動作が速く、1時間1円で料金が安いのと ロケーションをSan Franciscoにするとsshでもレスポンスが悪くないので、全部Digital Oceanを使っている。(徳丸先生が紹介する前から使っていたんだ！) Digital OceanについてはRebuild: 2: Rails, Redis, VPS (Kenn Ejima)の42分くらいから言及されてます。必聴です。 使ってる旧型のMacBookAirみたいな貧弱なマシンだとローカルでVM動かすとファン回りまくりとかで泣きたくなるので、Digital Oceanだと泣かずに済んで快適。 そんで今日Vagrant経由でDigital Ocean利用すると、コマンドラインから必要なときに新規インスタンス(Droplet)作って、 検証終わったら削除という手軽な使い捨て高速サーバ環境が利用
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
学者でもなんでもない現場のいちエンジニアの感想です。しかも、どれもちゃんと使ったことないので、聞きかじりをまとめたメモ書きなので嘘が入ってますが、興味ある方がいればどうぞ。 はじめに かつては「OS=物理サーバ」であって、その物理サーバの資源(CPU,RAM,DISK,etc.)をどのように使うかは OS がプロセスに割り振る形で決定されていました。しかし、それでは例えば以下の様な問題があります。 ファイルシステム資源をプロセスが自由にコントロールできない ProcA と ProcB で使いたい libfoo のバージョンが異なる場合面倒 CPU, RAM 資源もコントロールしにくい 同居してるプロセスがメモリ食い尽くして、みんな死亡、みたいな そもそも異なる OS を同居して使うことができない CentOS ばかり使ってるのに、使いたいライブラリが Debian でしか動かないとか 解決
「Chef! Chef!」と叫ばれる昨今、そのChefに挫折した皆様、いかがお過ごしでしょうか？ Chefに挫折中のid:k1LoWです。 Ansibleいいよ。Ansible。 Chefに挫折したからといってプロビジョニングツールへの憧れは消えるわけもなく、時間を見つけてはいろいろいじっていた時、 同僚からの「Ansibleというツールが良さげらしい」という情報をそのまま鵜呑みにし、PHP Matsuri 2013を通じて使ってみて今に至っています。 Ansibleいいよ。Ansible。 AnsibleはPython製のプロビジョニングツールです。ChefやPuppetと同じ領域のツールですね。 ちなみに、呼び方は、日本語英語的に「あんしぼぉ」です。「あんじぼぉ」でも「あんそぉぼぉ」でもありません。PHP Matsuri 2013でVagrantのMitchell Hashimotoさ
本項はChefConf 2013: Beginner Chef Antipatternsを和訳したものです。 はじめに よく Chefの学習は大変 Chefの学習曲線は急勾配 と言われているので、Opscodeでは緩和するためのコンテンツを色々準備しています。 learnchef.com docs.opscode.com パブリック/プライベート トレーニング Podcasts (Food Fight Show など) 各地のユーザグループ (訳注: 日本なら #opschef_ja ) ChefConf! (訳注: これは ChefConf 2013 で行われたセッションなので) それでも、正しいことをやっているのか知るのは難しく、何か間違ったことをやっているのか知るのはさらに難しいものです。コミュニティの中で「ベストプラクティス」は常に進化してきました。 ベストプラクティスについてもっ
馬鹿でもわかる Application Server と Reverse Proxy Balancer のお付き合いを考える 一般的な Web Application というのはロードバランサ、Webサーバ、アプリケーションサーバという HTTP を喋るサーバで構成されていると思います。 ロードバランサは高級なハードウェアからソフトウェア(lvs, httpd, etc..)で作るものまで色々ありますね。 アプリケーションサーバでは各種言語に合わせた実装でデーモンが常駐してるでしょう。これはいわゆる普通の Web サーバよりは単純なコンテンツを返す性能が低いです。 そんなわけで動的なアプリケーションサーバが有る構成では js や css や画像など静的なファイルは Apache や nginx などの専用の Web サーバでサービスして、動的なリクエストだけバックエンドのアプリケーションを
Monoceros というPSGI/Plackサーバ書きました https://metacpan.org/release/Monoceros https://github.com/kazeburo/Monoceros StarmanやStarletのようなPreforkなアプリケーションサーバでは、コネクションの維持イコールプロセスの占有なので、HTTPのKeepAliveは無効にするのが一般的ですが、負荷の高いサービスではTIME_WAIT状態のソケットが溜まったり、SYN-ACKの再送問題などあり、KeepAliveを使いたいという欲求があったりなかったりします。 Monoceros はリクエストを処理するworkerの他に、イベントドリブンで動くコネクション管理プロセスを立てて、クライアントからの接続ソケットをunix domain socketを使いプロセス間でやりとりします。待機
StarmanとStarletの違いはいくつかありますが、Starletにいくつか手を加えたあと、速度はどうなっているのか比較してみた。 なお、以下の記事はHello Worldのベンチマークなので、実際のアプリケーションのパフォーマンスにはあまり影響がないと思われます。 各ソフトウェアのバージョンは以下。 Plack-1.0023 Starman-0.3008 Starlet-0.18 Starletのベンチマークとほぼ同じアプリケーションを書いてサーバを起動した use Plack::Builder; use Plack::Request; my $length = 12; my $body = 'x'x$length; builder { enable 'AccessLog', logger => sub { }; sub { my $env = shift; my $req = P
「ウェブオペレーションエンジニアはリリース前のソースコードのココを見る！」みたいな記事があればいいね — masahiro nagano (@kazeburo) November 20, 2012 ちょいと前にツイートしたこの件のまとめ。新規サービスのリリースや既存サービスに新しい機能が追加される際に、しばしばそのソースコードを確認しているのですが、僕がどんなところを見ているのかまとめてみました。 そのサービスへの導線とランディングページの確認 まず、そのサービスへの導線やランディングページを確認します。そしてその一番アクセスがあろうページ、一つか二つに確認対象を絞ります — masahiro nagano (@kazeburo) November 20, 2012 どんな素敵なサービスも、機能も適切な誘導がなければ使われる事はありません。また誘導次第では大量のアクセスが一度にサーバに対し
こんにちは検索サービス開発４チームの崔珉秀と申します。 インフラやシステムとの連携や統計のバックエンドを担当しております。 モバイルのウェブ環境はPCのウェブ使用環境とは色々な違いが有ります。 ネットワークの速度だけではなくバッテリーの効率を考えた仕組みなど、PCに比べリソースが十分ではないためモバイルブラウザの動作が異なっていることも有ります。 今回はモバイルのウェブApplicationにおけるSSL関係の性能に関する工夫の内容をQ&A形式で解説していきます。 Q. 何が問題でしたか？ A. モバイルクライアント(iPhone, Android)のアプリケーションからのHTTPリクエストの応答時間に遅延の問題が有ります。 最初はweb access logからのslow response(１秒以上)のHTTPリクエストが結構ありました。 そのHTTPリクエストをprotoc
なんでもありのいい感じにスピードアップコンテスト ISUCON が 2 になって帰ってきたので、参加して優勝を勝ち取ってきました。 まとめ的なものはこちらから livedoor Techブログ : ISUCON チームメンバーのblogも併せてご覧ください。 おそらくはそれさえも平凡な日々: #isucon2 で連覇させてもらってきました Redis布教活動報告 ISUCON 編 - unknownplace.org 今回は前回の ISUCON 優勝メンバーのひとり @sugyan が転職して出題側に回ってしまったので、@typester を招聘してチーム編成。@songmu と共に3人でチーム「fujiwara組」として再参戦です。 以下、作業用IRCのログからふりかえりますと…… 11:39:29 <typester> とりあえずrecent_soldはキャッシュってのはまずやることか
定期実行って、Cronを使ってやるのが一般的ですよね。 エンタープライズシステムだとJP1とか使って管理したりしますが、 それJenkinsで良くない？ というわけで考えて見ました。なんでJenkinsがいいのか。 メリット（cronとの比較）① SVNなどのSCMとの連携が可能 ② メール等のアラートが可能 ③ 実行履歴の確認が容易 デメリット① Jenkinsが落ちたら動かない ただこれはJenkinsの監視やバックアップである程度回避できます。 またJP1 などは大変高価なので、無償で使えるのは嬉しいですね！実際にやってみたまずはSVNに適当なプロジェクトを作って適当なShellスクリプトをコミットしてみます。 SVNはファイル単位でのチェックアウトができないのでGitで管理したほうがいいのかもしれません。 Shellスクリプトは終了コードを明示的に0と書いたほうが良いでしょう。 J
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く