WebAssemblyとJavaScriptのパフォーマンス比較(再帰・ループ) - QiitaHelp us understand the problem. What is going on with this article?
Erlangパフォーマンス・チューニング - Qiita
-module(httpd_tcp_listener). -export([start_link/0]). start_link() -> Pid = spawn_link(fun init/0), {ok, Pid}. init() -> Port = 8888, Backlog = 10244, Options = [binary, inet6, % support both ipv4 and ipv6 {active, false}, {reuseaddr, true}, {backlog, Backlog} ], {ok, Listen} = gen_tcp:listen(Port, Options), accept(Listen). accept(Listen) -> case gen_tcp:accept(Listen) of {ok, Socket} -> {ok, Pid}
MySQLパフォーマンスチューニング -クエリキャッシュ適用状況の確認- - Qiita
花粉真っ盛り。 もれなく花粉症MAXな日々を過ごしております。 まみーです。 前回のエントリーからの続きになります。 MySQLパフォーマンスチューニング -my.cnfの見直し- 今回は、前回の設定結果の中から、クエリキャッシュの効き具合を測定・検証していきます。 概要 my.cnf に設定した内容のうち、クエリキャッシュについて検証します。 前回の設定変更から1週間経過した時点での値の比較となります。 目的 設定されていなかったクエリキャッシュが適切に効いているのかを検証し、設定が妥当かどうか判断します。 問題点 サービスの運用上、以下の問題点があります。 変更できない テーブル構成 リクエストごとに増え続ける ログレコード 必要な リアルタイム検索機能 状況 クエリキャッシュ設定前の状況は以下でした。 リアルタイム検索を 複数実行するとサーバーが落ちる 1プロセスでも 応答に30秒
MySQLパフォーマンスチューニング -my.cnfの見直し- - Qiita
※RDSは使っていません。 負荷を見てみる DBサーバーの負荷状況を見てみます。 当時の監視ツールの画像がないのですが、以下の状況でした。 LA(Load Average)が突き抜けている リクエスト数は「常識的に考えて」それほどでもない メモリの使用量にあまり変化がない swapはしていない ストレージ容量を結構食っている WEBサーバーから見れば、処理待ちのままプロセスが処理されていない典型的なパターンだったと思います。 DBサーバーとしては、LAに対し、メモリの使用量があっていないように思われました。 仮説 上記の状態から、仮説を立てます。 スロークエリ が頻発しているのではないか メモリ が正しく割り当てられていないのではないか 各種ログ の設定が適切ではないのではないか 仮説を検証することで、対策をしていきます。 設定を見直す 上記の仮説の設定は、MySQLの設定ファイルである「
Ruby on Railsで作ったWebサービスを5倍速くしてメモリを半分以下にした話 - Qiita
表示速度の高速化が趣味のzaruです。こんにちは。今回はRuby on Railsで作られた弊社Webサービスの表示速度を約5倍ほど速くしたので、何をしたのかをまとめました。Railsの高速化手法はいたるところで語られていますが、気にせず行きます。 前提や結果など アーキテクチャとしてはわりと一般的な AWS ELB -> nginx -> Unicorn / MongoDB という構成です。 |改善前|改善後 ---|---|--- Ruby|2.1|2.3 Rails|4.1|- MongoDB|2.6|3.2 Redis|2.4|3.2 Ruby・MongoDB・Redisのバージョンアップ、Railsもバージョンアップしたかったけど依存ライブラリの関係で据え置きになりました。 |改善前|改善後 ---|---|--- ページ読み込み速度|8.49sec|1.69sec 秒間リクエス
gatling による負荷試験とテレビ露出見積り - Qiita
表題の通りですが、本記事では次の事項は扱いません。 gatling の使用方法 目的 テレビ露出時にかかる負荷をある程度予測しておくことで、それにかかる費用をできるだけ小さく留めること（最小化とは言いません）。 最小化しようとするとギリギリのラインを攻めるためにかなり厳密に見積もらないといけなくなりますが、そうすると人件費の方が高くつくので本末転倒です。 その計算をするのに僕のリソースをもって 1日かかるなら、1〜2万円多く AWS や GCP に献上した方が他の仕事も進められてみんな幸せです。 従って、本記事での検証は比較的ざっくりです。 構成 本試験は、以下の様な構成のアプリケーションを対象に行います。 AWS 特に特筆すべきことのない、標準的な構成です。 DNS とかはあまり関係ないので抜いています。 Amazon ELB Amazon EC2 Amazon RDS（MySQL、マス
Crystalで書く → はやい - Qiita
def fib(n) return n if n <= 1 fib(n - 1) + fib(n - 2) end puts fib(40) #50だとrubyの実行時間がかかりすぎたため
Linux負荷監視コマンドまとめ - Qiita
※収録パッケージ名はAmazon Linuxの場合 procpsは数年間動きがなかったのでprocps-ngというプロジェクトがフォークした。ディストリビューションによってはprocps-ngが入っているかもしれない。 最低限覚えるべきはvmstat vmstatは多くの環境で標準でインストールされており、表示項目もメモリ・スワップ・IO・CPUと一通りそろっている。 vmstat 2で2秒ごとに表示される。 -tをつけると時刻も表示される。 $ vmstat -t 2 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp--- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 1 0
Apache Thrift 速度比較 - Qiita
動機 とある業務で使っている MessagePack-RPC に代わる RPC を探している RPC framework でグーグル先生に聞いたら gRPC と Thrift が上位に表示された gRPC は別の機会で別途比較する そもそも gRPC で使われている Protocol Buffers の 3.0 が Beta 版なので色々環境構築が大変なのが本音 業務で使うのに Beta ってのはちょっと抵抗があるのでモチベーション低下 とは言えど Go は比較的楽だったので頑張った Java も頑張ったが非常に大変だった Ruby はこの問題があって Gem を入れられない 概要 クライアントは Java で、サーバは以下の言語でそれぞれ開発 Java Ruby Go テストは巨大データ送信を10回繰り返した際の平均を取る 巨大データは50000件のハッシュ 結果（単位は秒） 考察 Ja
サーバ監視・性能測定ツールまとめ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? エージェントソフトウェアを対象PCにインストール形でサーバの監視・性能測定を行うツールのまとめ。 SaaSサービス NewRelic アプリケーションの性能測定が簡単にできるSaaS。あちこちで導入実績があってスタートアップではデフォルト担っているようにさえ感じる。各言語でのプラグインだけがあって、自作アプリ外のサービスは対象外なのかと思っていたが、プラグインのリストをみると色々と対応しているようだ。 Good 豊富な実績がある Bad インターネットにつながっていないと利用できない。 参考リンク New Relic Wantedlyを
MySQL InnoDBのIndex - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? mysqlのInnoDBではclustered indexというのを採用していて、indexを貼る際に注意が必要ということでメモ 結論から言うと InnoDBでは... Primary Key(以下PK)はできるかぎり設定して、できるかぎりauto_incrementの整数型が良い PKの検索は速いが、secondary indexやcount(*)での検索は若干遅い PKのupdateは避ける 無闇やたらとsecondary indexを付けない covering indexを狙えると速い かんたんに解説 図とか用意したかったけど気力
12章 Index Shotgun(闇雲インデックス) - Qiita
CREATE TABLE Mikosan ( miko_id SERIAL PRIMARY KEY, date_joined DATE NOT NULL, description VARCHAR(128) NOT NULL, status VARCHAR(10) NOT NULL, hours NUMERIC(9.2), INDEX(miko_id), INDEX(description), INDEX(hours), INDEX(miko_id, date_joined, status) ); mysql> show index from Mikosan; +---------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+----
StackProfを使ってrubyプログラムのプロファイリングをする方法 - Qiita
計測エンジニアになろうとしたら苦労したという記事を技術ブログに書いたのですが、技術的な部分を備忘録も兼ねてまとめておきます。 Spring_MTさんのブログには大変お世話になりました。(というかREADME + このブログ記事のまとめでしかないような、、、汗) profilingとは プログラムが実行された際、どの部分のコードの実行にどれだけの時間がかかったのかを計測することです。 ではなぜ人はプロファイリングするのでしょうか？ プロファイリングはパフォーマンスのボトルネックを発見し、”遅いプログラムを速くする”手助けになります。プログラムの中で無駄に何度も呼ばれている部分、不要なのに呼びだされている部分、不自然に遅い部分を発見すれば、それを効率化することでプログラムの実行を速くすることができます。 StackProfとは Rubyプログラムのプロファイリングに関してはいくつかのツールがあ
Ruby/Railsでの高速化の際に使うgem達 - Qiita
1. ベンチマーカー プロファイルすると、プロファイル自体に時間がかかるので正しく速度が測れない。そのためベンチマーカーも使うと良い。 ただし、ベンチマーカーはどこが遅いか等の解決の糸口は教えてくれない。 benchmark-ips 2. プロファイラ 実際に速度のボトルネックを見つける際に使う。 stackprof どのメソッドに多くの時間を費やしているかがわかる これを入れても速度にさほど影響がない rblineprof 行ごとにかかっている時間を出してくれる peek-rblineprofを使うとブラウザで結果が見れる ただしプロファイリングに結構時間がかかる (3. NewRelic) 実際、これらのことを手元でやらなくても、特にstackprof的なことや、どこのページやどのSQLクエリが特に遅いかなどは、 New Relic がやってくれます。お金を払うと結構詳細な部分も見れま
HiPE(High Performance Erlang)について - Qiita
日本語でHiPEについて触れている文書が少ない気がしたので、自分が知っている範囲の情報を取り留めもなく書いてみた。 ※ 経験ベースで書いているため情報の網羅性や信頼性にはあまり期待しないでください HiPEって何？ 「High Performance Erlang」の略。 HiPEコンパイラはOTPが提供する標準アプリケーションの中に含まれている(OTP17.3現在)。 HiPEコンパイラを使うと、ErlangのソースコードをVM(beam)のバイトコードとしてではなく、ネイティブコードとしてコンパイルしてくれる。 (JavaのJITコンパイラのように、実行時にネイティブコードへの変換を行なうわけではない) そのため、速度を重視したい(けどCで書く程ではない)モジュールを実装する場合に、HiPEが手軽な高速化の手段として重宝することがある。 HiPEを有効にするには ソースコードから自前で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/takashibagura/items/38588c5b6a80faf25be0
Unityで実行時間を計測する - Qiita
pythonの内包表記を少し詳しく - Qiita
rack-mini-profilerの計測結果がWebページに表示しないようにする - Qiita
誰も教えてくれなかったMySQLの障害解析方法 - Qiita
