![strace コマンドの使い方をまとめてみた : sonots:blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/da78a05937633f7a2b4b2219826151c370cd607b/height=288;version=1;width=512/https%3A%2F%2Fparts.blog.livedoor.jp%2Fimg%2Fusr%2Fcmn%2Fogp_image%2Flivedoor.png)
2017/06/30(金)に開催した『第一回社内ISUCON』のレポートです。 あいさつ 社内ISUCONについて ISUCONとは 企画〜準備 問題/ポータルサイトの用意 Scala実装の用意 インフラの用意 当日の様子 集合〜ルール説明/サーバー配布 チューニング ベンチマーク実施 開催してみて まとめ あいさつ こんにちは、 @ocadarumaです。 おもに広告効果計測ツールの開発/運用などをやっています。 最近はちょっとRustにハマってまして、GC無しで参照を適切に管理することの難しさを噛み締めています。(でもコンパイル時に検出できるのが素晴らしい) Cargoやrustupなどのツールもよくできていて、Rustには未来を感じざるを得ません。 社内ISUCONについて オプトテクノロジーズでは定期的に社内ハッカソンを開催しており、その日は1営業日を丸々使って、各々業務を改善する
この記事は、はてなエンジニアアドベントカレンダー2016の12月18日の記事です。 はてなエンジニアアドベントカレンダー2016を始めます - Hatena Developer Blog 昨日はid:ikesyoさんの「オープンソース活動への取り組み方」でした。 オープンソース活動への取り組み方 - Hatena Developer Blog こんにちは。はてなでWebオペレーションエンジニアとして働いているid:taketo957です。 2016年の4月に新卒として入社してからは、社内の仮想化基盤のリソース最適化に取り組んでみたり、 speakerdeck.com 社内の広告配信システムの刷新プロジェクトに関わってきました。 speakerdeck.com 本記事では広告配信システムの刷新を行う中で取り組んだ負荷試験環境を構築する際に考えたことと「継続的にパフォーマンス改善を行うためには
この記事は Go Advent Calendar 2015 その2 の 15日目の記事です。 先日、5倍の高速化を実現した高速検索ツールThe Platinum SearcherのV2をリリースしました。 今回は、高速化にあたり工夫した点をまとめておこうと思います。 The Platinum Searcherの基本実装について 以前、GoConferenceで発表した資料にまとめてあるので、興味のあるかたはご覧ください。 基本的にはFind、Grep、PrintのGoroutineがそれぞれの結果をChannelを経由して渡すつくりになっており、それぞれのGoroutine内で並行で処理を行うために更にGoroutineを起動しています。 ボトルネックの調査 今回は完全書き直しだったのでボトルネックを潰していくという手法ではなかったのですが、再実装にあたり、気をつけるべき点を確認する上でも
Sam Saffron Programming, Technology and the Art of Hacking Recently Godfrey Chan got Discourse working on Rails Master. It was a rather long task that involved some changes to Discourse internals and some changes to Rails internals. Knowing Rails 4.2 was just around the corner I decided that it seemed like the perfect time to see how performance is. Seeing Rails 4.2 contains the adequate record pa
Help us understand the problem. What is going on with this article? Rails3.2からRails4.2に上げたらActiveRecordが遅くなったので、どうやって調査して、どのように対処したかを語ってみたい。 とても長いので、ダルい人は最初と最後だけ読めばよいです。 TL;DR 環境: Ruby 2.1.5 ARオブジェクトを大量に(ざっくり750kくらい)loadするバッチ処理 3.2系での実行時間は約480sec、 4.2系では約2900sec 約6倍の性能劣化 原因: preloadで性能劣化してた CollectionProxyの生成周りで遅くなってた Rails4からARオブジェクトの1attribute毎にObject生成するので遅い GCの時間も増えた 調査方法: Githubのcommit、Issueを
LMAXという会社はおそらくFX業者で、筆者はLMAXの開発者の講演を、InfoQの動画で何度か見たことがあった。 彼らは非常に特異な集団で、さしずめ「Javaのスピード狂」という感じだ。 印象的なのは、シングルスレッドで仕事を片付けることを強調している点だ。 「Javaならマルチスレッドで並列処理すれば性能が出ると広く思われているが、我々の仕事においてはシングルスレッドが最速だ」というような主張を何度も見た。 ゴールドマンサックスといいLMAXといい、やはり多額の金が動く会社でガチでJavaをやっている連中はカリカリにチューニングするため、技術的には非常に面白い。 彼らがコアのライブラリをOSS化してくれるというのは、金融業界を否定的な目で見る筆者からすると複雑だが、悔しいことに参考になる。 LMAX DisruptorはJavaのライブラリだ。Producer/Consumerパターン
RubyKaigi 2014行った。良い発表がいろいろ聞けたんだけど、最近ISUCONに向けてwebアプリのチューニングに興味があったので特にfinal keynoteが興味深かった。 その中で紹介されていたtmm1/rblineprofが行ごとの実行時間を表示してくれるのでとても便利そうだったんだけど、GitHubではpeek/peek-rblineprofというRails用のプラグインでrblineprofを活用しているので、ISUCONでおそらく使用されるであろうsinatraでどうやって使うか考えていた。 kainosnoema/rack-lineprofというgemがその用途に便利そうだったので紹介したい。 使い方 rack-lineprofはRack middlewareで、まず以下のようにuseする必要がある。 require 'rack-lineprof' class My
JMeterはとても強力なツールなんですが、UIがいまいち(ですよね?)なのとテストケースがXMLなので、あまり積極的に使っていませんでした。 しかし、どうしてもJMeterを使わざるを得ないケースが出てきて*1、GUIツールとXMLを避ける方法をいろいろと探していたところ、ruby-jmeterがというライブラリが見つかりました。 ruby-jmeter https://github.com/flood-io/ruby-jmeter Tired of using the JMeter GUI or looking at hairy XML files? はい、疲れました…というひとのためにRubyのDSLでjmxを出力 or JMeterを実行してくれます。 require 'ruby-jmeter' test do thread_group count: 3, duration: 60
More than 5,000 organizations count on our digital courses and more to help their teams learn the tools and technologies that drive business outcomes. We can help yours too. New AI policy for O’Reilly authors and talent O’Reilly president Laura Baldwin shares the company’s ethical approach to leveraging GenAI tools and ensuring O’Reilly experts are compensated for their work. Read it now It’s time
Effectively managing memory at Gmail scale Stay organized with collections Save and categorize content based on your preferences. Introduction While JavaScript employs garbage collection for automatic memory management, it is not a substitute for effective memory management in applications. JavaScript applications suffer from the same memory related problems that native applications do, such as me
Web アプリケーションのパフォーマンスにうるさいみなさんこんにちは。 Rails アプリのパフォーマンスプロファイリングだと、 rack-mini-profiler が有名で、それ以外だと New Relic とかを使って測定していくのが普通のようですが、物足りない部分があったので、自前でプロファイラ gem を作りました。 Rubygems: http://rubygems.org/gems/speed_gun / Github: https://github.com/rosylilly/speed_gun 詳細は Github の README なんかを見ていただくとして、基本的には rack-mini-profiler 的な情報収集が出来ると思ってもらって差し支えないです。 ちなみに計測画面はこんな感じ。 大きなスクリーンショットはこちら 小さくて何も見えないかも……とりあえず3セ
linuxサーバのOS全体に効くカーネルパラメータのチューニング箇所と その設定値、またその理由をまとめておく。 あくまで自分の環境ではこうした、というだけであり、 提供するサービスごとに検討が必要である。 どこをどう変更するのか、または変えないのか、その判断材料にはなるだろう。 ※ユーザ単位でシステムリソースに制限をかける場合をこちらを参照してほしい。 以下は/etc/sysctl.conf で設定するものとする。 ● 大規模サイト用チューニング kernel.pid_max 動作:pidの最大数 設定値:131072 理由:pidを枯渇させない vm.max_map_count 動作:mmapやmalloc時にメモリを仮想空間にマッピングできる最大ページ数 設定値:300000 理由:マッピングできなくなる事態を防ぐ net.core.somaxconn 動作:接続(ソケット)キューの
JOIN 禁止の話に、いまだに絡んでくれる人がいた。 ■「艦これ」から、ソーシャル系のサーバ構成を考える - SQLer 生島勘富 の日記 僕が以前に書いた本テーマに関するエントリは以下の3つ。 ■信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設 ■信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 ■ホント信じられないDB文化だけど、統計情報固定化はマジでアリ ちょうど折よく、ウチの会社のオラクル女子が書いたエントリの続きも公開されました。 ■一緒にまなぼ!「hiromi と楽しむOracleパフォーマンスチューニング!」【Vol.2 Statspackを見てみよう】 ということで僕の中でDB熱が盛り上がってきたので返答的なエントリを書きます。 「とりあえずメモリだけ気にしておけ」
Rich Tracing Choose what methods to trace and add custom data to each event. Track asynchronous flows and actions. Slick Visualization Smoothly dig through millions of events in an awesome UI. See patterns and understand your code like never before.
本ブログでは、サイトの高速化に直結する「JavaScript 非同期読み込み」の話題を多数取り上げてきました。タイトルに釣られてこの記事を見てくれている方なら Google Analytics の非同期コードスニペット はご存知でしょうし、規模の大きいサイトやアプリ用に RequireJS などのフレームワークを使っている方もいるでしょう。 GA も RequireJS も、動的に生成したスクリプト要素を DOM に埋め込む「DOM 挿入法」が用いられています。さらに遡れば、Steve Souders が 2009年4月の記事 ノン・ブロッキングなスクリプト読み込み で、6つの手法に分類しています。 果たしてこれらの方法は、サイトの高速化にとってベストなのでしょうか? 答えは2012年12月の海外記事にありました。そこで本エントリーでは、日本ではほとんど取り上げられていない Frame i
I’ve had an unusual number of interesting conversations spin out of my previous article documenting that mobile web apps are slow. This has sparked some discussion, both online and IRL. But sadly, the discussion has not been as… fact-based as I would like. So what I’m going to do in this post is try to bring some actual evidence to bear on the problem, instead of just doing the shouting match th
yajl(Yet Another JSON Library)っていう高速なJSONライブラリがあって、 yajl こいつをrubyから使えるようにするyajl-rubyってgemがあって、これをMultiJsonのBackendに変更することで、RailsにおけるJSON処理の高速化が期待できるデス。 brianmario/yajl-ruby · GitHub 素のjson.gemと、yajl-rubyとで適当なActiveRecordオブジェクトからJSONへのエンコードと、その逆のデコードで簡単にベンチってみると、約2倍の差があることが分かる。 -------------------------------------------------------------------------------- Benchmark of json encoding/decoding json_
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く