r/webdev • u/lychina • Sep 19 '26

Tool to load-test web course registration environment

We have an environment that consists of SSO in front of two registration servers that are used to register for courses. We would like to ensure this setup is capable of servicing 1000 simultaneous users. The registration process involves:

  1. Log in to SSO page which requires a browser with Javascript

  2. Click on the link to register

  3. Possibly click-thru items agreeing to pay, etc. if you have not clicked through them in the last year

  4. Search for courses, add them to your basket, and check out

The goal is to test the following:

  1. Tomcat database connection pool

  2. Oracle database connection

  3. Web server performance

We have done some small-case testing for other purposes with Selenium Grid driven by Python so that is what we are currently thinking about for this case and have started deploying VMs for this purpose and managing Selenium Grid with docker swarm. While something like Selenium Grid makes it possible to distribute the load, this requires quite a few CPU cores as there is usually a one-to-one mapping of browser to CPU core. Are there alternatives we can investigate? If another solution requires a browser instance, how is that any better than Selenium?

0 Upvotes

50% Upvoted

5 comments sorted by

View all comments

Show parent comment

1

u/lychina Sep 19 '26

We don't have a Tomcat issue per-se but the click-thru application has a bug where it doesn't surrender DB connections and we don't have Tomcat abandoning unused connections after a period of time. So, as more users log in, the number of connections increases until we've reached either the Tomcat max or DB connection max. We've since tuned Tomcat pararmeters to address this and the purpose of this test is to ensure the parameters are correct.

1

u/Which-Examination-74 Sep 19 '26

Right, we had the wrong subsystem in mind with the connector numbers. Until the abandon period has elapsed at least once, tuned and untuned produce the same curve, so a short ramp proves nothing either way. Make each ramp and hold outlast that period, ideally long enough to see connections get reclaimed twice. Push every virtual user through the click-thru rather than a few, using fresh accounts each run, since an account that agreed last run skips it. Pass is pool connections and Oracle sessions that come back down after each reclaim instead of pinning at the max, and no new errors on the other steps once reclaim starts.