タグ

2010年9月24日のブックマーク (10件)

  • 開発メモ: オンメモリB+木による省メモリ連想配列

    Kyoto Cabinet 1.2.2から加わったGrassDBは、オンメモリでページ管理を行うB+木を実装してメモリを節約しちゃう仕組みである。それを使ってJavaPythonRubyPerlなどのハッシュ(連想配列)機構を鬼のように省メモリにしてみる。頑張ればなんと20分の1になる。 前提 B木やその変種のB+木などは、キーの順序が近いレコード群を「ページ」という単位にまとめてシリアライズしてストレージに書き込むことで、入出力の頻度を減らして高速化することを意図している。メモリに比べて低速なストレージの上で大量のデータを管理するために使われる。多くのRDBMSやいくつかのDBMがB+木をサポートしているのはそれが理由であろう。一方で、メモリ上で検索可能なデータ構造を表現するためには、二分探索木やその特殊例である赤黒木が使われる。STLのstd::mapの実装にも赤黒木を使うのが一

  • RubyKaigi2010 に行ってきた(2, 3日目) - LukeSilvia’s diary

    RubyKaigi2010 に行ってきた(1日目) - Slow Danceに続き、今年のRubyKaigi に行ってきたレポートを書きたいと思います!例によって興味があった内容をまとめました。Chad Fowler の基調講演の内容は情熱プログラマー ソフトウェア開発者の幸せな生き方を読むのが一番いいと思います。 また、内容に誤りがありましたらお手数ですが指摘いただけますと助かります。 Ruby powering 9 million dining tables(Cookpad) Cookpad CTO の橋さん(@hashikem)によるCookpad のサービス、システム全般のお話と、id:secondlife さんが何故Cookpad に入社したかというお話を聴きました。 規模 9.89 M UU / month 83万レシピ 開発体制 ユーザにとって価値のあるものを作成するには

    RubyKaigi2010 に行ってきた(2, 3日目) - LukeSilvia’s diary
    kamipo
    kamipo 2010/09/24
    クックパッドのはなし
  • skip-name-resolveでMySQLへの接続がどの程度速くなるのか試してみた - Lism.in * blog - nekoya (id:studio-m)

    skip-name-resolve重要 - kotori::log を見て、実際のところどの程度性能に影響があるのか気になったのでベンチを取ってみた。 ベンチマークスクリプトはhttp://gist.github.com/594839で、connect -> disconnectを1000回繰り返すのにかかった時間を計測。 ■計測結果 環境の詳細は後述するとして、まずは結果から。手動で何回か実行して、結果のボリュームゾーンを感覚的に抽出。 環境 実行時間(秒) skip-name-resolve 1.73 〜 1.74 hosts 1.75 〜 1.76 DNS 2.26 〜 2.29 /etc/my.cnfでskip-name-resolveを有効にした場合、確かに速くて、DNSで名前解決するよりも0.5秒ぐらい速くなる。1回あたり0.5msecをどう見るかはケースバイケースだが、DB

    skip-name-resolveでMySQLへの接続がどの程度速くなるのか試してみた - Lism.in * blog - nekoya (id:studio-m)
    kamipo
    kamipo 2010/09/24
  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.

    kamipo
    kamipo 2010/09/24
    sudoのログを取ろう
  • 『Hadoop/Hiveを用いたログ解析基盤の構築』

    こんにちは。Amebaのログ解析基盤を担当しているICHIROです。 今回は構築・運用中のログ解析基盤「Patriot」について書きたいと思います。 Webサービスを運営していると日々大量のログデータやユーザデータが蓄積されます。 今まではPV(ページビュー)やUU(ユニークユーザ)などアクセスログなどから取れる、大枠の指標のみを見ることがほとんどでした。 ページビューに合わせてシステムを増強するなど、システム側としては十分とも言える指標ですが、広告や課金サービスという視点から見ると十分とは言えません。 今まではAmeba内の個々のサービス担当者が必要とする指標を出すためにアプリエンジニアDBエンジニアに都度依頼をする形でデータを抽出していました。 今後の課金サービスの発展が見込まれ、よりデータ分析の重要性が高まると考えた私は、エンジニアでないサービス担当者(主にプロデューサ)がより簡単

    『Hadoop/Hiveを用いたログ解析基盤の構築』
  • Kazuho@Cybozu Labs: String::Filter っていうモジュール書いた - 続: (Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について

    先のエントリ「(Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について」の続き。 弾さんが「404 Blog Not Found:DHTML - 構造化テキストは構造化するのがやっぱ正しい」で示されているような DOM ベースの操作を行えば、原理的に XSS 脆弱性を防ぐことができます。ただ、クライアントサイド JavaScript によるレンダリングはウェブの構造を破壊するという点で筋が悪い(テーブルと FONT タグを利用したページレイアウトが批判されていた頃を覚えていらっしゃいますでしょうか。JavaScript によるレンダリングはウェブのリンク構造も破壊するので一層たちが悪いというのが自分の考え)ですし、サーバサイドでの DOM 操作は重たいので、できれば避けたいところです。 構造化テキストの HTML への変換は、よほど複雑な記法でない限り

  • oinume journal

    大規模なコードベースでリファクタリングを省エネ化するためにcodemodを最近調べていて、軽く試行錯誤したのでそのメモ。 やりたいこと 例えば以下のようなTable Driven TestなコードをBEFOREからAFTERに書き換えたい。コード量が多いため人間がやるのは現実的ではなく、codemodで機械的に書き換えたい。 BEFORE package main import ( "slices" "testing" ) func TestContains(t *testing.T) { type args struct { ss []string s string } tests := []struct { name string args args want bool }{ { name: "empty: false", args: args{[]string{}, ""}, wan

    oinume journal
    kamipo
    kamipo 2010/09/24
  • Mostly-Concurrent Mark & Sweep GC のアルゴリズム

    目次 1. 前置き 2. HotSpot VM 1.4.x の GC の種類 3. Mostly-concurrent Mark & Sweep 4. 応用 4.1 世代別 GC との組み合わせ 4.2 カードマーキング (Card Marking) 4.3 並列化 (Parallel GC) 4.4 ビットワイズ・スイープ (Bitwise Sweep) 4.5 インクリメンタル・コンパクション (Incremental Compaction) 5. 参考文献 脚注 コメント 1. 背景 ガーベージコレクション(GC) には色々なアルゴリズムが存在するが、大雑把に言って Stop-the-World (STW) 型 GC と On-the-fly 型 GC に大別される。 STW 型の GC はプログラムの実行中にはガーベージの回収を行わず、メモリが枯渇した時になって始めてガーベージの回

    kamipo
    kamipo 2010/09/24
  • セッションの有効期間とか設定とか挙動とかを調べました - [PHP + PHP] ぺんたん info

    PHPでログインページを作ったりするときに、よくセッションを使ったりすると思いますが、 じゃあセッションってどのようになってるのでしょうか。 [参考]セッション固定攻撃 [参考]GPC(GET/POST/cookie)以外の情報を送るアラワザ [参考]アンダーバーのあるドメインではセッションクッキーは使用できません セッションの破棄されるタイミング ガベージコレクト(ガベージコレクション、ガーベッジコレクション、ガーベッジコレクタともいわれます)とは、『ごみ拾い』という意味です。 session_start()が行われたときに、session.gc_probabilityを分子、session.gc_divisorを分母とする確率で、 session.gc_maxlifetimeよりファイル更新日付の古いファイルをsession.save_pathから削除します。 デフォルトでは、1/10

    kamipo
    kamipo 2010/09/24
  • skip-name-resolve重要 - hiroyのブログ

    MySQLを使っていて、サーバーの負荷は高くないのに接続できないクライアントが発生、状況を見ようとshow processlistするとunauthenticated userがたくさんいることがわかった。そのコネクションがあふれてmax connectionsに到達、接続できないクライアントがあるらしかった。 いろいろ調べてみるとクライアントのIPアドレスDNS逆引きをしていて、その処理が追いつかなくなるとそうなるらしく、解決方法としては2つあった。 /etc/hostsでクライアントの名前解決をできるようにする /etc/my.cnfにskip-name-resolveを設定してMySQLをrestart /etc/hostsでの対策はお手軽だがメンテナンスが面倒な感じ。 skip-name-resolveのオプション付けていなかったっけ…と調べたら付いていないことが発覚。/etc/

    skip-name-resolve重要 - hiroyのブログ
    kamipo
    kamipo 2010/09/24