#Apache jmeter free ebook download download

The median of the TestJSON is around 108 milliseconds (this time includes the execution of the API and the download of the information to my laptop). I found the CPU was below one percent and the number of threads of the worker was 83: Testing with 300 threads in JMeterįirst, I tested the API using 300 threads in JMeter. The JMeter script uses between 300 and 600 threads, with a ramp-up of 60 seconds:Ī Gaussian random timer is used between requests, with a constant delay of 0.5 seconds and a deviation of one second:īefore the test, I checked the status of the worker in CloudHub with Anypoint Monitoring. To stress the API, I created a JMeter load test that invokes the four endpoints: Once the API was developed, I deployed it in CloudHub in a 0.1 vCore worker:Īs I wanted to simulate a realistic scenario, I created an API instance protected with client_credentials: Performing stress tests using JMeter

#Apache jmeter free ebook download code

This flow first invokes the TestJSON endpoint and transforms the output using the DataWeave code shown before. The Request just invokes the testJSON endpoint: Text2: substringAfterLast(payload.text2,'Blue '), The Transform message contains this code: %dw 2.0 'text1': 'Text in uppercase and lowercase', The payload is set using this code: output application/json Once the API was published, I created a Mule project with Anypoint Studio implementing the logic, using these four flows: I published the API definition to Exchange: Creating a Mule project to implement logic TestRequestDataWeave: This endpoint invokes TestJSON using an HTTP request and modifies the output using the previous DataWeave Transformation.TestRequest: This endpoint invokes TestJSON using an HTTP request connector.TestDataWeave: This endpoint transforms that JSON object using math, date, and substring operations.TestJSON: This endpoint returns a simple JSON object with five or six attributes.To test that, I created a simple API that exposes these four endpoints: I was curious if Dataweave operations add significant overhead in the CPU, or how many requests per second can handle a small worker running in just 500 MB. Some thread switches are omitted - for example, if a CPU_INTENSIVE is followed by a CPU_LIGHT operation, that task will remain in the CPU_INTENSIVE thread.ĭuring one of my projects, I wanted to check the API performance that uses a combination of different types of operations (HTTP requests, Dataweave transformations, etc.). Additionally, the proactor design pattern is used, so the different operations of a Mule flow are classified in categories and executed with threads of IO, CPU_LIGHT, or CPU_INTENSIVE depending on the task. In the new threading model, the CPU_LIGHT, CPU_INTENSIVE, and IO thread pools are combined into a single thread pool: the UBER pool. MuleSoft introduced Mule 4.3 runtime which includes several changes in the way it handles threads.