Pewpew is an HTTP load test tool designed for ease of use and high performance. See the guide for details on its use. Also see the examples which run against the test-server.
There is also a system which can be deployed to the cloud to dynamically spin up test clients in AWS. It consists of a Controller written in Typescript and Next.js which can then start a test which runs on an Agent written in Typescript which then uploads the results to AWS S3 for viewing on the Controller.
Precompiled Pewpew binaries and WebAssemblies can be found under Releases
- Pewpew executable is the base of this entire project. It is an HTTP load testing tools written in Rust. The code is in both the src folder which contains the actual binary code and the lib folder which contains the sub components used to build pewpew.
- Config WebAssembly is a Rust WebAssembly used to validate yaml files before they are run. It will validate the yaml syntax is correct and all environment variables needed by the test are provided. Used by the Controller before tests are run and by the Agent as well
- HDR Histogram WebAssembly is a RUST WebAssembly used by the Controller or Guide to display results in readable charts.
- Test Server is a special executable that was created to make easy Bug Reports. It is a simple HTTP server that will bounce replies back and all Examples will run against it.
The PPaaS System works by having an always running Next.js Controller running which can be used to start a test. Starting a test will upload the yaml file, any required provider files, and any environment variables to AWS S3 (Simple Storage Service). The controller also puts a Message on an SQS Queue (Simple Queue Service) which then will cause a scaling event to bring up a Typescript Agent which then downloads the test files from S3, along with a Pewpew binary and runs the test. During the run, the agent will periodically upload results to Splunk, and check for updated files from the controller. At the completion of the test, it uploads the final results to S3 and notifies the Controller via SQS that it is complete. It then removes an SQS message from the SQS Scale In queue allowing the agent to be scaled in. A single Controller can be attached to multiple SQS queues and subsequent autoscale groups of agents. This allows you to have different sized instances depending on your load tests. A single controller could have one queue/autoscale group using t3 instances for small load tests or a c5n.18xlarge for very large load tests. Our recommended default is one of the network optomized instances (currently c5n.large). Shared code by the Controller and Agent is in the Common folder. This includes the code for accessing S3 and SQS. Logs are also written via bunyan using a log4j format that can be injested into a log parser such as Splunk.
- (Multiple) SQS
SCALE_OUT_QUEUE- Start test messages are put on this queue to cause a scale out event and autoscale up an agent. Any new messages on the Scale Out queue will cause a new autoscale event. Each Agent autoscale group needs its own Scale out queue. - (Multiple) SQS
SCALE_IN_QUEUE- Used for scaling in. Due to limitations in SQS, tests cannot reside on theSCALE_OUT_QUEUEfor more than 12 hours and be kept hidden. To work around this limitation (and allow load tests longer than 12 hours), we use a separate queue for scaling out and scaling in. Because there may be multiple agents running tests and we have no way to determine which agent will be scaled in, only when the Scale In Queue is empty, will agents scale in. Each Agent autoscale group needs its own Scale in queue. - SQS
COMMUNICATIONS_QUEUE- This queue is used by the agents to send update messages back to the Controller. Messages such as error, new results, completed, or failed messages can be sent. Only one Communications queue is needed by the controller that all agents and autoscale groups can use. - S3 Storage - All test files, results, and status files are written here. Different PewPew version binaries will also be uploaded here along with the file containing the calendar for the Controller.
- Controller EC2 Instance/Autoscale - Due to the nature of the future scheduler, only one instance is supported at this time.
- Agent EC2 Autoscale Group(s) - One or more autoscale groups with its own SCALE_OUT and SCALE_IN SQS queue. Each scale out creates a new instance running the agent code