タグ

ブックマーク / dsas.blog.klab.org (15)

  • VirtualBoxのファイルシステムを10倍速くする ~ find編 ~ : DSAS開発者の部屋

    もう、あって当たり前というところまで浸透してきた仮想環境、みなさまは何をお使いでしょうか? 私の周辺ではVirtualBoxがよく使われています。 典型的な使い方としては、 以下のような感じです。 ホストOSには、mac/windowsをつかう ゲストOSには、Linuxを使う 共有フォルダを使って、ホストとゲストでファイルを共有する その中でも地味に重要なのが共有フォルダ。 共有フォルダとは、ホストOSのファイルシステムをゲストOSからマウントするための、VirtualBoxが提供している仕組みです。 しかし便利な反面、ファイルアクセスが非常に遅いという声をよく聞きます。 findが終わらないとか、git statusが遅すぎるとか... この問題への対策を探してみると、下記のような物がみつかります。 vboxsfでなくNFSなど別のファイルシステムを使う VirtulaboxではなくV

    VirtualBoxのファイルシステムを10倍速くする ~ find編 ~ : DSAS開発者の部屋
  • 最近のPython-dev(2018-04) : DSAS開発者の部屋

    バックナンバー: 2018: 1月 2017: 1月 | 2月 | 3月 | 4月 | 5月 | 6月 | 8月 | 9月 | 12月 Python 3.7 がベータになり、大きな変更はなく安定期に入りました。 その間、Python の言語自体やエコシステムに関して重要な話題が幾つかありました。 pypi.python.org から pypi.org へ 長年 Python のエコシステムを支えてくれていた PyPI がリニューアルしました。 Python 3 への移行を始めとしてモダン化され、 Markdown で書いた README をレンダリングできるようになるなどの改善も入っています。 IRC から Zulip chat へ freenode に python-dev という IRC チャンネルがあるのですが、新しい貢献者がコミュニケーションを取るのに今更IRCを使うのはハードルが

    最近のPython-dev(2018-04) : DSAS開発者の部屋
    a2ikm
    a2ikm 2018/04/28
  • ログからは見えてこない高負荷サイトのボトルネック : DSAS開発者の部屋

    ちょうど1年前に「高負荷サイトのボトルネックを見つけるには」という記事を掲載していますが、この手のトラブルシューティングって結構大変で悩ましいですよね。はじめまして、新入りの@pandax381です。 ログからは見えてこないもの 「サイトの応答が遅い」という問題が発生した場合、その原因はどこにあるでしょうか。 Webアプリケーションの処理に時間が掛かっている DBサーバに投げたクエリーの応答が遅い サーバの処理能力を超えている などなど、いくつもの可能性があります。通常、上に挙げているような問題は、アプリケーションやサーバのログを調査することで、原因を突き止めることができます。 一方で、こういったログの調査だけでは、その原因にたどり着くことができなかったり、相当な苦労が伴うケースもあります。 あるサイトのある日の出来事 つい先日のことですが、KLabの運営している某ソーシャルゲームにて、サ

    ログからは見えてこない高負荷サイトのボトルネック : DSAS開発者の部屋
  • Go ではエラーを文字列比較する?という話について : DSAS開発者の部屋

    Go で関数の戻り値のエラーを判別するときに、エラーメッセージの文字列をチェックするコードが存在します。 (例) これは、 Go が言語設計としてエラー処理が貧弱だったり、標準ライブラリがエラー処理を軽視しているからでしょうか? 言語設計や標準ライブラリのAPIの設計をみて行きましょう。 TL;DR 言語設計としては、Java的例外機構と同等以上の(文字列比較によらない)エラー検査が可能 ただし Go のエラーに関する哲学により、公開されていないエラーが多い 実際にエラーを文字列比較されている実例についての解説 Go のエラー検査方法 Java の例外機構では、例外をキャッチするために専用の構文が用意されており、型によりマッチングすることができます。 これはクラスのツリー構造を利用してサブクラスをまとめて分岐することもできます。 一方で、同じクラスでも値によりエラー処理が異なる場合には、

    Go ではエラーを文字列比較する?という話について : DSAS開発者の部屋
    a2ikm
    a2ikm 2015/05/03
  • Android/iOS向けテストアプリ配信ツール 「EMLauncher」を公開しました : DSAS開発者の部屋

    先日、TestFlightのAndroidサポート終了、Appleによる買収といったニュースが世間を騒がせましたが、皆さんテストアプリの配信はどうしていますか? KLabでは自社製のテストアプリ配信ツール「EMLauncher」を使用しているのですが、せっかくなのでOSSとして公開することにしました。 https://github.com/KLab/emlauncher 今すぐ試す 今すぐ試したい方のために、セットアップ済みのAWS EC2イメージを用意しました。 ami-9b295f9a EMLauncher Sample インスタンスを起動後、設定ファイルのAWSアカウント情報を編集し、S3のバケットを作成してください。 (設定の詳細はconfigディレクトリのサンプルをご覧ください) /home/ohoflight/emlauncher/config/emlauncher_confi

    Android/iOS向けテストアプリ配信ツール 「EMLauncher」を公開しました : DSAS開発者の部屋
  • ISUCON4 予選で workload=5 で 88000点出す方法 (lily white 参戦記) : DSAS開発者の部屋

    ISUCON4 予選1日目に、 lily white というチームで参戦してきました。 試合中に 62000 点は出していたのですが、最終的に提出したスコアは 60344 点でした。 以降、予選終了までと、その後に気づいたさらにスコアを上げる方法について書いていきます。 実際の提出時のコードは methane/isucon4q-go リポジトリの "final" タグを見てください。 準備 (~前日) 予選方式が発表された時点で、 isucon3 予選と同じ方式だったので、有効な作戦もほぼ同じになる事が予測できました。 具体的には以下のとおりです。 PIOPS な EBS を使わないので、性能が不安定なディスクがネックになる問題は無いでしょう。 1インスタンスのみを使うということから、ネットワーク帯域がネックになる可能性も無いはずです。 ほぼ確実に CPU ネックな問題が出るはずです。 ア

    ISUCON4 予選で workload=5 で 88000点出す方法 (lily white 参戦記) : DSAS開発者の部屋
  • チャットで学ぶ Go ネットワークプログラミング : DSAS開発者の部屋

    簡単なチャットプログラムは、ネットワークプログラミング用のフレームワークでは定番のサンプルプログラムです。 echo サーバーが Hello World とするなら、チャットは FizzBuzz といったところでしょう。 とりあえず動くだけのチャットならだれでもすぐに作れるようになりますが、まじめにチャットを作ることで、 ネットワークプログラミングで考えないといけない点やエラー処理の重要な基礎を学ぶことができます。 ということで、 Go でシンプルなチャットを実装してみました。 (ソースコード) 以降、何を考えてどういう設計を採用したのかを解説していきます。 考慮すべきポイント 特定のクライアントへの送信に長時間待たされた場合に、他のクライアントへの送信が遅れないようにする。 クライアントを切断するのは、 (1)ルーム側から kick する場合, (2)受信エラー, (3)送信エラー の3

    チャットで学ぶ Go ネットワークプログラミング : DSAS開発者の部屋
  • MySQL 5.6 では innodb_flush_log_at_trx_commit の意味が MySQL 5.5 と違う : DSAS開発者の部屋

    MySQL 5.6 では innodb_flush_log_at_trx_commit の意味が MySQL 5.5 と違う innodb_support_xa と binlog の危ない関係 で、 MySQL がトランザクションログのコミットをシングルスレッドでシーケンシャルに fsync していると書いたのですが、誤解だったのでその補足です。 タイトルの通り、 innodb_flush_log_at_trx_commit=1 の場合も、トランザクションログが fsync されません。トランザクションがディスクに書かれるシーケンスは次のようになります。 1. prepare (fsync) 2. write binlog (grouped, fsync) 3. commit このうち 1 は従来通り各スレッドで並列に実行され、 2 と 3 が昨日紹介した sql/binlog.cc の

    MySQL 5.6 では innodb_flush_log_at_trx_commit の意味が MySQL 5.5 と違う : DSAS開発者の部屋
  • WebSocket アプリの負荷分散 : DSAS開発者の部屋

    最近 SPDY と WebSocket がアツいですね。 再来週の SPDY & WS 勉強会 も、定員100名に対して 参加者が 247 名とかなりアツいことになっています。 その予習というわけでもないですが、最近 WebSocket を実サービスへの 導入方法を考えながら遊んでいたので、 WebSocket の負荷分散方法について 考えていることを書いておこうと思います。 ステートフルな WebSocket アプリケーション HTTP サービスは基的にステートレスな実装になっており、リクエストが来るたびに DBサーバーや memcached などのバックエンドから情報を取得して返していました。 この構成では Web アプリ自体は完全にステートレス化することができているので、 負荷分散機はラウンドロビン等のアプリケーションを無視した負荷分散をすることができました。 しかし、 WebSo

    WebSocket アプリの負荷分散 : DSAS開発者の部屋
  • Isucon2参戦記(Q) : DSAS開発者の部屋

    男の戦い recaro が使えないことになってメゲそうになったものの、 やれることがまだまだ残っているのに何もせずに負けるわけにはいきません。 「逃げちゃダメだ逃げちゃダメだ」と呟きながら、残り2時間弱でできそうなことは 全部やってしまいます。 @pandax381 に、リバースプロクシで静的ファイルを直接返す設定、死んだ Web サーバーの 代わりにリバースプロクシと同じサーバーとDB サーバーでWebアプリを動かす設定をお願いして、 Webアプリのチューニングを進めます。 Webアプリ側でやったことは、 (1) Webサーバーの meinheld 化, (2) ページキャッシュを アプリから返すのでその高速化, (3) マルチプロセスの対応とチューニング, です。 (3) のマルチプロセス対応ですが、もともとアプリはシングルプロセスで動かすつもりで、 状態やページキャッシュを全部アプリ

    Isucon2参戦記(Q) : DSAS開発者の部屋
  • Isucon2 参戦記(破) : DSAS開発者の部屋

    #isucon2 参戦記の第二部です。昨日の @methane の記事とオーバーラップする部分もありますが、僕の視点で当日の状況をレポートします。やっと nexus7 が手に入ってご機嫌な @pandax381 です。 決戦、渋谷ヒカリエ 当日寝坊してしまうという笑えない展開もなく、受付け開始と同時に入館し、すぐに @methane と合流。開始時間まで1時間くらい余裕があったので「こんな問題だったらここをこうしよう」といった感じで軽く打ち合わせしていました。 そして、@methane が共同作業用にAWSのインスタンスを上げてくれたので、そこに recaro のソースを持ってきたりしていたら、ちょうどいい時間に。 NHNさんからレギュレーションや注意事項の説明があり、いよいよ #isucon2 スタートです。 事前の打ち合わせ通り、僕はベンチマーク用のツールを走らせながら、どんなHTTP

    Isucon2 参戦記(破) : DSAS開発者の部屋
  • Erlangとは何だったのか : DSAS開発者の部屋

    タイトルは釣りです。 methane です。 8/20(土)にLL Planetesに行ってきました。 今年は JavaScript 一色と言っていいほど、 JavaScript の存在が大きくなっており、 そのなかでも特に Node.js の話題が多かったように思います。 「Node.jsとはなんだったのか」というセッションでは主にコールバックチェーン型プログラミング vs 軽量スレッドを使った手続き型プログラミングの話題や各言語におけるライブラリなどが 紹介されていたのですが、以前個人的な興味でいくつかの言語とライブラリで echo server を実装していたので、他にも興味を持っておられる方のために公開します。 いろんな言語でEcho Server@github 参考に、簡単なベンチマーク結果も載せておきます。各言語・フレームワークで完全に同じものを 実装しているわけではないし、エ

    Erlangとは何だったのか : DSAS開発者の部屋
  • 高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋

    はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか? 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の2倍や3倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立

    高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
    a2ikm
    a2ikm 2011/07/12
    「3と9って、なんかだよく聞く数字だなあと冷静に考えてみると、これってTCPのSYNの再送間隔ではありませんか!」センスが凄すぎる
  • 並列1000コネクションに耐える! Ruby のイベント駆動ライブラリ Rev と EventMachine の HTTPクライアント : DSAS開発者の部屋

    並列1000コネクションに耐える! Ruby のイベント駆動ライブラリ Rev と EventMachine の HTTPクライアント こんにちは、takada-at です。 Rubyのイベント駆動型ネットワークプログラミングフレームワーク Rev と EventMachine で HTTPクライアントを動かしてみました。 イベント駆動型ネットワークプログラミングフレームワークとは何か説明しだすと難しいですが、一言で言うと、以下のようになります。 # ふつうのフロー駆動型プログラム Net::HTTP.start(host, port){|http| res = http.get(path) #この処理が終わってから } puts "done" #この次の処理が実行される # イベント駆動型プログラム client = Rev::HttpClient::connect(host, port

    並列1000コネクションに耐える! Ruby のイベント駆動ライブラリ Rev と EventMachine の HTTPクライアント : DSAS開発者の部屋
  • 届いたメールの料理の仕方 (1) 〜qmail編〜 : DSAS開発者の部屋

    qmailではdot-qmailと呼ばれるファイルで届いたメールの処理を制御できます。典型的なdot-qmailファイルは、ユーザのホームディレクトリの下の~/.qmailや~/.qmail-XXXですね。 今回は、dot-qmailを使う上で知っておきたいことをTIPSを交えて紹介したいと思います。 例として、kbora@klab.org宛てのメールが~kbora/.qmailに届く場合を考えます。 qmailにはextension addressというものがあり、ユーザ名に続けて「-XXX」を指定することができます。例えば、kbora-oboko@klab.org宛てのメールは、~kbora/.qmail-obokoに届きます。このextension addressを活用すれば、管理者の手を煩わすことなくメールアドレスを増やすことができますね。 では、~/.qmail-inaが無い状態

    届いたメールの料理の仕方 (1) 〜qmail編〜 : DSAS開発者の部屋
  • 1