タグ

2016年2月24日のブックマーク (7件)

  • LINEの100億超/日メッセージを支える Redis・HBaseのスケールアウト・アップ戦略 #linedevday - Togetterまとめ

    リンク linedevday.linecorp.com LINE DEVELOPER DAY_2015 Tokyo LINE DEVELOPER DAY_2015 Tokyo is a technical conference in which our teams of engineers share their various experiences and also address open issues. Shunsuke.N A-5 HBaseとRedisを使った100億超/日メッセージを処理するLINEのストレージ HALL A 13:30 - 14:10 "LINEのメッセージングストレージとしての難しい要求に対して、RedisとHBaseを利用してどのように問題を解決してきたかについて紹介します。 最初にLINEでのストレージのユースケースを共有した上で、ストレージの可用性を

    LINEの100億超/日メッセージを支える Redis・HBaseのスケールアウト・アップ戦略 #linedevday - Togetterまとめ
  • アプリケーションがマルチスレッドでもマルチコアCPUを活かせない件 - blog.nomadscafe.jp

    もっと詳しい方のフォロー募集です アプリケーションがマルチスレッドになってもネットワーク処理が分散されなければマルチコアを活かせない典型的な例です。id:viverの古橋さんがs100kpsとしてあげていた件にも近いかも。 memcachedで現象を確認します。最近のmemcachedはマルチスレッドで動くようになっているので、まずはそれを確認します。 $ memcached-tool localhost stats|grep threads threads 4 スレッドが4つで起動しています。 負荷がそれなりにある状態(8000req/sec程度)で、コマンドラインでtopを開き、「1」キーを押して、CPUごとの使用率を表示します。(例はFedora8 kernel-2.6.23) Tasks: 77 total, 1 running, 76 sleeping, 0 stopped, 0

  • 512バイトを超える DNSパケット | harasou.github.io

    glibc の脆弱性 CVE-2015-7547 でも話題になった 512バイトを超える DNS パケットについてのメモ。 DNS では、TCP が使われたり、512 バイト超えるデータが扱われることは知っていたが、詳しい仕組みなど知らなかったので、備忘録のためにまとめておく。 そもそもなぜ 512 バイト? 調べてみると、 インターネットで使われている IP(IPv4)の仕様では 一度に受信可能なデータグラム(ヘッダーを含むパケッ ト)として、 576 バイトを保証しなければならないと定められています。この値は、64バイトのヘッダーと 512バイトの データブロックを格納可能な大きさとして選択されたものです refs: https://jprs.jp/related-info/guide/008.pdf とのこと。 インターネットで使われている IP の仕様では、かならず「1パケットで

    512バイトを超える DNSパケット | harasou.github.io
  • マネージドサービスについて

    マネージドサービスについて AWSなどが提供するマネージドサービスを使うかどうかは利用者側の状況にひとえに依存すると思う。 まず気にするべきポイントは、マネージドサービスを使うことで得られるメリットを明確にすることだ。一般に、マネージドサービスはインフラストラクチャからよりアプリケーションに近いレイヤ、多くの場合特定のミドルウェアまで、を抱合して提供してくれるため、運用面での負担が減る。できるだけ利用する方がよいと思う。一方で、運用のやり方やスタイルは提供者側の目線にあわせないといけない。ここにギャップが生まれやすい。理由としては、提供者側の気にする点が全体最適化のうえでベストエフォートで提供できるラインはどこか・そのうえで提示できるSLAがどこにあるか、なのに対して、利用者側の気にする点はミクロな視点で特定リソースが安全に継続可能性が十分にある状態で妥当なコストで利用できるか、の違いがあ

    a2ikm
    a2ikm 2016/02/24
  • レイテンシに負けないプロトコルとして登場したHTTP/2~奥一穂氏による「HTTPとサーバ技術の最新動向」(前編)。Developers Summit 2016

    私はWeb関連の基盤技術を20年くらいやっています。 最近の仕事としてはディー・エヌ・エーで「H2O」というWebサーバを開発していて、2016年2月に1.7.0をリリースしました。HTTP/2対応のWebサーバとしてはおそらく世界最速で洗練された実装だろうという評価をいただいています。 日はサーバ技術をそもそもどういう評価軸でわれわれが見ているのか、HTTP/2の特長。そしてサーバプッシュとはなにか、HTTPS化はどれだけサーバ負荷が上がるのかについてのわれわれの見解。Webサーバ内でのスクリプト実行がどう変わってきているのか、といった話をしていきます。 サーバ技術の評価軸 サーバ技術の評価軸をどう考えているかですが、大きく分けて4つの項目で考えています。 サーバ負荷 転送データ量 応答性 設定・運用コスト まず「サーバ負荷」です。小規模なWebサイトではサーバ負荷はそれほど問題にはな

    レイテンシに負けないプロトコルとして登場したHTTP/2~奥一穂氏による「HTTPとサーバ技術の最新動向」(前編)。Developers Summit 2016
  • 人を強制的に幸せにするデザインとインターフェース | fladdict

    最近よく考えることに、人間を強制的に幸福にするユーザーインターフェースは作れないか、という着想がある。100万ユーザー級のアプリのUI改善に何か関わった結論として、単に使いやすいインターフェースや、KPIアゲアゲの設計とかに飽きた。 むしろ統計、認知心理学、脳科学、行動経済学などをフル活用して、デザインで強制的に幸せを生産できないだろうかと考える。 幸せは生産できるか? アメリカの哲学者、ウィリアム・ジェームズの言葉に、「私達は幸せだから笑うのではない。笑うから幸せなのだ」というものがある。日にも類似の表現として、「笑う門には福来る」という諺がある。 両者で注目したいのは、因果関係の方向だ。どちらも方向として、「笑う」→「幸福」という因果関係を説いている。「幸福」→「笑う」ではない。 実は最近の脳の研究によると、とりあえず口角を持ち上げれば、人間の脳はドーパミンを生産するのだという。脳

    人を強制的に幸せにするデザインとインターフェース | fladdict
    a2ikm
    a2ikm 2016/02/24
  • 算数の問題「円周率を3.14とするとき、半径11の円の面積を求めよ」の解を379.94とするのは誤り? - Togetterまとめ

    科学や教育にまつわる非常に面白い議論に発展したのでまとめました。いろいろな観点から考察がなされていて興味深いです。漏れているツイート等があれば適宜追加をお願いします。 ※なるべく多様な議論を収集するという方針のため量が膨大になっていますが,まとまりごとに区切り線を入れてあるので,適当に読み飛ばしながら興味のある箇所だけ拾っていくのもありですし,時間をかけてじっくり全部読むのも面白いと思います。 2/22 タグが荒らされたのでタグ編集を禁止しました。 3/3 だいぶ落ち着いてきたようなので,イタズラ防止も兼ねて「誰でも編集可」を解除しました。もし何か問題等があれば@kisopsy_kunまでご連絡ください。

    算数の問題「円周率を3.14とするとき、半径11の円の面積を求めよ」の解を379.94とするのは誤り? - Togetterまとめ
    a2ikm
    a2ikm 2016/02/24
    目的による。正確なことを教えることは大事だけどその前にいろいろ言って拒否されるほうが怖い。義務教育の間は「あれは正確じゃない」と言う機会があるから、まずはざっくりでも計算の仕方を知ってほしい。