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

test_start event blocks the UI #1463

Closed
denniseffing opened this issue Jul 3, 2020 · 3 comments
Closed

test_start event blocks the UI #1463

denniseffing opened this issue Jul 3, 2020 · 3 comments

Comments

@denniseffing
Copy link

Describe the bug

When a user starts a load test and the test_start event is fired, the UI is basically doing nothing until the test_start event hooks have finished executing.

Expected behavior

UI should open up the statistics dashboard and change the status from READY to a new state called INITIALIZING.

Actual behavior

UI hangs on "Start new Locust run screen" until test_start execution has finished.

Steps to reproduce

  1. Add a test_start listener that pauses the thread for 5 seconds.
@events.test_start.add_listener
def on_test_start(**kwargs):
    time.sleep(5)
  1. Start a test

Environment

  • OS: macOS 10.15.3
  • Python version: 3.7.7
  • Locust version: 1.0.3
  • Locust command line that you ran: locust
  • Locust file contents (anonymized if necessary):
from locust import events, HttpUser, task, between
import time


@events.test_start.add_listener
def on_test_start(**kwargs):
    time.sleep(5)


class TestUser(HttpUser):
    wait_time = between(5, 9)

    @task
    def index_page(self):
        self.client.get(url=self.host)
@camilojimenez
Copy link

I looked into this and I found that there is a relatively easy way to fix it (without changing too much the current ways). I put a PR for this (#1479). However, the displayed state is not 'fully' consistent (it says ready while in reality is preparing).

A better (but more involved) solution would be to add an extra state signaling that the test_start events are running (something like PREPARING).

Thoughts?

@denniseffing
Copy link
Author

denniseffing commented Jul 17, 2020

Well that was indeed an easy fix, thank you for the PR. However, I think that adding an additional state would be the most optimal solution.

@cyberw
Copy link
Collaborator

cyberw commented Jul 17, 2020

the solution feels good enough for me. Marking as low prio.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants