JMeterを使用したWebアプリケーションの並行性やトランザクション整合性のテスト

Question

データベース内の複数のスレッドを扱うのはむしろ新しいものです（私のキャリアの大半はフロントエンドに費やされています）。

今日私は、テーブルロックを使ってトランザクションをエミュレートするISAMテーブルを使ってmysql dbに値を格納するために書いた簡単なPHPアプリケーションを試してみました。

私はちょうどここで手続き上のブログの記事を書いた：

Testing With JMeter

を私の結果から、私の単純なPHPアプリは私のCSVファイルがあることで、データから見て（そのままトランザクションの整合性を保つために表示されます

CSVファイル：

0 I）は、データベースから再抽出データと同じJMeterのテスト実行後の両方のユーザーのためのデータの

問合せ：

は、私は、トランザクションデータの整合性が損なわれていないことを右の私の仮定にいますか？

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

Answer 1

なぜInnoDBを使用せず、手動テーブルロックなしで同じ効果を得るのでしょうか？

また、あなたは何に対して防御していますか？考えてみましょう二人のユーザ（ビルとスティーブ）：

1. ビルロードレコード1234
2. スティーブ・ロードレコード1234
3. スティーブはその後、古いレコードを更新し、レコードを1234に変更し、
4. ビルは少し待って提出1234と提出する。これらの変更はビルズを破りました。

テーブルロックは、ネイティブMyISAMテーブルロックよりも高いデータの完全性を提供しません。 MyISAMは、データ破損を止めるために必要なときにテーブルファイルをネイティブにロックします。

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

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

EDIT

私が覚えているから、MyISAMテーブルは、挿入のための特別な振る舞いを持っています。挿入のためにテーブルをロックする必要はありません。テーブルの最後に追加するだけです。ユニークなインデックスまたは非オートインクリメントのプライマリキーを持つテーブルの場合はそうでないかもしれません。