Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Transaction] Add transaction perf #11933

Merged
merged 34 commits into from
Nov 22, 2021
Merged

[Transaction] Add transaction perf #11933

merged 34 commits into from
Nov 22, 2021

Conversation

liangyepianzhou
Copy link
Contributor

@liangyepianzhou liangyepianzhou commented Sep 6, 2021

Master Issue: ##11765

Motivation

  • When opening a transaction, what is the delay and rate of pulsar sending and consuming messages?
  • How does the granularity of the transaction affect the rate at which pulsar produces or consumes messages
  • Is the rate of abort and commit transactions different
  • Try to keep the functions of ordinary produce perfand consume perf as much as possible

Modifications

Add PerformanceTransaction.Class

  • According to the number of topics set by the user, each topic starts a thread to execute a number of transactions asynchronously.
  • If there is a preset transaction value, the production or consumption of this topic is terminated after the corresponding number of transactions is executed, and the production and consumption of all topics are summed up. After the consumption ends, the main thread ends.
  • Each consumer can have multiple subscriptions, but each subscription has only one consumer. In order to better compare the rate of production and consumption.

Verifying this change

Not yet

Does this pull request potentially affect one of the following parts:

If yes was chosen, please highlight the changes

  • Dependencies (does it add or upgrade a dependency): (yes / no)
  • The public API: (yes / no)
  • The schema: (yes / no / don't know)
  • The default values of configurations: (yes / no)
  • The wire protocol: (yes / no)
  • The rest endpoints: (yes / no)
  • The admin cli options: (yes / no)
  • Anything that affects deployment: (yes / no / don't know)

Documentation

Check the box below and label this PR (if you have committer privilege).

Need to update docs?

  • doc-required

    (If you need help on updating docs, create a doc issue)

  • no-need-doc

    (Please explain why)

  • doc

    (If this PR contains doc changes)

Copy link
Contributor

@gaoran10 gaoran10 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we reuse the existing perf components? Such as PerformanceClient, PerformanceProducer and PerformanceConsumer.

@liangyepianzhou
Copy link
Contributor Author

Could we reuse the existing perf components? Such as PerformanceClient, PerformanceProducer and PerformanceConsumer.

Their logic is different, and they did not extract the generic component. I don't think it's suitable

@codelipenghui codelipenghui added this to the 2.9.0 milestone Sep 6, 2021
@Anonymitaet Anonymitaet added the doc-required Your PR changes impact docs and you will update later. label Sep 7, 2021
@Anonymitaet
Copy link
Member

@liangyepianzhou Thanks for your contribution. Please do not forget to add docs accordingly to allow users to know your great code changes. And you can ping me to review the docs, thanks.

@hangc0276
Copy link
Contributor

Can we divide produce and consume in separate file? Users can test produce with transaction and consume with transaction individually. Otherwise, we may add a script in bin/pulsar-perf to start the transaction perf

@liangyepianzhou liangyepianzhou marked this pull request as draft September 8, 2021 05:01
Copy link
Contributor

@eolivelli eolivelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very interesting idea.

We need this kind of tools in order to be able to test transactions properly.

This is a brand new tool, can you please start a discussion on dev@pulsar.apache.org ?
this way we can discuss in the community

@liangyepianzhou
Copy link
Contributor Author

/pulsarbot run-failure-checks

@Parameter(names = {"--txn-disEnable"}, description = "Disable transaction")
public boolean isDisEnableTransaction = false;

@Parameter(names = {"-abort"}, description = "Abort the transaction. (After --txn-disEnable "
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why some arguments have a double "-" and some other arguments have a single "-" ?

@eolivelli eolivelli modified the milestones: 2.9.0, 2.10.0 Oct 12, 2021
@eolivelli
Copy link
Contributor

I am moving this PR to 2.10.0
we could possibly cherry pick to 2.9.1

I believe that it is not useful to add this to 2.8 branch as transactions evolved

@congbobo184
Copy link
Contributor

@eolivelli please review again, thanks.

@liangyepianzhou
Copy link
Contributor Author

/pulsarbot run-failure-checks

Copy link
Contributor

@eolivelli eolivelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

let's go with this first version of the tool

@congbobo184 congbobo184 merged commit 793a8b9 into apache:master Nov 22, 2021
dlg99 pushed a commit to dlg99/pulsar that referenced this pull request Nov 23, 2021
Master Issue: #apache#11765

### Motivation
- When opening a transaction, what is the delay and rate of pulsar sending and consuming messages?
- How does the granularity of the transaction affect the rate at which pulsar produces or consumes messages
- Is the rate of abort and commit transactions different
- Try to keep the functions of ordinary produce  perfand consume   perf as much as possible
### Modifications
Add PerformanceTransaction.Class
- According to the number of topics set by the user, each topic starts a thread to execute a number of transactions asynchronously. 
- If there is a preset transaction value, the production or consumption of this topic is terminated after the corresponding number of transactions is executed, and the production and consumption of all topics are summed up. After the consumption ends, the main thread ends.
- Each consumer can have multiple subscriptions, but each subscription has only one consumer. In order to better compare the rate of production and consumption.
eolivelli pushed a commit to eolivelli/pulsar that referenced this pull request Nov 29, 2021
Master Issue: #apache#11765

### Motivation
- When opening a transaction, what is the delay and rate of pulsar sending and consuming messages?
- How does the granularity of the transaction affect the rate at which pulsar produces or consumes messages
- Is the rate of abort and commit transactions different
- Try to keep the functions of ordinary produce  perfand consume   perf as much as possible
### Modifications
Add PerformanceTransaction.Class
- According to the number of topics set by the user, each topic starts a thread to execute a number of transactions asynchronously. 
- If there is a preset transaction value, the production or consumption of this topic is terminated after the corresponding number of transactions is executed, and the production and consumption of all topics are summed up. After the consumption ends, the main thread ends.
- Each consumer can have multiple subscriptions, but each subscription has only one consumer. In order to better compare the rate of production and consumption.
fxbing pushed a commit to fxbing/pulsar that referenced this pull request Dec 19, 2021
Master Issue: #apache#11765

### Motivation
- When opening a transaction, what is the delay and rate of pulsar sending and consuming messages?
- How does the granularity of the transaction affect the rate at which pulsar produces or consumes messages
- Is the rate of abort and commit transactions different
- Try to keep the functions of ordinary produce  perfand consume   perf as much as possible
### Modifications
Add PerformanceTransaction.Class
- According to the number of topics set by the user, each topic starts a thread to execute a number of transactions asynchronously. 
- If there is a preset transaction value, the production or consumption of this topic is terminated after the corresponding number of transactions is executed, and the production and consumption of all topics are summed up. After the consumption ends, the main thread ends.
- Each consumer can have multiple subscriptions, but each subscription has only one consumer. In order to better compare the rate of production and consumption.
codelipenghui pushed a commit that referenced this pull request Dec 21, 2021
Master Issue: ##11765

### Motivation
- When opening a transaction, what is the delay and rate of pulsar sending and consuming messages?
- How does the granularity of the transaction affect the rate at which pulsar produces or consumes messages
- Is the rate of abort and commit transactions different
- Try to keep the functions of ordinary produce  perfand consume   perf as much as possible
### Modifications
Add PerformanceTransaction.Class
- According to the number of topics set by the user, each topic starts a thread to execute a number of transactions asynchronously.
- If there is a preset transaction value, the production or consumption of this topic is terminated after the corresponding number of transactions is executed, and the production and consumption of all topics are summed up. After the consumption ends, the main thread ends.
- Each consumer can have multiple subscriptions, but each subscription has only one consumer. In order to better compare the rate of production and consumption.

(cherry picked from commit 793a8b9)
@codelipenghui codelipenghui added the cherry-picked/branch-2.9 Archived: 2.9 is end of life label Dec 21, 2021
@Anonymitaet Anonymitaet added doc-complete Your PR changes impact docs and the related docs have been already added. and removed doc-required Your PR changes impact docs and you will update later. labels Dec 31, 2021
@lhotari
Copy link
Member

lhotari commented Feb 3, 2022

this PR introduced a flaky test, reported as #14109 . Please fix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/transaction cherry-picked/branch-2.9 Archived: 2.9 is end of life doc Your PR contains doc changes, no matter whether the changes are in markdown or code files. doc-complete Your PR changes impact docs and the related docs have been already added. release/2.9.2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants