GitHub - kazuho/mysql-ranking-engine: (to become) a MySQL storage engine specializing in ranking operationYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
JSX はなぜ「速い」のか - kazuhoのメモ置き場
なぜ「速い」のか、について JSX 開発者の立場から。 たとえば、シューティングゲームで一番重たい処理は何か。言うまでもなく衝突判定。多数の弾や敵機の衝突判定を毎フレームごとに行う必要があり、この演算が重たい。 JSX に同梱されている web/example/shooting.jsx には衝突判定のコードが複数あるが、一番重たいのは Bullet#update 関数で、その処理は以下のようになっている*1。 for (var rockKey in st.rocks) { var rock = st.rocks[rockKey]; if (this.detectCollision(rock)) { if (rock.hp == 0) return false; inDisplay = false; if (--rock.hp == 0) { st.score = Math.min(st.s
mysql_json - a MySQL UDF for parsing JSON
Somewhat related to (or rather not related to) やったーJavaScriptの動くMySQLできたよー - 愛と勇気と缶ビール, I have written a MySQL UDF that parses JSON strings. The UDF introduces one function: json_get, that parses a JSON object or an array and returns one of the properties. SELECT json_get('{"a":1}', 'a') => 1 SELECT json_get('{"a":1}', 'b') => NULL SELECT json_get('[1,2,3]', 2) => 3 SELECT json_get('{"a":[2]}', 'a
「オープンソース開発者がDeNAを選ぶ理由」 (OSC 2011-Kyoto 発表資料)
Hi to every one, it’s really a nice for me to pay a visit this site, it includes useful Information. Thanks a lot for sharing with use! Greatclosetspoeler ReplyDelete Thanks for sharing this nice post. http://5thpm.in/ http://5thpm.in/packers-and-movers-gurgaon.html http://5thpm.in/packers-and-movers-delhi.html Packers and Movers @ http://5thpm.in/ Packers and Movers in Gurgaon @ http://5thpm.in/p
Kazuho@Cybozu Labs: Japanize / Mylingual サービス移管のおしらせ
直前のお知らせになり恐縮ですが、2010年10月29日より Japanize および Mylingual の両サービスを、弊社サイボウズ・ラボ株式会社より、サービスの開発者である私、奥一穂個人へ移管いたします。 蓄積された翻訳データ（編集履歴等含む）は、全て移管されます。 拡張機能や Userscript 等を通して翻訳機能をご利用の皆様におかれましては、何も作業していただく必要はございません。現在と同様に翻訳機能をご利用いただくことが可能です。 Japanize または Mylingual でアカウントを作成し、翻訳作業にご協力いただいている方々におかれましては、サービス移管後に再度アカウント作成をお願いいたします。お手数をおかけし恐縮ですが、個人情報の取り扱いに関しては慎重を期すため、再度ご登録をお願いすることにいたしました。ご理解のほど、よろしくお願いいたします。 移管後のアカウント
Kazuho@Cybozu Labs: Compressing URLs in your Webapp, for size and speed
Last year I had a chance to talk about the internals of our service: Pathtraq at Percona Performance Conference (slides), in which I described the methods we use to compress the URLs in our database to below 40% of the original size, however had not released the source code since then. I am sorry for the delay, but have finally uploaded the code to github.com/kazuho/url_compress. It is generally
Kazuho@Cybozu Labs: Parallel::Scoreboard でワーカープロセスをモニタリングする方法
cho45 さんの Plack::Middleware::ServerStatus (Starman や Starlet で Apache の mod_status 相当の情報を得られるようにする - 冬通りに消え行く制服ガールは、夢物語にリアルを求めない。 - subtech) に続き、昨日 kazeburo さんが「StarmanやStarletでmod_statusっぽい情報を得る簡易版Plack::Middleware::ServerStatus - blog.nomadscafe.jp」というエントリを書かれていらっしゃいましたが、ウェブアプリケーションサーバに限らず、複数のワーカープロセスが動作するシステムにおいて、それらの状況をモニタリングするためのスコアボードがほしい、というケースはよくあることだと思います。 また、プロセス名を使う方法は、他の監視ツールとの相性が悪い、プロ
Amazon AWS と NIFTY や Rackspace のクラウド (IaaS) は、技術的にどう違うのか - kazuhoのメモ置き場
AWS はコンポーネント指向の IaaS 現時点でのクラウドコンピューティングの大勢は、リソースをオールインワンで提供すること。一般ユーザーにとっての SaaS なアプリケーションは、もちろんそうだし、開発者にとっての Google App Engine も然り。 Amazon AWS も、EC2 や S3, Relational Database Service, Elastic Load Balancer といったサービスコンポーネントを Amazon が提供し、それを開発者が組み合わせて可用性の高いサービスを構築するようになっている。 コンピューティングリソースと、基盤ソフトウェアコンポーネントがセットで提供されているというのは、IBM PC以前のパソコンを思い出すような... Rackspace Cloud や NIFTY Cloud は VM 指向 一方、AWS に継ぐ IaaS
2010年代には Apache の mpm_prefork とか流行らない (もしくは HTTP keep-alive のメリットとデメリット) - kazuhoのメモ置き場
HTTP の持続的接続の功罪について はじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の２点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約 ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。 一方、持続的接続のデメリットは、 接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、１プロセス１コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。 そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション
ウェブのアーキテクチャパターン＝空間と時間の分割、という話 - kazuhoのメモ置き場
Twitter でつぶやいたことだけど。 ウェブの本質はメッセージのルーティング(と保存)だし、最重要なアーキテクチャパターンは空間と時間の分割アルゴリズム。マルチコアvs時分割マルチタスク、L3(もしくは携帯のセル)と CSMA等、リバースプロキシとAppサーバ、シャーディングとMVCC、... http://twitter.com/kazuho/status/11333730163 だから研究開発あるいはプロダクトの選定で問いかけるべきは、どのレイヤを(空間と時間の)どちらの手法で分割しているのか？ その手法が技術的コスト的にベストなのか？ という点。 http://twitter.com/kazuho/status/11333815510 それに対して、どのレイヤにおいて必要な信頼性（可用性と一貫性）を確保しようとするかによって、解が変わったりする http://twitter.co
Cosmic っていうネットワークストレージを作り始めた - kazuhoのメモ置き場
GitHub - kazuho/cosmic: fail-safe management tools for network-based software RAID, using mdadm + iSCSI 概要 (というか近場の目標) は、以下のとおり。 fail-safe な network RAID 多重マウントが発生しないプロトコルを実装 RAID だから DRBD や MySQL の async replication のような lost updates 問題がない software RAID + NBD を使用 (NBD は遅いから iSCSI 対応するかも) RDBMS レベルのレプリケーションや DRBD と異なり、高可用性のあるブロックデバイスを提供するソフトウェアレイヤとして機能 様々なストレージミドルウェアを統一的に管理可能なので、管理コストが低い バックアップとかも
GitHub - kazuho/nopan: install software directly from SVN or Git (instead of from CPAN)
NAME nopan - download software from source-code repository and install SYNOPSIS % nopan [options] http://svn-or-git-repository -i, --install -I, --no-install installs (or does not install) the repository (default: yes) -t, --test -T, --no-test runs (or does not run) the test suit (default: depends on the type of the repository) DESCRIPTION Nopan downloads software from a subversion repository or a
linuxで httpd が使ってるメモリ総量を調べる話 - kazuhoのメモ置き場
Perl等のLLでウェブアプリケーションサーバを書いていると、普通はマルチプロセスモデル (apache なら prefork とか) で運用することになると思う。で、それらがどれだけメモリを使っているか、っていうのはチューニングにおいて重要になってきたりする (んじゃないかと思う) けど、そもそもメモリの総使用量をどうやって測定するのか。 20:20追記: PSSを使ってワンライナーで測定するのが簡単 (コメント欄参照)。kosakiさんありがとうございます。 $ sudo perl -le 'for my $p (@ARGV) { open my $fh, "< /proc/$p/smaps" or die $!; map { /^Pss:\s*(\d+)/i and $s += $1 } <$fh> } print $s' `pgrep plackup` 914325以下は初回投稿時
ドキュメントとテストコードつきのPerlスクリプトを書く方法 - kazuhoのメモ置き場
Re http://d.hatena.ne.jp/perlcodesample/20091130/1258979624, http://mt.endeworks.jp/d-6/2009/12/scriptsubimport.html スクリプトとコードとテストを単一のファイルにまとめたい*1という需要が、かねて自分の中であったので教えを請うた結果、以下のような感じで書けばいいことがわかった。 #! /usr/bin/perl use modules...; my $global = ...; sub foo { ... } sub bar { ... } run_tests() if $ENV{HARNESS_ACTIVE}; # メインのコード foo(); bar(); ... sub run_tests { ... exit; } __END__ =head1 NAME my_scr
(特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場
InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー
Kazuho@Cybozu Labs: パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料)
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場
「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって本当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ（とエスケープ）を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ（あるいはchunkedエンコーディング）を使うことで、ペイロードのパース／変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降
コンピュータは創造力を刺激する 奥一穂さんのエンジニアライフ（1/2） - 特集：No okyuu, No Life [okyuu.com]
コンピュータは創造力を刺激する 奥一穂さんのエンジニアライフ（1/2） 「コンピュータは自分の考えをダイレクトに試せる」――天才エンジニアとして国際的な評価も高いサイボウズ・ラボの奥一穂さんは笑顔で語る。世間からのスマートだとの評価には「自分は広く浅くだから」とさらり。 この企画はokyuu.com編集部が現在のエンジニア像をリレー形式で追っていくものです。 （取材・文＝編集部） 奥一穂（おくかずほ） 1977年2月21日生 32歳 サイボウズ・ラボ 【略歴】 1997年 Palm OS 用Webブラウザ「Palmscape」開発 1999年 東京大学中退、株式会社イリンクス入社 2002年 M.I.T. Technology Review誌のTR100に選出 2003年 株式会社モビラス 代表取締役就任 2004年 IPA「未踏ソフトウェア創造事業」採択 2005年 IP
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
