Out Of My Memory

雨垂れ石を穿つ

【ABC169】初めて競技プログラミングに参加した

1問しか正解できなかったよ。。。言語はC++を使用。

f:id:pzdl-HIRAKU:20200603230432p:plain
ABC169得点結果

B問題のオーバーフローやC問題の丸め誤差を理解していなかった。
自分がパソコンをいかに知らないかを思い知らされた。

復習や過去問をちょくちょくやりつつチャレンジしていこう。。。。

【React】親コンポーネントから子コンポーネントへの引数渡し方メモ

React javascript

ディレクトリ 構成

src
|-index.js
LTodoList.js

基本ソース

index.js

TodoListコンポーネントを表示しているだけ

import React from 'react';
import ReactDOM from 'react-dom';
import TodoList from './TodoList';

ReactDOM.render(<TodoList />, document.getElementById('root'));

TodoList.js

TodoListからTodoへ「objectのnameプロパティ」を渡し、Todoが受け取ったnameプロパティを表示させている。
keyプロパティを指定して渡しているのは、渡さないと開発者ツールのコンソール見たときに怒られるから。

qiita.com

import React from 'react';

const objectArray = [
  {id:1, name:"name1"},
  {id:2, name:"name2"},
  {id:3, name:"name3"},
  {id:4, name:"name4"},
  {id:5, name:"name5"},
];

const TodoList = () => {
  return (
    <ul>
      {objectArray.map((object) => <Todo key={object.id} name={object.name} />)}
    </ul>
  )
}

const Todo = (props) => {
  return (
    <li>{props.name}</li>
  )
}

export default TodoList;

TodoListがスプレッド演算子を使用して渡す

以後、TodoListとTodoのソースのみしか変更しないため変更部分のソースのみ掲載

const TodoList = () => {
  return (
    <ul>
      // <Todo key={object.id} id={object.id} name={object.name}/> と同義
      {objectArray.map((object) => <Todo key={object.id} {...object}/>)}
    </ul>
  )
}

const Todo = (props) => {
  return (
    <li>{props.name}</li>
  )
}

export default TodoList;

Todoがプロパティ名を指定して受け取る

const TodoList = () => {
  return (
    <ul>
      {objectArray.map((object) => <Todo key={object.id} {...object} />)}
    </ul>
  )
}

const Todo = ({ name }) => {
  return (
    <li>{name}</li>
  )
}

export default TodoList;

スプレッド演算子を使用して子コンポーネントにプロパティを渡すやり方を知らなかったのでメモ。

【Jmeter】スレッドグループのスレッド数・RampUp・ループ回数について

Jmeter

要約

  • スレッド数：仮想ユーザの数を設定する。10に設定すれば10ユーザで負荷掛けを行うと考えればよい
    • 負荷調整はスレッド数だけでなく、リクエスト間隔で行う
  • RampUp:仮想ユーザが全員立ち上がるまでの時間を設定する
    • 負荷をばらつかせるためRampUpは設定した方がいい
  • ループ回数：1つのスレッドが何回ループするかを設定する
    • 負荷掛け時間はループ回数ではなく、Durationで調節した方がいい

使用資材・環境など

スレッド数（これの説明が大半）

仮想ユーザの数を設定する箇所。ここの数値を10とすれば、10ユーザで負荷掛けを行うと考えればいい。
スレッド数によって、生成できる負荷量の上限は大きく変わるが、サーバのレスポンスタイムによっては、1スレッドで10TPSを出すことができるし、逆に10スレッドで5TPSさえ出すことができない場合がある。
Jmeter側でリクエスト間隔を調節すれば、100スレッドで1TPSしか出さないようにもできる。
リクエスト間隔を調節すれば、多くのスレッドで少ないTPSを出せるが、少ないスレッドでは大きなTPSを出すことは基本難しい。（レスポンスタイムが爆速であれば可能）

具体例的な

以下の具体例で、狙ったTPSを出すにはレスポンスタイムに応じてスレッド数を調整しなければいけないことを体感してもらえればうれしいです。理解してもらえれば、10TPSの負荷をかけたいから10スレッドでいいなどとは考えないようになるでしょう。

以下の様にShell Bean Sampler1つの負荷シナリオを使用します。
1秒スリープして終了するだけ。統計レポートには1秒後にレスポンスタイムが返却されたような挙動になります。
sleepを50ミリ秒に設定すれば50ミリ秒でレスポンスが返却されてたように統計レポートに表示されます。

f:id:pzdl-HIRAKU:20191222211509p:plain
使用する負荷シナリオ

1スレッド1ループで単発実行すると統計レポートには1秒でレスポンスが返却されたように見える。
ThroughtPutは59.9/minとほぼ1TPS出ていることがわかる。

f:id:pzdl-HIRAKU:20191222211712p:plain
1スレッド1ループでの実行結果

100スレッドで10TPSを狙ってみる。負荷掛け時間は1分とする。
リクエスト間隔を調節しなければ100TPS出てしまうので定数スループットタイマーでリクエスト間隔を調節する。

f:id:pzdl-HIRAKU:20191222212346p:plainf:id:pzdl-HIRAKU:20191222212401p:plain
100スレッドで10TPSを狙う

定数スループットタイマーについては以下の記事を参照してください 【Jmeter】負荷量を調整する方法 - Out Of Memory

確かに100スレッドでも10TPSを出すことができた。

f:id:pzdl-HIRAKU:20191222212653p:plain
100threadで10TPS 負荷試験結果

次に、Shell Bean Samplerのsleepを50ミリ秒にして1スレッドで10TPSを狙ってみる。 シナリオの構成は全く一緒。変更点はShell Bean Samplerのsleepが50になっていること、スレッドグループのスレッド数が1になっていること。

f:id:pzdl-HIRAKU:20191222213053p:plainf:id:pzdl-HIRAKU:20191222213059p:plainf:id:pzdl-HIRAKU:20191222213102p:plain
1スレッドで10TPSを狙う

レスポンスタイムが50ミリ秒程度となっているため1スレッドでも10TPSを出すことができた。

f:id:pzdl-HIRAKU:20191222214202p:plain
1スレッドで10TPS 負荷試験結果

次にShell Bean Samplerのsleepを1秒にし、1スレッドで10TPSを狙ってみる。（もちろん無理）

f:id:pzdl-HIRAKU:20191222214840p:plain
1スレッドで10TPS 負荷試験結果（無理）

レスポンスタイムが1秒の時点で1スレッドでは1TPS以上出すことは不可能。
なぜスレッド数の説明をここまでしているかというと私がこれで嵌ったからです。。。

RampUp

設定したスレッド数をすべて立ち上げるまでの時間を設定する。
ここを0秒にすると、負荷試験開始と同時にすべてのスレッドを立ち上げる。
ここを設定する意義は各スレッドが送るリクエストをばらつかせるという理由がある。

以下の様にHTTPリクエストをA→B→C→Dと送る負荷シナリオがあったとする。

f:id:pzdl-HIRAKU:20191222204401p:plain
簡単な架空の負荷シナリオ

RampUpを0秒にした場合、以下の様な負荷挙動になることがある。

設定したスレッドみんなが一斉に立ち上がり、ほぼ同じタイミングでAリクエストを投げる。
↓
サーバが処理をしてレスポンスを返却（受信したリクエストをすべて捌いたとする）
↓
設定したスレッドみんながほぼ同じタイミングでレスポンスを受け取り、一気にBリクエストを投げる。
↓
サーバが処理をしてレスポンスを返却
↓
（略）

理想は、あるスレッドはAのリクエストを送信しており、ほかのスレッドはBとかCのリクエストを送信しているといったように各スレッドが送信するリクエストにばらつきがあることだ。
各スレッドが同時に同じリクエストを送信するより、各スレッドが違うリクエストを送っていた方が実際の負荷挙動っぽいしそれを再現するためにRampUpを設定する。

負荷シナリオを1周するのに1分もかからなければRampUpは1分とか5分とかでよいが、負荷シナリオの1周が長く、5分とかかかるのであればRampUp時間も10分や15分と長めに設定して送るリクエストをばらつかせるといい。

RampUpを設定するその他の理由としては、徐々にスレッドを起動した方がJmeter側の負荷が一気に上がって詰まることがないことが挙げられる。

ループ回数

スレッドグループの各スレッドが何回ループするかを設定する箇所。
例えばスレッド数が10でループ回数が5回なら10×5=50回のリクエストを送ることになる。

ただ、負荷試験を行うとなると10分間50TPSの負荷をかけ続け、サーバが目標とするスループットを出せており、かつ目標とするレスポンスタイム内にレスポンスを返せるか等の見るため、ループ回数で何回リクエストを送るかを設定するよりもどれくらいの時間負荷をかけ続けるかを設定した方が楽ちん。 もし、10分間50TPSをかけ続けたいなら、ループ回数は無限に設定し、持続時間を10分に設定するのが吉。
そしてかける負荷量（ここでは50TPS）はThink Time か 定数スループットタイマーで調整する。

f:id:pzdl-HIRAKU:20191222203716p:plain
10分間負荷掛けを行いたい場合の設定

【Jmeter】負荷量を調整する方法

Jmeter

要約

この記事ではJmeterで負荷量を調整する方法2つを説明している

1.Think Timeで負荷量を調整する
2.定数スループットタイマーで負荷量を調整する

  • Think Timeで負荷量を調整した場合、何らかの理由ででサーバ側のレスポンスタイムが落ちた場合、目標スループットは出せなくなる。
  • 定数スループットタイマーで負荷量を調節した場合、何らかの理由でサーバ側のレスポンスタイムが落ちた場合でも目標スループットが達成できる時がある。

使用資材・環境など

Jmeterから同じ端末内のApacheへアクセスして静的コンテンツを取得するだけのシナリオを使用する。
また、目標スループットは10TPSとする。

f:id:pzdl-HIRAKU:20191222134701p:plain
負荷掛け環境イメージ

Apacheへアクセスすると It works! と表示されるhtmlが返却されるだけ。

f:id:pzdl-HIRAKU:20191222135808p:plain

負荷シナリオの共通設定

  • 使用するシナリオはスレッドグループの中に1つのHTTPサンプラーがあるだけ。
  • スレッドグループの設定は同じで以下の通り
    • スレッド数：20
    • RampUp：0秒
    • ループ回数：無限
    • 「Specify Thread lifetime」にチェックを入れ「Duration」を60秒に設定する。

下記シナリオに「Think Time」または「定数スループットタイマー」を入れ負荷量を調節する。

f:id:pzdl-HIRAKU:20191222140242p:plain
使用する負荷シナリオ

そのまま負荷掛けしてみる

「Think Time」も「定数スループットタイマー」も入れずにそのまま負荷掛けしてみる。
スタートした後、約5秒でsocket枯渇によるエラーが発生した。

f:id:pzdl-HIRAKU:20191222142045p:plain
socket枯渇によるエラー

●参考

unageanu.hatenablog.com

Jmeterはリクエストに対するレスポンスを受け取るとすぐに次のリクエストを送信するため、レスポンスタイムがとても速いとsocketの作成がsocketの上限値に達してしまい、socket枯渇のエラーが出てしまう。

●テスト結果

Jmeterはレスポンスを受け取るとすぐに次のリクエストを送信するため、Think Time等を設定してリクエスト間隔を調整しないと、socket枯渇のエラーにかかわらずとても多くの負荷を生成してしまう。

f:id:pzdl-HIRAKU:20191222151812p:plain
何も設定せずに行った負荷掛けの結果

Think Timeで負荷量を調整してみる

静的コンテンツを返却するだけなのでレスポンスタイムは100ミリ秒もかかっていない。また、スレッド数は20なのでThink Timeを1秒程度では目標スループットに対して過負荷になってしまうため1.9秒としてみる。

「Think Time」 という名前で「Flow Control Action」というサンプラーを追加している。

f:id:pzdl-HIRAKU:20191222152808p:plain
Think Timeを追加したシナリオ

負荷をかけてみると大体10TPSにはなっている。

f:id:pzdl-HIRAKU:20191222152954p:plain
負荷試験結果（Think Time追加ver）

Think Timeで調節をする場合はスレッド数やレスポンスタイムからどれくらいThink Time を入れる必要があるか計算して調節する必要がある。
今回はとても簡単な負荷シナリオなので計算も簡単だったが、負荷シナリオが長く、レスポンスタイムにもばらつきがある場合は負荷をかけて結果を見ての繰り返しでThink Timeを調節する必要がある。

定数スループットタイマーで調整してみる

＜定数スループットタイマーについて＞
設定したスループット（TPM）になるように送ったリクエストの結果に応じて次のリクエストの送信を遅らせ、目標TPSになるようにリクエスト間隔をよしなに調整してくれるタイマー。

スレッドグループの下に定数スループットタイマーを入れ、TPM(Transaction Per Minutes)に600を入力。TPS(Transaction Per Second)ではなくTPMなので注意。
また、Calculate Throughtput based on: を「all active threads in current thread group (shared) 」にする。ここの設定をミスると全く狙ったスループット通りにならないので注意すること。

f:id:pzdl-HIRAKU:20191222153750p:plain
負荷シナリオ(定数スループットタイマーver)

今回はとても単純な負荷シナリオのため、10TPSちょうどとなった。
定数スループットタイマーは正確に狙ったスループットになるわけではないが、そうなるようにリクエスト間隔を調節してくれるので、大体近しいTPSになる。

f:id:pzdl-HIRAKU:20191222154940p:plain
負荷試験結果（定数スループットタイマー追加ver）

まとめ

  • Think Time
    • 負荷量調整が面倒くさい。
    • サーバのレスポンスタイムに関係なくThink Timeで設定した秒数待機してから次のリクエストを送信する。そのためサーバ側のレスポンスタイムが遅れた場合、目標とするスループットが達成できなくなる。
    • サーバ側のレスポンスが遅れた場合、目標TPSを達成しないためJmeterとサーバのどこかで何らかのボトルネックがあることがすぐにわかる。
  • 定数スループットタイマー
    • 負荷量調整が簡単
    • レスポンスタイムに応じてリクエスト間隔を調節してくれるため、サーバ側のレスポンスタイムが遅れた場合でも目標とするスループットを達成できる場合がある。
    • 言い換えると、目標TPSを達成するために負荷量を増やしたりしていないか注意する必要がある。

【elona改造】所持金やプラチナ硬貨を増やしてみる（３）プラチナ硬貨を増やしてみる

Elona

はじめに

本記事では汎用プロセスメモリエディタ兼デバッガである「うさみみハリケーン」を使用して、elonaの所持金やプラチナ硬貨の増やし方について記載しています。
※本来の遊び方とはかけ離れているため、不快な方はブラウザバックの方をよろしくお願いします。

目次

【elona改造】所持金やプラチナ硬貨を増やしてみる（１）メモリ範囲検索前まで
【elona改造】所持金やプラチナ硬貨を増やしてみる（２）所持金を増やしてみる
【elona改造】所持金やプラチナ硬貨を増やしてみる（３）プラチナ硬貨を増やしてみる　←いまここ

プラチナ硬貨を増やしてみる

1.プラチナ硬貨が格納されているメモリを探す

前回から続けて行っている場合は青枠の①「解放」と②「クリア」を行ってください。
検索・比較単位が2byteになっていますが、前回と同じく4byteで問題ありません。
前回同様にプラチナ硬貨の個数を入力して検索後、「確保・記録」をクリックしてください。

続きを読む

【elona改造】所持金やプラチナ硬貨を増やしてみる（２）所持金を増やしてみる

Elona

はじめに

本記事では汎用プロセスメモリエディタ兼デバッガである「うさみみハリケーン」を使用して、elonaの所持金やプラチナ硬貨の増やし方について記載しています。
※本来の遊び方とはかけ離れているため、不快な方はブラウザバックの方をよろしくお願いします。

目次

【elona改造】所持金やプラチナ硬貨を増やしてみる（１）メモリ範囲検索前まで
【elona改造】所持金やプラチナ硬貨を増やしてみる（２）所持金を増やしてみる　←いまここ
【elona改造】所持金やプラチナ硬貨を増やしてみる（３）プラチナ硬貨を増やしてみる

所持金を増やしてみる

1.所持金が格納されているメモリを探す

現在の所持金を下の画像の様に①に入力して②「通常検索実行」をクリックしてください。
検索の設定は特にいじくる必要はありません。画像と同じようになっていなければ同じようにしてください。（検索・比較単位の部分等）
415の数値が格納されているメモリ番地一覧が表示されるので、③「確保・記録」をクリックしてください。
f:id:pzdl-HIRAKU:20191221210926p:plain

続きを読む

【elona改造】所持金やプラチナ硬貨を増やしてみる（１）メモリ範囲検索前まで

Elona

はじめに

本記事では汎用プロセスメモリエディタ兼デバッガである「うさみみハリケーン」を使用して、elonaの所持金やプラチナ硬貨の増やし方について記載しています。
※本来の遊び方とはかけ離れているため、不快な方はブラウザバックの方をよろしくお願いします。

参考記事

下記の記事を参考にさせていただきました。

blog.azarashi-server.0t0.jp

使用するもの

  • Elona ver1.16final
  • うさみみハリケーン バージョン0.31正式版
続きを読む