Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料) Kubernetesでの性能解析 ~なんとなく遅いからの脱却~ (Kubernetes Meetup Tokyo #33 発表資料) 2020/08/26 NTT DATA Yasuhiro Horiuchi
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料) Kubernetesでの性能解析 ~なんとなく遅いからの脱却~ (Kubernetes Meetup Tokyo #33 発表資料) 2020/08/26 NTT DATA Yasuhiro Horiuchi
こちらで公開されているWebSocketサンプラを使います。 WebSocketを負荷テストする: overflow:auto WebSocketの知識が足りないままやってて色々とハマったのでそのメモになります。 WebSocketの流れ WebSocketを接続するためには2回のリクエストが必要になります。 まずhttpでWebSocket接続に使用するセッションIDを取得します。 Responseの先頭がセッションIDです。 上記で取得したセッションIDをWebSocketのパスに加えてWebSocketリクエストします。 JMeterでどう書くの? こんな感じで特に難しいことはないです。 タイムスタンプ生成(必須かわからないけどブラウザの挙動をなるべくエミュレートしたくて)。 セッションIDを取得するためのhttpをリクエスト。 正規表現でレスポンスからセッションIDを取得して変数に
locust良いですよね。 locust。最近の負荷試験は全部locustで済ませています。複雑なシナリオでもpythonでかけるのですごい楽です。 とはいえ最近は常時接続型のアプリも増えてきて単純なreq/resモデルではうまく負荷がかけれない状況も多い感じです。 というわけで、LocustのタスクでWebsocketを使った負荷をかけて、Webの画面から確認できるようにしてみました。 デフォルトだと単位がmsなんですが、ソケット通信でmsだと普通に0が連発されてしまうので単位はμsになります。 コードみるとわかりますが単にTaskの中でsocketつくって通信し、結果をlocustに通知してるだけなのでlocust本体にはまったく手を入れていません。 locustは設計がシンプルで分散環境の構築部分とリクエストしたりその結果を集計する部分が分かれてるのでこういう事が簡単に出来るのも良い
PHP BLT とは 全員がLTで発表するというコンセプトのPHP周辺/Web/サーバサイド全般の勉強会 phpblt.connpass.com 以下メモ 『自作ArrayでPHPのメモリ節約』"よや" yoya@awm.jp speakerdeck.com 「PHPの配列は重たい」という問題提起 原因はArray管理データが大きい事 SplFixedArray はArray管理データがごそっと減っているので早い もっと節約したい=自作の提案 ArrayAccess + Countable + Iterator を使い、PHPで実装 3GBメモリが20MBメモリに!100分の1のメモリ使用量! 自作Arrayの注意点 『I ♥ PHP(Openpearの素敵な終わらせ方)』@riaf Openpear 作った 誰でもパッケージ公開ができる野良PEARチャンネル 諸事情により使われなかった;
こんにちは。インフラストラクチャー部 セキュリティグループの星 (@kani_b) です。 主に "セキュリティ" や "AWS" といったタグのつきそうなこと全般を担当しています。 Fluentd などのデータコレクタ、Kibana やその他 SaaS による可視化、Kafka, Kinesis, Spark などのストリーム処理といった様々な分野で「ログの処理」がホットですが、アプリケーションのログ (行動ログなど) に関する話題が多くを占めています。 そうしたログの他に重要なのが OS や各種ミドルウェアのシステムログです。これらはトラブルシューティングであったり、セキュリティ上の問題を見つけたり、といったことに使われますが、最低限 syslog でどこかに集約しているだけ、といった例をよく見かけます。 これらのログをきちんと検索可能にし、分析することで、今まで気づかなかったような問
TL;DR HerokuでPull Request毎にステージング環境が勝手にできるようになりました。 Review Apps自体はHeroku Buttonから続くWebアプリデプロイの自動化の流れの成果の内の一つとです。もともとPipelinesを自分で色々やればできたろうとは思いますが、管理画面だけでPR毎の自動環境構築ができるのはクッソ便利です。 Sendagaya.rb #127で下記の発表をさせていただきました。 Sendagaya.rb #127に行ってきました - komagata Review Appsで無限ステージング環境 // Speaker Deck スライドみればわかりますが、githubとconnectして、環境変数・addon選んでapp.json生成して、PR作れば勝手にステージング環境ができます。PRがmergeされれば消えます。 AWS + docker
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く