JMeterを使用したWebアプリケーションでの並行性および/またはトランザクションの整合性のテスト

Question

データベース内の複数のスレッドを扱うのは初めてです（私のキャリアのほとんどはフロントエンドに費やされています）。

今日、テーブルロックを使用してトランザクションをエミュレートするISAMテーブルを使用してmysql dbに値を格納するために作成した簡単なphpアプリをテストしてみました。

手順についてのブログ記事を書いたところです：

JMeterでテスト

私の結果から、私のシンプルなphpアプリはトランザクションの整合性を損なわないように見えます（csvファイルのデータがデータベースから再抽出したデータと同じであるように見えます）：

CSVファイル：

JMeterテスト実行後の両方のユーザーのデータのクエリ：

トランザクションデータの整合性が損なわれていないという前提で正しいですか？

並行性をどのようにテストしますか？

Answer 1

InnoDBを使用して、手動のテーブルロックなしで同じ効果を得るのはなぜですか？

また、あなたは何に対して保護していますか？ 2人のユーザー（ビルとスティーブ）を考えます：

1. 請求書はレコード1234を読み込みます
2. Steveはレコード1234をロードします
3. Steveはレコード1234を変更して送信します
4. ビルは少し待ってから、古いレコード1234を更新して送信します。これらの変更により、手形が変わります。

テーブルロックは、ネイティブのMyISAMテーブルロックよりも高いデータ整合性を提供しません。 MyISAMは、データの破損を停止する必要がある場合、テーブルファイルをネイティブにロックします。

実際、MyISAMではなくInnoDBを使用する理由は、テーブルロックの代わりに行ロックを行うためです。トランザクションもサポートします。異なるレコードへの複数の更新は互いにブロックされず、複数のレコードへの複雑な更新はトランザクションが完了するまでブロックされます。

アプリケーションで同じレコードの2つの更新が同時に発生する可能性を考慮する必要があります。可能性が高い場合、テーブル/行のロックは2番目の更新をブロックせず、最初の更新が完了するまで延期するだけです。

編集

私が覚えていることから、MyISAMには挿入のための特別な動作があります。テーブルの最後に追加するだけなので、挿入のためにテーブルをロックする必要はありません。これは、一意のインデックスまたは非自動インクリメントの主キーを持つテーブルには当てはまらない場合があります。