SDCon2024: Enabling DevOps and Team Topologies thru architecture: architecting for fast flow
![DroidKaigi 2016 パフォーマンスを追求したAndroidアプリを作るには](https://cdn-ak-scissors.b.st-hatena.com/image/square/b985ef8dab9287be43bdb71e73546dda323c7132/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fb6d9c2bb763f4726b44fd5c85279a5ab%2Fslide_0.jpg%3F5892959)
Video: https://www.youtube.com/watch?v=JRFNIKUROPE . Talk for linux.conf.au 2017 (LCA2017) by Brendan Gregg, about Linux enhanced BPF (eBPF). Abstract: A world of new capabilities is emerging for the Linux 4.x series, thanks to enhancements that have been included in Linux for to Berkeley Packet Filter (BPF): an in-kernel virtual machine that can execute user space-defined programs. It is finding
速い Python 実装といえば PyPy が有名ですが、 Python 3 へのキャッチアップが遅い、 CPython が持っている Python/C API のサポートがまだ弱く遅い、などの欠点があります。 また、 Google の1年プロジェクトだった Unladen Swallow もありました。これは CPython をフォークして LLVM で JIT を実装するものでした。この fork 実装は終わりましたが、この時期まだ不安定だったLLVMへの貢献は大きく、(ちゃんとおってないので憶測ですが)現代LLVMを利用したJITを実装しているプロジェクトは全部間接的に Unladen Swallow の成果の上に成り立っていると言えるかもしれません。 終了した JIT プロジェクトといえば、 psyco もありました。これはベタに CPython の JIT を実装していましたが、
はじめまして。サーバーサイドエンジニアの中野(@Hiraku)です。2015年12月からメルカリで働いています。 2016年1月27日(水)の第98回PHP勉強会@東京にて、composerを速くする取り組みについて発表をしてきました。 composerはPHPにおける実質スタンダードなパッケージマネージャです。 このcomposer、日本で実行すると非常に遅く感じます。この原因は普通ならこう表現すると思います。 githubやpackagistが日本から遠いから composerの実装がよくないから しかし発表ではあえて「光が遅いから」という主張をしました。 一般常識として、光の速さ(真空中で秒速約30万km)はとてつもなく速いものという認識だと思います。しかし一方で、地球や宇宙の規模など極限的な状況に携わる仕事をしている人であれば「全然速くない、むしろ遅い」というのが普通の感覚です。
まあ、タイトルは若干釣りで、特定のユースケースにおいて3割程度の高速化が見込める、というだけです。 joker1007/curl_escape: This gem provides fast URL escape by libcurl. 以下、実装経緯。 Railsのurl_forを辿っていくと、最終的にクエリパラメーターとして渡したハッシュやらArrayやらに対して、Object#to_queryを発行します。 このObject#to_queryの実装は、ほぼCGI.escapeの実行です。 やたらとlink_toの数が多くて、クエリパラメーターをそれなりに渡している、というページを表示しようとすると、割とこの処理時間が馬鹿にならない感じになってきます。 ということで、CGI.escapeを早くすれば、ちょっとはマシになるんじゃないかと思いました。 しかし、CGI.escapeの実装をR
1. ベンチマーカー プロファイルすると、プロファイル自体に時間がかかるので正しく速度が測れない。そのためベンチマーカーも使うと良い。 ただし、ベンチマーカーはどこが遅いか等の解決の糸口は教えてくれない。 benchmark-ips 2. プロファイラ 実際に速度のボトルネックを見つける際に使う。 stackprof どのメソッドに多くの時間を費やしているかがわかる これを入れても速度にさほど影響がない rblineprof 行ごとにかかっている時間を出してくれる peek-rblineprofを使うとブラウザで結果が見れる ただしプロファイリングに結構時間がかかる (3. NewRelic) 実際、これらのことを手元でやらなくても、特にstackprof的なことや、どこのページやどのSQLクエリが特に遅いかなどは、 New Relic がやってくれます。お金を払うと結構詳細な部分も見れま
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
Webサーバのベンチマークをとるのが趣味になりつつあるmatsumotoryです。 Webサーバのベンチマークについては、abからはじまりwrk等を使っていたのですが、最近ではほぼh2loadを使っています。 h2loadはnghttp2というHTTP/2ライブラリのアプリケーションに含まれているツールですが、 HTTP/2(SPDYも)とHTTP/1.xに両対応している ベンチマーク側の同時スレッド数を増やせる TLS及びSNIもサポートしている 最小、最大、平均、標準偏差あたりもちゃんとでる ので、色々プロトコルを変えつつ同じベンチマークツールで、値の目安を出すにはとても重宝しています。 Nghttp2: HTTP/2 C Library - nghttp2.org 実行結果のサンプルは例えば以下、 $ h2load -c 100 -n 10000 https://localhost:
Goodpatch CTOの id:sadah です。 これはGoodpatch Advent Calendar 2015の25日目のエントリです。 Prottというサービスではパフォーマンスチューニングのために、Railsアプリケーション/フロントエンドの改善、ミドルウェアのバージョンアップ、SPDYやHTTP/2の導入、オンプレミス環境からAWSへの移行などを行ってきました。 今回はその取り組みの一部をご紹介します。 Slides 10月にGoodpatch Engineer Meetupというイベントをやって、Prottのパフォーマンスチューニングについて話した。 Goodpatch Engineer Meetup Vol.1 - connpass イベントの内容はこちらにまとまっている。 Goodpatch Engineer Meetup Vol.1を開催しました | MEMOPA
明日から RubyKaigi なので、ちょっとした小ネタを一つ。 例えば、0 から 9999 までをハッシュに順に入れます。 h = {} 10000.times do |n| h[n] = true end このとき、h[9998] や h[9999] は、h[0] や h[1] より高速です。 どのくらい高速かというと、 1_000_000_000.times { h } # 40.8 sec (ループ自体の速度) 1_000_000_000.times { h[9999] } # 57.2 sec 1_000_000_000.times { h[0] } # 89.1 sech[0] は 89.1 - 40.8 = 48.3 nsec 、h[9999] は 57.2 - 40.8 = 16.4 nsec ということになります。なんと 3 倍も速い。*1 なぜこんなことが起きるのか ハ
「Matzから、Rubyパフォーマンスのポイントを教えてもらおう!会議」レポート #matz_1031 こんにちは、開発2年目エンジニアの 岩﨑 俊貴 です。 2015.10.31(Sat)13:00-15:30 @渋谷クロスタワー32F CTカンファレンスルームにて 弊社顧問、Rubyの作成者まつもとゆきひろ氏をはじめ、 株式会社Ruby開発 開発室室長 柴田有一郎氏 株式会社Speee サーバサイドスペシャリスト 西岡寛兼氏 にお越しいただき、勉強会を開催いたしました。 ここでは当日のスライドをまとめてご覧いただけます。 当日ご協力いただきました皆様、 また、お越しいただきました皆様、誠にありがとうございました。 Index Rubyのパフォーマンスはどこまで上げられるか。あるいはRubyは本当に遅いのか? (まつもとゆきひろ氏) Benchmarkspec (株式会社Ruby開発 開
vboxsfを速くするために頑張る記事の2本目です。 前回は、findコマンドが遅いことを調べ、速くすることができました。 今回は、VirtualBoxのファイルシステムvboxsfと、VMWareのファイルシステムvmhgfsの違いをもっと調べていきます。 vboxsfとvmhgfsの速度を比較している記事としては、Comparing Filesystem Performance in Virtual Machinesが、わかりやすくまとまっていました。 この記事を見ると、 sequential readで、vboxsfでは100MB/s、vmhgfsでは500MB/s random readで、vboxsfでは100MB/s、vmhgfsでは7GB/s と、速度の差が大きいことを指摘され、さらには、 Because the deviation of the VirtualBox thr
railsアプリが遅いって言われたので、久しぶりにrubyでisuconしてみました。 railsアプリでstackprofを使ったプロファイリング まず、自分がいつもやってる方法なのですが、config.ruにstackprofの設定を仕込みます。 stackprofはrackミドルウェアとして差し込めるようになっています。 下記設定はrailsだけでなく、sinatraでももちろん動きます。(これをいつも仕込んでおいてあります。) Gemfileにgem 'stackprof'を書いてconfig.ruに下記のように仕込んでいます。 is_stackprof = ENV['ENABLE_STACKPROF'].to_i.nonzero? stackprof_mode = (ENV['STACKPROF_MODE'] || :cpu).to_sym stackprof_interval
こんにちは。技術部の吉川です。 クックパッドでは、ユーザーが快適にサービスを利用できるように本番環境でのパフォーマンスを向上させるための様々な工夫がなされています。 ところでパフォーマンスを気にするのは本番環境だけで良いのでしょうか? 開発環境に目を向けると、そこにもユーザーがいます。開発者です。開発環境のパフォーマンスが向上することで、開発者が快適にサービスを開発できるようになります。 今回はそういった開発環境でのパフォーマンス向上のための取り組みについてご紹介します。 ※ なお先日 Ruby2.2化されました が、今回紹介するものはそれ以前に実施されたため、Ruby2.2で同じ結果になるとは限りません。 状況 今回対象とするのはcookpad.comのアプリケーションです。 近年はMicroservices化を進めていますが、それでも本体のレシピサービスのアプリケーションは依然として非
逆に言うと、Rubyの文字列型の内部実装がropeになれば、freezeしてもしなくても変わらない速度が出るようになって、結局freezeする必要なんてなかったんやーで丸く収まるんじゃないの?と思いました #雑な感想 — Kazuho Oku (@kazuho) October 6, 2015とツイートしたところ、処理系の中の人から @kazuho 文字列を弄る話じゃなくて、文字列の identity の話なので、ちょっと関係ないかなぁ、と — _ko1 (@_ko1) October 6, 2015みたいなツッコミをもらって、うっすみません…ってなってRuby VMのコードを読むことになったわけです。 で、まあ、いくつか気になる点があったので手をつけてしまいました。 1. オブジェクト生成のホットパスの最適化 ホットスポットだとされていたところのコードを読んでると、オブジェクト生成の際に
Web fonts are great. They are also be really bad for front-end performance because they block rendering. You may have experienced this on a slow cellular network. Staring at a blank page is no fun, especially when the content has already loaded. This talk explores why browser have placed fonts on the critical path, and how we can work around this while still delivering a good user experience. It a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く