最近のPython-dev(2018-06) : DSAS開発者の部屋
バックナンバー: 2018: 1月 | 4月 2017: 1月 | 2月 | 3月 | 4月 | 5月 | 6月 | 8月 | 9月 | 12月 Python 3.7 日本時間の6/28に Python 3.7 がリリースされました。 終盤に駆け込みで2つ大き目の変更が入りました。 Unicode 11 対応 ASTの変更の revert Unicode 11 はデータの更新だけなので危険が少ないし、1.5年後の3.8まちにはしたくないということでGoサインが出ました。 AST は、僕が中心で行ったAST段階での定数畳み込みの準備として、 docstring とそうでない文字列の区別をAST段階でつきやすくために変更していました。 その変更によりいくつかのライブラリで問題が報告されていたのですが、AST はもともと後方互換性を保証していないからとライブラリ側での対処がされていました。しかし
最近のPython-dev(2018-01) : DSAS開発者の部屋
バックナンバー: 2017: 12月号 | 9月号 | 8月号 | 6月号 | 5月号 | 4月号 | 3月号 | 2月号 | 1月号 Python 3.7b1 が29日の予定です。問題なければ日本時間の今日中に出るはずですが、buildbotやTravisが不安定なので少し遅れるかもしれません。これで feature freeze なので新機能追加やパフォーマンス向上などは基本的に終わりです。 beta 前の駆け込みで、先月号で紹介したAcceptされたPEPを実装する大型コミットがたくさんマージされました。（間に合わなかったものは無いはず。たぶん。） 今回は私が関係していたところを中心に紹介していきます。 dict の順序の言語仕様化 Python 3.6 から dict が挿入順序を保存するようになりましたが、この挙動は実装詳細であり、まだ言語仕様ではありませんでした。そのため、他の
Pythonアプリの起動を高速化する : DSAS開発者の部屋
pipenv 9.0.2 のリリースでCLIの大幅な高速化をしたというアナウンスを見かけました。 Just released Pipenv v9.0.2, which includes massive CLI speedups! https://t.co/AGD8Hkq1EG — Kenneth Reitz 🐍 (@kennethreitz) 2018年1月16日 興味を持ってすぐに試してみたのですが、あまり速く感じられませんでした。そこで Python 3.7 の新機能を使って速度を調査することにしました。 この記事ではその新機能と実際の使い方を紹介します。 起動時間 ≒ import時間 pipenv -h のようなコマンドの実行時間は、実際にヘルプメッセージを表示するための時間よりもずっと長くなります。 アプリケーションが起動するときには、設定ファイルの読み込みなど一定の処理が必要
最近のPython-dev(2017-12) : DSAS開発者の部屋
バックナンバー: 9月号 | 8月号 | 6月号 | 5月号 | 4月号 | 3月号 | 2月号 | 1月号 @methane です。 ISUCON があってしばらく間が空いてしまいました。コミットやML上の議論も追えてないのですが、1月末にPython 3.7のbeta1 (=feature freeze)が予定されているために、Python 3.7 を目標にしている PEP たちがたくさんacceptされたので、それらを紹介しておきます。 PEP 540 UTF-8 mode https://www.python.org/dev/peps/pep-0540/ PEP 538 (locale coercion) とセットで、私が BDFL-delegate (PEP を accept する責任者) になった PEP です。 この PEP は当初はかなりのボリュームが有ったのですが、すでに
最近のPython-dev(2017-09) : DSAS開発者の部屋
バックナンバー: 8月号 | 6月号 | 5月号 | 4月号 | 3月号 | 2月号 | 1月号 今月は Sprint がありました。去年の Sprint はベータ版直前だったのでたくさんの実装が入りましたが、次の Python 3.7 のベータは来年のはじめなので、今回は実装よりも提案(PEP)が多めです。とても全部は紹介しきれない（そもそも一部を除いて議論を追えていない）ので、今月からは提案については受理されたものや受理間近のものだけ紹介していきます。 namedtuple 生成の高速化 bpo-28638: Optimize namedtuple() creation time by minimizing use of exec() namedtuple という、タプルの要素に整数の添字ではなく属性名でアクセスできるようにするデータ構造があります。 例えば次のようにして使われます。
最近のPython-dev(2017-08) : DSAS開発者の部屋
バックナンバー: 6月号 5月号 4月号 3月号 2月号 1月号 https://docs.python.org/ja/3/ docs.python.org に言語スイッチのドロップダウンリストが追加されました。docs.python.org は Fastly を使っているので、 docs.python.jp よりも高速に閲覧できると思います。 docs.python.jp にあるセクション単位での英語ドキュメントへのリンク機能などがまだなくて単純な翻訳でしか無いので、すぐには docs.python.jp を止めるつもりはありませんが、将来的には docs.python.jp は docs.python.org/ja/ にリダイレクトすることを考えています。 PEP 550: Execution Context Flask などのフレームワークではスレッドローカルストレージを利用して「コ
最近のPython-dev(2017-06) : DSAS開発者の部屋
バックナンバー: 5月号 4月号 3月号 2月号 1月号 PEP 546 -- Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7 2014年に Python 2.7 をセキュアな状態に保つため、過去に PEP 466 でセキュリティ関連の Python 3.4 の機能が Python 2.7 にバックポートされました。これには ssl モジュールも含まれており、 Python 2.7.9 からは TLS のホストを自動で検証するようになったりシステムの証明書ストアを利用できるようになりました。 今回の PEP 546 は、さらに Python 3.5 で追加された ssl.MemoryBIO と ssl.SSLObject も Python 2.7 にバックポートするものです。これらの API を利用すると、 socket をラッ
最近のPython-dev(2017-04) : DSAS開発者の部屋
バックナンバー: 3月号 2月号 1月号 NEWS (changelog) の作り方 Mercurial時代からNEWSファイル (changelog) の扱いは面倒だったのですが、Githubに移行したことでよりコンフリクトが起こりやすくなり面倒さに拍車がかかりました。 また、コンフリクトせずに間違った状態でマージされるというかなり致命的な事故も起こってしまっています。 (ワークフローが cherry-pick になったためにマージ時に履歴が考慮されなくなったのか、それともMercurialよりもGitの方がマージがバカなのか、詳細は把握してません。) それで、1つの大きなNEWSファイルにエントリを追記していく代わりに、1つのエントリだけを含む小さいファイルを追加していき、ツールでそれらのファイルからNEWSファイルを生成する仕組みへの移行が急務となり、ツールの選定のためにコンペが行わ
最近の Python-dev (2017-03) : DSAS開発者の部屋
バックナンバー: 2月号 1月号 Python 3.6.1rc1 Python 3.6.1rc1 がリリースされました。大きな問題がなければ 3.6.1 は 3/20 にリリースされる予定です。 3.6.1 は Github に移行してから初めてのリリースになります。なにか問題がないか確認するために、いつものRC版以上にソース形式・バイナリ形式両方の配布物のテストが必要なので、可能な方は協力をお願いします。 Github 移行後日談 以降から1ヶ月が経ちました。開発者からのフィードバックはおおむね好評です。私は、気軽にプルリクエストをくれた人がCLAにサインしないまま放置して大量のマージできないプルリクエストが貯まることを懸念していたのですが、今までののところそれも大丈夫そうです。 一方で Misc/NEWS といういわゆる changelog にあたるファイルが頻繁にコンフリクトを起こし
最近の 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 がリリースされ
vmprof-flamegraph を作りました : DSAS開発者の部屋
vmprof-flamegraph を作ったのでその紹介をしておきます。 まず、サンプルとして Sphinx を使って Python のドキュメントをビルドしたときの vmprof 結果を flamegraph にしてみたので、どんなものかはこちらを見てみてください。 http://dsas.blog.klab.org/img_up/sphinx-prof.svg flamegraph について flamegraph の一般的な紹介については省略して、リンクだけ置いておきます。 公式サイト: http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html 日本語の紹介記事: http://d.hatena.ne.jp/yohei-a/20150706/1436208007 他にプロファイル結果をビジュアライズするツールとしては cac
pixiv private isucon 2016 攻略 (1/5) : DSAS開発者の部屋
攻略記事一覧: pixiv private isucon 2016 攻略 (1/5) pixiv private isucon 2016 攻略 (2/5) pixiv private isucon 2016 攻略 (3/5) pixiv private isucon 2016 攻略 (4/5) pixiv private isucon 2016 攻略 (5/5) pixiv さんが社内で開催したプライベート ISUCON の AMI を公開してくれたので、手順を残しながら攻略していきます。 ISUCON6出題チームが社内ISUCONを開催！AMIも公開！！ リポジトリ この記事の対象読者は途中で何をすればいいかわからなくなってしまう ISUCON 初心者です。 Go を利用して攻略していきますが、他の言語で参加する場合でも考え方などは参考になると思います。 最低限の初期設定 ssh の公開
Tornado アプリのログファイル書き込みのチューニング : DSAS開発者の部屋
最近は協力プレイやPvPなどの「リアルタイムサーバー」を書くときは Go が主流になっているのですが、 Tornado を使ったシステムも健在です。 (以前の記事) 数人〜十数人程度の「部屋」を、1つの Tornado プロセスに複数もたせ、さらに一台のサーバーにその Tornado プロセスを複数置くことでCPUのマルチコアを活用する構成になっているのですが、最近各プロセスがログファイルを書く部分でブロックして応答性能が悪化するケースがあったので対策しました。 この記事ではその対策で行ったチューニングや、行わなかったチューニングについても紹介します。 ※なお、この記事は Tornado を題材にしていますが、似たような仕組みになっている node.js などの他の言語のフレームワークでも同じ事が言えるはずです。 前提知識 Tornado は epoll や select などのIO多重化
VirtualBoxのファイルシステムを10倍速くする ~ find編 ~ : DSAS開発者の部屋
もう、あって当たり前というところまで浸透してきた仮想環境、みなさまは何をお使いでしょうか? 私の周辺ではVirtualBoxがよく使われています。 典型的な使い方としては、 以下のような感じです。 ホストOSには、mac/windowsをつかう ゲストOSには、Linuxを使う 共有フォルダを使って、ホストとゲストでファイルを共有する その中でも地味に重要なのが共有フォルダ。 共有フォルダとは、ホストOSのファイルシステムをゲストOSからマウントするための、VirtualBoxが提供している仕組みです。 しかし便利な反面、ファイルアクセスが非常に遅いという声をよく聞きます。 findが終わらないとか、git statusが遅すぎるとか... この問題への対策を探してみると、下記のような物がみつかります。 vboxsfでなくNFSなど別のファイルシステムを使う VirtulaboxではなくV
Goでアロケーションに気をつけたコードを書く方法 : DSAS開発者の部屋
GoはPythonのようなLLと比べると実行速度は速いのですが、GCは特別速いわけではないので、相対的にGCがパフォーマンスに与える影響は大きくなります。 また、Java に比べると、一時オブジェクトなどのために頻繁にヒープアロケーションを行うとGCの停止時間が長くなりがちですが、一方でヒープアロケーションを避けたプログラミングがしやすい言語でもあります。 MySQL ドライバのような低レイヤーのライブラリを作る場合、アプリケーション側の性能要件を勝手に決めることができないので、現実的な範囲でアロケーションを減らす努力をするべきです。 ということで、前回の記事 で紹介したプレースホルダ置換を実装するにあたって経験した、アロケーションに気を使ったプログラミングについて、チューニングする手順やコード上のテクニックを紹介したいと思います。 1. まずは正しく動くものを作る go-sql-driv
Goのdatabase/sql.Stmtのスケーラビリティを改善しました : DSAS開発者の部屋
先日、 Goに初めて私のパッチが取り込まれ 、コントリビュータに仲間入りしました。 このパッチは、 database/sql.Stmt をヘビーに使った時に性能がだいたい16コア以上のコア数にスケールしないという問題を解決するものです。 こういった問題をどうやって調査するのかと、Goにパッチが取り込まれるまでの手順を紹介します。 背景 私は TechEmpower の FrameworkBenchmarks という、いろんな言語/フレームワークで同一のアプリを作ってベンチマークするというプロジェクトで、主にPython関連のメンテナをしています。 Goにも興味があるので、Ginというフレームワークを追加したりコードレビューに参加したりしています。 2014-05-01 に行われた前回のベンチマーク Round 9 では、 PEAK Hosting が実行環境に加わりました。この環境は、デュ
MySQL 5.6 でのレプリケーション遅延は危険 : DSAS開発者の部屋
MySQL 5.6 の検証中に MySQL 5.5 とは違うタイプのレプリケーション遅延を見つけたので紹介します。 MySQL のレプリケーションのおさらい MySQL のレプリケーションは次のような仕組みで動作しています。 マスターの更新トランザクションが binlog を書く スレーブの I/O スレッドがマスターに接続し、 binlog を取得し、 relaylog を書く. マスター側はスレーブからの接続を受け付けると(dump スレッド)、指定された場所から最新までの binlog を転送する binlog が追記されるのを待ってさらにスレーブに送る スレーブのSQLスレッドが relaylog を再生する MySQL 5.5 でよくあったレプリケーション遅延 マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。 一方、ス
Redis Sentinel で冗長構成を組む際の注意点 : DSAS開発者の部屋
KVS界隈ではすっかりおなじみ(?)のRedisですが、当社でも徐々にそのニーズが高まってきました。 標準機能として、レプリケーション、Pub/Sub、ソート等の便利機能が満載のRedisですが、サービスに投入する際に冗長構成をどう組むかといった点が気になっている方もいるのではないでしょうか。 まだまだ検証中ではあるのですが、Redisに実装されているRedisSentinelを用いて冗長構成を組んだ際にハマった所をご紹介したいと思います。 RedisSentinelとは Redisに標準実装されている機能の一つで、Redisのステータス監視、通知、自動フェイルオーバーが行なえます。 詳細な仕様、設定に関しては以下のドキュメントをご確認下さい。 http://redis.io/topics/sentinel RedisSentinel導入前の構成 特に何の変哲も無い構成です。 Redisサ
ISUCON4 予選で workload=5 で 88000点出す方法 (lily white 参戦記) : DSAS開発者の部屋
ISUCON4 予選1日目に、 lily white というチームで参戦してきました。 試合中に 62000 点は出していたのですが、最終的に提出したスコアは 60344 点でした。 以降、予選終了までと、その後に気づいたさらにスコアを上げる方法について書いていきます。 実際の提出時のコードは methane/isucon4q-go リポジトリの "final" タグを見てください。 準備 (~前日) 予選方式が発表された時点で、 isucon3 予選と同じ方式だったので、有効な作戦もほぼ同じになる事が予測できました。 具体的には以下のとおりです。 PIOPS な EBS を使わないので、性能が不安定なディスクがネックになる問題は無いでしょう。 1インスタンスのみを使うということから、ネットワーク帯域がネックになる可能性も無いはずです。 ほぼ確実に CPU ネックな問題が出るはずです。 ア
チャットで学ぶ Go ネットワークプログラミング : DSAS開発者の部屋
簡単なチャットプログラムは、ネットワークプログラミング用のフレームワークでは定番のサンプルプログラムです。 echo サーバーが Hello World とするなら、チャットは FizzBuzz といったところでしょう。 とりあえず動くだけのチャットならだれでもすぐに作れるようになりますが、まじめにチャットを作ることで、 ネットワークプログラミングで考えないといけない点やエラー処理の重要な基礎を学ぶことができます。 ということで、 Go でシンプルなチャットを実装してみました。 (ソースコード) 以降、何を考えてどういう設計を採用したのかを解説していきます。 考慮すべきポイント 特定のクライアントへの送信に長時間待たされた場合に、他のクライアントへの送信が遅れないようにする。 クライアントを切断するのは、 (1)ルーム側から kick する場合, (2)受信エラー, (3)送信エラー の3
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
