https://drecom.connpass.com/event/300236/presentation/
![負荷試験Night#1 負荷試験2023年トレンド](https://cdn-ak-scissors.b.st-hatena.com/image/square/ccac39a20557725e07d6e6fd36d9fe98011ba6c3/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F1019861ba4b94b158f8f04cfd12ac297%2Fslide_0.jpg%3F27708777)
2015年2月24日 ヒカ☆ラボ発表資料 Webアプリケーション負荷試験実践入門 ■スライドの目的 負荷試験の重要性を認識して頂く 意味のある負荷試験を最短距離で行うための“段取り”を持ち帰って頂く 内容的には、主にAWS上のLAMP構成のシステムに対する負荷試験ですが、負荷試験ツールに依存しない全般的に通用する話を扱っています。Read less
こんにちはこんにちは。技術部クックパッドサービス基盤グループの id:riseshia です。 本記事では直前の記事で提案された新しい検索システム(以下、 solr-hako と呼びます)を利用し、レシピサービスの検索インフラの切り替えた話をします。 solr-hako の設計を直接参照する内容はありませんが、それを前提においた移行作業ですのでそちらの記事を先に読むことをおすすめします。 インフラ構成の変化 まずインフラ構成の変化ををみておきましょう。 検索インフラ(変更前) 今まではこのようなインフラ構成でした。特徴としては、 search-cache というキャッシュサーバ(Varnish)が手前にあることくらいでしょうか。今回、 solr-hako を利用することで以下のような感じになりました。 検索インフラ(変更後) しれっとキャッシュレイヤーである Varnish がなくなったこ
The best developer experience for load testingOpen source and SaaS for engineering teams Prevent failures. Improve reliability. Release with confidence.Test early and continuously—break the QA silo in performance testing DevelopersBackend and frontend engineers prevent regressions when running performance tests. Site Reliability EngineersTest scalability to improve your reliability targets. Test S
技術部 Site Reliability (SR) グループの id:itkq です。2020 秋タイトルで一番期待しているのはおちこぼれフルーツタルトです。本エントリでは、Web サービスの負荷試験に対する障壁を下げるために、汎用的な Web コンソール開発に至ったまでの話を書きます。 Web サービスの負荷試験の障壁を下げたい クックパッドでは、マイクロサービスを支える基盤が成熟しており、新規サービス開発や、サービスリニューアルなどの機能開発の場面では、疎結合な新規のマイクロサービスとして実装されることが多いです。このようなサービスをリリースする際は、予想されるトラフィックに対して、実際にそれを捌ききれるかどうかテストする、いわゆる負荷試験をすることは一般的です。これまで、サービスリリース時に、負荷試験をきちんと行うこともあれば、負荷試験を行わないこともありました。負荷試験が行われない
最近はZX-25Rが気になっている菅原です。4気筒250ccといえば、以前バリオス2に乗っていたんですが、あれもよく回るよいバイクでした。足つきの良さが懐かしいです。 この記事では、クエリログを使ったAurora MySQLの負荷テストの話を書きます。 MySQLの負荷テスト サービスに使われているデータベースは、Webサーバと比べて自動的なスケールアップ・スケールアウトが簡単ではないためキャパシティプランニングは非常に重要です。サービスへのアクセス増による負荷増大の結果、急激に性能が低下するためなるべく事前にキャパシティを把握しておきたいところです。 クックパッドではサービスのデータベースとして主にAurora MySQLを利用しているのですが、キャパシティを把握するための負荷テストには以前から苦労してきました。 1. シナリオを書くのが大変 サービスで使われているデータベースの負荷テス
toyama0919/fluent-plugin-http_shadowというShadow Proxyっぽいことを簡単にやるプラグインを作りました。 production環境で半年くらい動かしてたのでメモしときます。 「Fluentd Meetup 2015 夏」で実際のユースケースを発表しました。 Shadow Proxyサーバとは Shadow Proxyサーバについては以下がわかりやすいです。 気軽なMySQLバージョンアップ - まめ畑 Go言語を含む複数種類の言語により実装されたソフトウェアのベンチマーク - Qiita 実装としては以下のようなものが公開されています。 cookpad/kage lestrrat/p5-Geest kentaro/delta 本番のリクエストをそのままバックエンドにあるサーバーに複製して送信するのですが、アプリケーションの規模が大きくなればなるほ
はじめまして。オプティムのプラットフォーム事業本部 Cloud IoT OSチームの津田です。 普段は、Cloud IoT OSのSREチームとして、キャパシティプランニング・パフォーマンスチューニングを主に行なっています。 さて、今回はキャパシティプランニングの中で行なっている負荷試験について触れてみたいと思います。 ※ 2019/1/28 一部の表記を修正しました Cloud IoT OS とは キャパシティプランニングとは 負荷試験とは 負荷試験をする 試験準備 テストシナリオとテストの設計・計画 負荷試験ツール・サービスの選定 なぜk6なのか ボトルネック・スケーラビリティ特性の洗い出し テストシナリオ作成、保守 試験実施 前提 実施 Get My Profileの試験実施 localから直接試験実施 Load Impact を介して試験実施 試験分析 前提 分析 チェック項目 負
Cookpad Tech Kitchen #24 5800万人が使うサービスのリニューアルとその技術 ( https://cookpad.connpass.com/event/183385/ ) で、"「信頼性」を保ちつつ大規模サービスをリニューアルする" というタイトルで発表した際の資料です。 スライド内のリンクは次のとおりです。 - How SRE teams are organized, and how to get started: https://cloud.google.com/blog/products/devops-sre/how-sre-teams-are-organized-and-how-to-get-started - Design Docs at Google: https://www.industrialempathy.com/posts/design-docs
8. 負荷テストアプローチ別の目標設定と指標の考え方 7. 負荷テストの評価基準には何 を使えばよいのか? に戻る はじめに 一般的に負 荷テストには、目的に応じて以下の4種類のアプローチがあると言われています。 * 性能テスト - スループット * 性能テスト - 応答時間 * 限界テスト * 耐久テスト 負荷試験はシステムに対する客観的評価手法の 一つですが、何をもって判定基準や達成目標にするかという明確な指標を伴わずに、漫然と一定量の負荷をかけて問題が起きなければそ のまま完了とするスタンスには問題があります。 実行時に明確な目標と指標が無い場合には、採取したデータも活用の出来ない 意味の無い客観データになりやすいですし、また、テスト時に可能である潜在的な性能問題の発見/改善のせっかくの機会を見逃すこと になります。 本編では、これらアプローチ毎の目的設定と指標の考え方について整理し
~テストツールを使う際の負荷量の指標~ 6. システムがパフォーマンスを維持するためのメモリ管理について に戻る はじめに 性能テスト、負荷テストを行う上では、達成すべき目標値の定義が必要となります。しかし、性能テストでは様々な指標が存在しており、どの指標をもって目標とし、結果を判定すべきか判断が難しい場合があるでしょう。 実際に、Webシステムの性能評価を行うための指標には以下があります: * 同時接続ユーザー数(Number of Virtual Users) * 時間あたりのユーザーシナリオ実行本数(Transactions per hour) * 時間あたりのページ処理数(Received pages per hour) * 時間あたりのヒット数(Hits per hour) * サーバー平均応答時間(Average Server times, etc.) * サーバー側のCPU
An open source load testing tool. Define user behaviour with Python code, and swarm your system with millions of simultaneous users. Tweet Follow @locustio Define user behaviour in code No need for clunky UIs or bloated XML. Just plain code. Distributed & scalable Locust supports running load tests distributed over multiple machines, and can therefore be used to simulate millions of simultaneous u
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く