Headless Firefox

[so0k]

Great module, it worked perfectly with PhantomJS in docker containers.

Although, PhantomJS seemed quite slow, so I tried to use firefox... and it was a pain due to display issues.

I ended up copying the sourecode into my project folder and modifying the locusts.py as follows:

+from pyvirtualdisplay import Display
...

class RealBrowserLocust(Locust):
    client = None
    timeout = 30
    screen_width = None
    screen_height = None
+   display = None

    def __init__(self):
        super(RealBrowserLocust, self).__init__()
        if self.screen_width is None:
            raise LocustError("You must specify a screen_width for the browser")
        if self.screen_height is None:
            raise LocustError("You must specify a screen_height for the browser")
+       self.display = Display(visible=0, size=(self.screen_width, self.screen_height))
+       self.display.start()
...
class FirefoxLocust(RealBrowserLocust):
    """
    This is the abstract Locust class which should be subclassed. It provides a Firefox webdriver that logs GET's and waits to locust
    """
    def __init__(self):
        super(FirefoxLocust, self).__init__()
        #binary = FirefoxBinary(firefox_path='/usr/bin/firefox',log_file=open("/firefox.log",'w'))
        #self.client = RealBrowserClient(webdriver.Firefox(firefox_binary=binary), self.timeout, self.screen_width, self.screen_height)
+       self.client = RealBrowserClient(webdriver.Firefox(), self.timeout, self.screen_width, self.screen_height)

I still have to find a way to stop the display when the locust client is killed...

But I wonder, how do you run the locust Firefox instance?

[brandonparncutt]

@so0k You can use a virtual display...you need to install Xvdf and the pyvirtualdisplay python module. Then create a virtual display with visible param set to 0...the firefox web driver will then start firefox using that framebuffer. It's not exactly headless, but it doesn't require X or anything.

@nickboucart Thanks for this...I've been on the hunt for a better way to test AJAX-heavy single-page web apps and Locust has become my favorite tool for loadtesting. This was its only downfall.

[so0k]

I do believe I used Xvdf, but it was just too slow to run a high load test

[brandonparncutt]

@so0k I was actually curious about how adding the selenium jar and a browser to the mix was going to impact performance. The biggest reason why I chose Locust (over Jmeter, for example) was that I could perform a very intensive load test (borderline DOS attack) with just a quad-core laptop...and still be able to use it for other tasks. Do you recall the specs of your machine and the highest RPS you were able to generate?

[so0k]

i was mainly using Kubernetes on AWS (running on m4.large on EC2 perhaps) - so using Docker Containers...

FYI, to that purpose I also built a Helm chart for Locust to quickly run distributed load tests https://kubeapps.com/charts/stable/locust

On Mon, Oct 16, 2017 at 8:41 PM, Brandon Parncutt notifications@github.com wrote:

@so0k https://github.com/so0k I was actually curious about how adding the selenium jar and a browser to the mix was going to impact performance. The biggest reason why I chose Locust (over Jmeter, for example) was that I could perform a very intensive load test (borderline DOS attack) with just a quad-core laptop...and still be able to use it for other tasks. Do you recall the specs of your machine and the highest RPS you were able to generate?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nickboucart/realbrowserlocusts/issues/1#issuecomment-336874512, or mute the thread https://github.com/notifications/unsubscribe-auth/ABrlJ86_5oRf01Ffnc7BVbEtJyAJsr6_ks5ss07cgaJpZM4JOMmj .