最近の Python-dev (2017-01) : DSAS開発者の部屋
@methane です。 compact dict が Python 3.6 が9月（ベータになる直前）にマージされ、それのおかげで推薦をもらい 10月ごろから Python の Core Developer になりました。 「PythonのフルタイムコミッタとしてKLabに雇われている」という訳ではないのですが、 もともと自己裁量で業務時間の大半をOSSへの貢献やコードを読むことに費やし、特にこの3ヶ月位は Python ばかり触っていたので、実質的には近い状態です。 そちらでの活動をあまり日本で共有する機会がないので、 Money Forward の卜部さんが書かれている 最近の ruby-core という記事をリスペクトして、 最近の Python の開発状況を紹介する記事を書いてみたいと思います。 Python 3.6 リリース 12/23 に Python 3.6 がリリースされ
CTOの独り言 : DSAS開発者の部屋
このエントリーは、KLab Advent Calendar 2016 の12/25 の記事です。 最終日の担当はCTOの安井です。 今年のアドベントカレンダーもテーマが多岐に渡っていてとても興味深いです。 ゲームに関係ありそうなものから関係なさそうなものまで盛りだくさんですね。 KLabでは業務と直接関係のない開発活動も積極的に推奨しています。 これには、自分が得意とする分野、興味のある技術に対して全力で取り組んで欲しいという願いがあります。好きなことに全力で取り組んで結果を残すことができるエンジニアは、様々な場面において高いアウトプットを出してくれることが多いものです。 社内ではよく「市場価値の高いエンジニアを目指そう」という言い方をしています。 エンジニアが安心して仕事を続けるためには「自分の実力に自信を持てること」がとても重要なことだと考えています。いくら上司から高い評価を得ていても
ISUCON6 で優勝しました : DSAS開発者の部屋
@methane です。タイトルの通り、 ISUCON でとうとう優勝してきました。 チームメンバーは、(予選と同じく) @kizkoh (インフラ担当), @mecha_g3 (アプリ担当) でした。 私は予選のときはガッツリとアプリを書いていたのですが、本戦では netstat -tn (←老害), top, dstat -ai, sudo perf top などをみつつ指示をだしたり、方針を決めたり、完全に未経験だった node.js & react.js 対策をしたりが主な仕事で、あとは序盤のインフラのタスクが大量にあるときに MySQL を docker から外して基本的なチューニングを入れたり Go を100行程度書いただけです。 結果的には優勝できましたが、メンバーの2人がよく準備し本番でも実力を発揮してくれたのに対して 僕の戦略ミスで中盤から全くスコアを上げられなかったので
ISUCON5 予選通過しました (@methane編) : DSAS開発者の部屋
9/27 の ISUCON 予選2日目に参戦してきました。 KLab から参加した6チームのうち予選通過できたのは私が率いる lily white だけ、それも通過組の中で下から3位とかなり厳しい結果になってしまいました。 本格的な練習は新人が予選で ISUCON の難しさを実感してからにしようと思っていたのですが、今年は予選のレベルが想像以上に上がっていて、 お題のアプリも本戦さながらの規模、複雑さになっていて、もう完全に舐めてましたごめんなさい。出題側本気出しすぎです。本当にお疲れ様でした。 考察と感想戦はベンチマーカーが公開されてからにするとして、当日の流れを覚えているうちに振り返ってみます。 (時間とスコアをメモってなくて集計サイトもクローズしてしまったので、文中の時間とスコアはうろ覚えのものです) 準備 lily white は私以外に新卒の @gam0022, そして Twit
その先の世界へ : DSAS開発者の部屋
このエントリーは、KLab Advent Calendar 2015 の12/25の記事です。 最終日なので緊張・・・はさすがにしません（笑 はじめに KLabがゲーム事業に参入して今年で6年になります。 当時生まれた赤ちゃんが来年小学校へ入学する年月ですね、時が経つのは早いものです。 年末の締めの記事ということで、今年を振り返るような内容にしようかともおもいましたが、 2009年から現在までを技術者（CTO）の視点でざっくりと振り返ってみようとおもいます。 2009年 mixiアプリで「恋してキャバ嬢」をリリースしました。 恋キャバはおかげさまで今でも多くの方々に楽しんで頂いてますが、リリース当初は大量のリクエストを処理しきれずにサーバがダウンしてしまい、新規のユーザ登録を停止せざる得ない状況にまで陥ってしまったことがありました。（当時のユーザのみなさんほんとごめんなさい） これまで経験
ISUCON 5 決勝戦で負けてきました : DSAS開発者の部屋
lily white というチームで ISUCON 5 決勝戦に出場してきました。 終盤が、結果 fail でスコアなしに終わってしまいました。 チームメンバーは僕の他に、新人の @gam0022 と、学生の @koki_cheese さんです。 二人とも経験が殆ど無い状態だったので、 @gam0022 には主に MySQL を、 @koki_cheese さんには アプリ側で僕が予選でやったことを練習してもらい、少しでも僕が戦略的に動ける余裕を作るという作戦でした。 結果的に、DB が MySQL でなかった、 @koki_cheese さんが練習時間をあまり取れなかった、 僕が2人を信頼しきれずアプリの実装に回ってしまい、戦略的な所ができなかったために、実力を発揮できずに終わってしまいました。 11:00 ~ 12:00 初回ベンチ実行 下回りは @gam0022 にまかせていたのです
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
VirtualBoxのファイルシステムを10倍速くする ~ find編 ~ : DSAS開発者の部屋
もう、あって当たり前というところまで浸透してきた仮想環境、みなさまは何をお使いでしょうか? 私の周辺ではVirtualBoxがよく使われています。 典型的な使い方としては、 以下のような感じです。 ホストOSには、mac/windowsをつかう ゲストOSには、Linuxを使う 共有フォルダを使って、ホストとゲストでファイルを共有する その中でも地味に重要なのが共有フォルダ。 共有フォルダとは、ホストOSのファイルシステムをゲストOSからマウントするための、VirtualBoxが提供している仕組みです。 しかし便利な反面、ファイルアクセスが非常に遅いという声をよく聞きます。 findが終わらないとか、git statusが遅すぎるとか... この問題への対策を探してみると、下記のような物がみつかります。 vboxsfでなくNFSなど別のファイルシステムを使う VirtulaboxではなくV
go-sql-driver/mysql でプレースホルダ置換をサポートしました : DSAS開発者の部屋
前回の記事で少し触れましたが、 go-sql-driver/mysql にドライバ側でのプレースホルダ置換を実装するプルリクエストを出していました。 それがマージされたので、背景のおさらいと利用方法を紹介しておきます。 背景 Go の database/sql の概要については前回の記事で解説しました。 そこで説明したとおり、 DB.Prepare() を使わずに直接 DB.Exec() や DB.Query() を使った場合、 ドライバ側でのプレースホルダ置換に対応していないドライバでは prepare, exec, close で3回のラウンドトリップが発生することになり、パフォーマンスが悪くなります。 基本的には DB.Prepare() を使えばいいのですが、前回の記事で修正したスケーラビリティの問題は Go 1.5 になるまで直りませんし、 IN 句があるSQL文などで事前に P
Goのdatabase/sql.Stmtのスケーラビリティを改善しました : DSAS開発者の部屋
先日、 Goに初めて私のパッチが取り込まれ 、コントリビュータに仲間入りしました。 このパッチは、 database/sql.Stmt をヘビーに使った時に性能がだいたい16コア以上のコア数にスケールしないという問題を解決するものです。 こういった問題をどうやって調査するのかと、Goにパッチが取り込まれるまでの手順を紹介します。 背景 私は TechEmpower の FrameworkBenchmarks という、いろんな言語/フレームワークで同一のアプリを作ってベンチマークするというプロジェクトで、主にPython関連のメンテナをしています。 Goにも興味があるので、Ginというフレームワークを追加したりコードレビューに参加したりしています。 2014-05-01 に行われた前回のベンチマーク Round 9 では、 PEAK Hosting が実行環境に加わりました。この環境は、デュ
ISUCON4 予選で workload=5 で 88000点出す方法 (lily white 参戦記) : DSAS開発者の部屋
ISUCON4 予選1日目に、 lily white というチームで参戦してきました。 試合中に 62000 点は出していたのですが、最終的に提出したスコアは 60344 点でした。 以降、予選終了までと、その後に気づいたさらにスコアを上げる方法について書いていきます。 実際の提出時のコードは methane/isucon4q-go リポジトリの "final" タグを見てください。 準備 (~前日) 予選方式が発表された時点で、 isucon3 予選と同じ方式だったので、有効な作戦もほぼ同じになる事が予測できました。 具体的には以下のとおりです。 PIOPS な EBS を使わないので、性能が不安定なディスクがネックになる問題は無いでしょう。 1インスタンスのみを使うということから、ネットワーク帯域がネックになる可能性も無いはずです。 ほぼ確実に CPU ネックな問題が出るはずです。 ア
TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋
昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク（いわゆるLong Fat pipe Network）において、通信時間を削減するにはどうしたらいいか？」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間（伝送遅延）を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT（往復遅延時間）はだいたい10〜30ms程度ですが、日本・北米間だと10
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
