タグ

2016年3月15日のブックマーク (6件)

  • JMeterのMaster-Slave構成で目標スループットから負荷設定値を決める | DevelopersIO

    目標リクエスト毎秒は 発行するリクエスト総数/総秒数 です。よって、JMeterのMaster-Slave構成の負荷試験においては、これらの変数の関連を次のように表現できます。 [latex] RPS = \frac{Slaves \cdot Threads \cdot Loop}{RampUp} [/latex] このうち、目標リクエスト毎秒(RPS)は今回の前提で固定値になります。また、ほとんどのケースではスレーブ台数(Slaves)とRamp-Up期間(RampUp)があらかじめ決まっていると思います。 その場合には、未知数がスレッド数(Threads)とループ回数(Loop)のみになります。これらの値は次の式で表現できます。 [latex] Threads = RPS \cdot \frac{RampUp}{Slaves \cdot Loop} [/latex] [latex] L

    JMeterのMaster-Slave構成で目標スループットから負荷設定値を決める | DevelopersIO
  • AWSの一括請求に関するアレコレ - Qiita

    一括請求(Consolidated Billing)とは? 複数のAWSアカウントの請求を1つのアカウントに紐付けて請求を一化する機能です。 主に複数プロジェクトを抱える組織などで便利な機能だと思いますが、これを活用することで受けられるメリットもいくつかあるので覚えておくと良いです。 一括請求に関する詳細は、公式ドキュメントや、ぐぐれば他にもっと手順や何やらを詳しく説明しているサイトがあるのでそっちを見てください。 ここはそれらのざっとググった情報からは見つけることが出来なかった、一括請求に関する細かい点を調査して補足するメモです。前半にざっとメリットなども書いてますが、 後半の「注意点」以降がこの記事のメイン です。 メリット 請求を1箇所にまとめられる 一番よくある活用方法は、プロジェクトや顧客ごとに新規AWSアカウントを作って分けて使うことでしょう。こうすることでプロジェクト毎の利

    AWSの一括請求に関するアレコレ - Qiita
  • AWS 権限管理のベストプラクティスについて考えてみた | はったりエンジニアの備忘録

    AWS は Management Console や API ですべて操作できます(Direct Connect など一部例外もあります)。データセンターの物理的なセキュリティなどは AWS が責任を負うところで、ユーザーはまったく意識する必要はありません。 その代わり、OS やミドルウェアの管理、アプリケーションの設計や実装、適切な権限管理などはユーザーが責任を負うところです。 今回はあまり取り上げられないけど、すごく大事な権限管理についてまとめてみました。自分が仕事で関わっているプロダクトで権限管理を見直すときに調べたことをベースにしていますが、もっと良いプラクティスがあればぜひ教えてください。 AWS アカウントは使わない 普段の運用で AWS アカウントは使いません。 AWS アカウントとは、最初にサインアップするときに作られるアカウントです。 このアカウントは Linux で言う

    AWS 権限管理のベストプラクティスについて考えてみた | はったりエンジニアの備忘録
  • AWSコンソールを複数人で安全に共有する方法 - Qiita

    はじめに AWSキッチンのシェフ中村です。 AWSでサーバーを構築する際に、アカウントを保持している人とは別の人が作業を行う場合があり、たとえば、お客様が開発ベンダーに仕事を依頼する際にAWSのアカウントを伝える場合がそれにあたります。この際に問題になるのが、通常のAWSログインアカウントを渡した場合、クレジット情報や課金情報等のお金にかかわる情報まで閲覧できてしまう可能性があることです。もちろんクレジットカード番号の閲覧はできませんが、これらの情報にアクセスできるのは少々問題があります。そこで、管理者用のアカウントと作業者用のアカウントを分けることで、これらの問題に対応したいと考えます。 AWSアカウントの種類 AWSのアカウントには、ルートアカウントとIAMアカウントがあり、ルートアカウントは管理者のアカウントで、IAMアカウントは利用するユーザー毎のアカウントになります。IAMアカウ

    AWSコンソールを複数人で安全に共有する方法 - Qiita
  • Getting started with Laravel on PHP for App Engine

    Getting started with Laravel on PHP for App Engine
  • ユニットテストの綺麗な書き方 - 超ウィザード級ハッカーのたのしみ

    テストばっかり書いている。テストコードなんかの綺麗さを追求しても仕方ないかなと思っていたのだけれど、適当に書いていると重複が多くて大変で、シンプルに楽に書くコツみたいなのを掴んできたのでメモしておく。JUnitを対象にする。 テストクラスの単位 ユニットテストは機能要件をテストするものだ。非機能要件(性能、保守性、etc)などはテストできない。ユニットテストを書けるようなコードは保守性も上がるし、テストがあるコードは壊せないのでチューニングもしやすいというのは事実だろうが、これらをユニットテストで確認することはできない。 機能をテストするのだから、JUnitのクラスは機能(function)ごとに分けるのが自然だ。基的にはクラス・メソッドごとになるかと思う。普通は機能ごとにクラスがあって、そのサブ機能がメソッドになっているものでしょう。したがって、クラスとそのテストのクラスは1対多にする

    ユニットテストの綺麗な書き方 - 超ウィザード級ハッカーのたのしみ