Amazon Auroraを始めるためのパラメータ資料 | 外道父の匠
Auroraがそこそこ浸透してきたように感じなくもないですが、そのわりに情報がまだ少なめなのは、それだけ従来のMySQLと変わりなく扱え、性能も十分満足いくものだろう、という証なのでしょうか。 中の人も、パラメータチューニングは済んでいるので、基本的にはスケールアップで対応してください、と申しているように、かなり良い調整がされているようです。しかし、インフラエンジニアというかエセDBAたるもの、何がどう調整されているかを具体的に確認しなくては気がすまないため、整理してみたわけです。 デフォルトの設定 パラメータグループについて Auroraのパラメータは従来と異なり、ノード毎の設定である『DB Parameter Group』と、クラスタ内共通の『DB Cluster Parameter Group』の２つに設定が分かれます。 必要に応じてクラスタの方に、文字コードやレプリケーション周りな
手軽に負荷テストができるツール「Taurus」がスゴい
modules: jmeter: version: 5.4.1 # ここに書いてあるバージョンを勝手にダウンロードしてくれる properties: log_level.JMeter: WARN log_level.JMeter.threads: WARN system-properties: org.apache.commons.logging.simplelog.log.org.apache.http: WARN 既存ツールのラッパーとして動作 デフォルトでは内部的にJmeterが実行されますが、以下のようなツールで作成されたスクリプトを流用することが可能です。 JMeter Gatling Locust Selenium Vegeta つまり、さきほどはYAMLでシナリオが記述可能とは言いましたが、もちろん既存のスクリプトを流用できるってことです。 いままで作り上げてきたスクリプトや
Reactのサーバサイドレンダリングとパフォーマンスについてのメモ - Qiita
Reactのサーバサイドレンダリングとパフォーマンスについて調べてたのでメモ 基本的なこと サーバサイドとReactのproduction build 要約: Reactをサーバサイドで使うときも、クライアントサイドのように圧縮(というよりはcode eliminate)しないと遅い Reactはdev向けのコードを大量に含んでいる。 これはprocess.env.NODE_ENV !== 'production'の時実行されるassertや警告などが主となりproductionには必要ない。 そのため、process.env.NODE_ENV = 'production'をしないとかなり不利な結果を得る。 I tend to agree that "compiling server side code with webpack to remove access to process" i
Reactを使ったプロダクトのパフォーマンスを改善した話 | GMOメディア エンジニアブログ
技術推進室の色川です。 ここ一年くらいランキングシェアというキュレーションメディアのフロントエンドを担当しています。その記事作成画面をReactで実装しており、先日アイテムの移動をDrag&Dropで行えるようにしたのですが、動きはガクガク、ブラウザは途中で固まる、という有様で、パフォーマンスチューニングを余儀なくされたのでその内容を紹介します。 ［ランキングシェアの記事作成画面］ ※画面は開発中のものです。（動画にしたら？との意見があったのですが、Windowsで画面を録画する方法が分からず…） Reactのパフォーマンス改善の基本Reactはコンポーネントをツリーとして管理していて、あるコンポーネントの更新が必要になるとそのコンポーネントをルートとするサブツリー全体を更新します。 引用元：Reactive, Component-based UIs with React | Consta
逆引き！フロントエンドのイマドキパフォーマンス改善 - 青空コメントアウト
WebアプリにしろWebサイトにしろパフォーマンスはとても重要です。どんなに高機能であっても、どんなにデザインが良くても、パフォーマンスが悪ければユーザーは離れてしまいます。 とは言え現場はキツキツのスケジュールで、パフォーマンスにまでこだわる余裕がないよ！パフォーマンスはひとまずできる限りのところまで頑張るよ！となってしまうこともあるかと…。 この問題の解決の糸口はパフォーマンスを良くする手段をどれだけ知っているかです。仕様を決めるとき、デザインを決めるとき、実装するとき、それぞれのフェーズでパフォーマンスを常に意識していると自ずとハイパフォーマンスに近づきます。 というわけで今回はフロントエンドの観点から、イマドキのパフォーマンス改善手法をまとめてみました。イマドキと謳っておきながら2年前くらいの技術が出てきたりして最新の話題でもないのですが。 ちなみに、本題に入る前にWebパフォーマ
dresscording.com
dresscording.com 2019 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
Ruby on Railsで作ったWebサービスを5倍速くしてメモリを半分以下にした話 - Qiita
改善前に比べ約5倍表示速度が速くなりました。また、1秒間にさばけるリクエスト数も約3倍ほどになっています。Unicornの1プロセスあたりが使用しているメモリもだいぶ低くなりました。 なお、ページ読み込み速度は、ブラウザでページを表示したときにインジケータのクルクルが止まったときです。Chromeの開発ツールのネットワークタブで赤い文字で Load 1.2sec とか表示されているやつです。GoogleAnalyticsのページ速度でいうと plt というキーでレポートされているものです（参考ページ）。 グラフとか GoogleAnalyticsのグラフです。読み込み時間が下がっています。 メモリ使用量です。Zabbixからmackerelに乗り換えたのでグラフが違いますが、使用量が下がって安定しているのがわかります。 AWS ELBのレイテンシです。不安定なレスポンスが安定してるのがわか
AbemaTV の番組表リニューアルに伴うパフォーマンス改善 - Qiita
以前の番組表 ↓↓↓ AbemaTV 新番組表 大きく変わったところ チャンネルが横スクロールですべて見れるようになった サイドバーにチャンネル一覧ができた 日付切り替えがセレクトボックスからカレンダー表示になった etc. 今まではチャンネルが 5ch 毎に区切られていたので、わざわざページを切り替えて見ないといけなかったのを、横スクロールですべてのチャンネルが一覧で見られるようになりました。 さらにチャンネル毎の番組表にもアクセスしやすくなり、日付の切り替えもしやすくなったかと思います。 このリリースによって、ユーザービリティが少しでも向上していれば幸いです。 しかし、便利になった反面、このリリースに至るまでに、パフォーマンス面で様々なところで問題になりました。 今回は実際にリニューアル中に課題となった箇所と解決方法の一部を紹介します。 AbemaTV 以外であまり参考にならないかもし
負荷試験をしよう！ / ServerStressTest
GameServerDevelopers Vol.1の登壇資料です。 https://gsdevelopers.doorkeeper.jp/
AbemaTVのランタイムパフォーマンスのAudit - 1000ch.net
2016.05.17 AbemaTVのランタイムパフォーマンスのAudit 最近業務で、巷で話題のAbemaTVのパフォーマンス改善をしている。個別具体性が高いが調査改善の雰囲気を感じ取ってもらえればそれで良いかと思い、記事にした。 AbemaTVのフロントエンドの構成 話の前提となるAbemaTVのフロントエンドの構成は次の通りで、まさに流行りのといった感じ。 facebook/react facebook/immutable-js Reactive-Extensions/RxJS reactjs/react-router css-modules/css-modules ビルド周りはbabelとwebpack、あとはlintツールがちょこちょこ入ったりしている。この改善の話と関係してくるのは、ReactとImmutableJSとRxJSだけ。 番組再生画面のコメント開閉が重い 今回ケース
サーバの負荷テストのための、何百万ものHTTPリクエストを発生させる方法 | POSTD
(注記：6/9、いただいた翻訳フィードバックを元に記事を修正いたしました。) 今回の記事は毎秒300万ものリクエストを処理できるほど強力で高性能なWebクラスタの構築についてのパート1になります。まず初めに、あまり多くはありませんが、私がこれまで使用したことのあるロードジェネレータツールをいくつか紹介します。私のようにてこずって時間をかけてしまわないよう、今回の記事が理解の手助けになれば幸いです。 ロードジェネレータはテストを目的とした数種類のトラフィックを発生させるプログラムです。それによって高負荷においてサーバがどのように動いているか、そのサーバの弱点はどこなのか、などが見えてきます。負荷テストを通じてサーバの限界を知ることは、サーバのレジリエンシーを測定する最適な方法であり、あらゆる問題に対する準備の手助けにもなります。 ロードジェネレータツール 負荷テストをする際に頭に入れておくべ
挫折から始まるプログラム開発奮闘記～フルスタックエンジニアを目指して～ fastutilを使った高速化の検討
SEとして、数年。。。技術力で食べていきたい！！ という思いと、なかなか最新の技術はWEBで調べても わからないこともあるってことで、同じように困っている人がいるかも と思い設立しました。 どうもどうも、ゆきむです。 前回までで、超導入部分の話ではございますが、 Mavenのインストールからeclipse上での簡単な利用方法までを紹介させていただきました。 Mavenを使うとライブラリ管理がすごく楽になるので、世の中にある便利なライブラリを 使ってみようかな？という気持ちの閾値が低くなったものと思います。（少なくとも私はそうなりました。） そのままの流れで幾つか、Javaのライブラリを紹介していきたいと思います。 今回は、fastutilというライブラリについてです。 Javaのオートボクシング・オートアンボクシングの落とし穴 Javaをやっている皆様は、おそらくオートボクシング・オートア
JMeterとJUnitとMavenで独自プロトコルサーバーの負荷テストを自動化するぞ | GREE Engineering
こんにちは、インフラストラクチャ本部の@nagaseyasuhitoです。このエントリは GREE Advent Calendar 2014 10日目の記事です。昨日はイケメンmoritaさんによる男性エンジニアリングマネージャが長期育休を取った話でした。 エンジニアブログのアカウントは2年くらい前からあるのですが、これが初エントリになります。グリーでは比較的珍しいJavaEEを始めとしたサーバーサイドJavaアプリケーションの開発、SolrやHadoopといったミドルウェアの周辺機能開発や運用などを行っています。どうぞよろしくお願いします。 最近はPvE/PvP/GvGなどユーザー同士がリアルタイムに協調プレイする際、クライアント-サーバー間を常時接続通信で行うゲームが増加しています。このような場合はHTTPのREST APIなど慣れ親しんだプロトコルでは要件を満たしきれないため、Web
パフォーマンス監視サービスのNew Relicが超便利な件 - Qiita
12/09/05 監視対象のWebサービスのURLを間違えていたため修正しました RailsのAdvent Calendarを待ちわびていました． 今回は，WEB+DBの最新号のRails高速化記事で紹介されていたパフォーマンス監視サービスのNew Relicを使ってみた話です． New Relicは．newrelic_rpmというgemをインストールすることにより，レスポンスタイムやスロークエリなど，パフォーマンスに関するさまざまな統計情報をNew Relicのサイトでみることができます． Railsに限らずPythonやJavaなどいろいろな言語に対応しているようです． さらに，HerokuやDotCloudなどのPaaSにも対応していてやばい． HerokuのNew Relicプラグイン Herokuにホストしたアプリケーションを監視するためにはNew Relicプラグインを導入する
Gree Fast Processor: PHPを3倍(くらい)速く | GREE Engineering
ごあいさつエントリだけというのもなんなので、引き続きfujimotoです。実質上1つめのような気がするこのエントリでは、PHPが3倍くらい(少なくとも2倍くらいは...)速くなるGree Fast Processorというのを先月作ってみたのでご紹介です。 すぐわかるまとめ Gree Fast Processorというのを使ってみると、シンプルなsymfonyのプロジェクト(xav.ccで試しました)でも2倍弱、結構複雑なアプリケーションだと7倍くらい速くなったりします。いくつかの制約がありますが、パフォーマンスに飢えているかたはお試しください。 こちらはなんかすごい速くなっている感じのグラフ(一番上が速くなった版のRequests per Second、赤が通常版のRequests per Second): これはさすがにbest caseすぎる気がしますが、普通にやっても2倍弱くらいは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
仮想化基盤のリソース最適化 / Resource optimization on virtualization platform
計算量と僕とWeb開発 / computational complexity and I and Web
Pingdom - Website Monitoring Made Easy
Rails高速化戦略 / Speeding Up Rails
http://blog.inouetakuya.info/entry/20121216/1355656214
