Share your experience using RadView WebLOAD

I always consider the purposes and use cases from an enterprise version perspective as a user of the product.

The advantages of OpenText Enterprise Performance Engineering (LoadRunner Enterprise) are clear. The analytics and reporting features provide beneficial impacts on my organization. The scalable testing environment is very beneficial for my performance testing processes.

Scalability is a main important factor when identifying bottlenecks. For example, when I target about 100 users but scale up the system to 120 or 150 users, I can identify where the bottleneck starts to occur.

Regarding negative sides or areas for improvement, I do not see any disadvantages so far. OpenText Enterprise Performance Engineering (LoadRunner Enterprise) might have some drawbacks, but I did not go to that extent to find any. Regarding new features they could add, I am not getting anything at this time.

I have been using OpenText Enterprise Performance Engineering (LoadRunner Enterprise) for two years.

In terms of stability, I would give a rating of nine. The product is stable.

For technical support, I would give a rating of eight. Although technical support issues are not directly related to OpenText Enterprise Performance Engineering (LoadRunner Enterprise) but related to partners, I need to contact support through them since the partners are in between. The technical support experience is a bit limited due to this indirect relationship.

Positive

When discussing price, OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is very expensive, which I would represent by a rating of ten. The product carries maximum expense points.

I have experience with load distribution testing. Based on the load requirements, I set out the virtual machines and load generator systems according to how many are needed and what capacity they can provide. That dependency is based on the load.

Regarding marketplace specifics like AWS or Azure, I am uncertain whether that applies to AWS Marketplace or Azure Marketplace.

For my project handling, I use JMeter for approximately 90 percent of the projects I manage and OpenText Enterprise Performance Engineering (LoadRunner Enterprise) for 10 percent of my projects. My overall review rating for OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is nine.

My work is mainly on the testing part with Apache JMeter itself. I work on anything which is testing-related.

Apache JMeter is used for two different tasks: one is performance-related testing, and another one is API testing. It also helps in security-related testing aspects.

I do work with dynamic HTML reporting. It gives the complete insight altogether. We are not using it vanilla, so we have a wrapper around it. We try to present it in a form where our clients or management appreciate it, but this is the base that we use.

It is quite easy to create and manage tests in Apache JMeter, and since I have been used to it, it tends to become easier.

Apache JMeter is easily integrated into our continuous testing in the CI/CD pipelines.

Apache JMeter is mainly used for performance testing, and this is one of the prime features that we use in any of the performance testing aspects. It forms the heart and soul of everything in terms of the performance testing work that we do.

We do have command prompt related or CLI functionality with Apache JMeter, so it is easier. However, since it is open source, much work has not been put into the GUI part. The GUI could definitely be enhanced.

One drawback which I can see when I compare it with other tools is the amount of cache that it uses, the memory that it uses. It becomes very difficult to work with when we have a lot of requests that need to be processed. Anything more than 10,000 requests becomes a bit of an unfavorable task when using Apache JMeter altogether. Otherwise, it does help anyone who is starting off with performance testing.

I have been using Apache JMeter for seven or eight years.

Apache JMeter is quite stable. Going by the same point, if we have more requests, then we do see some latencies altogether from the system perspective or the environment perspective, as well as from the tool itself.

We do have scaling capabilities. When we have a lot of requests to be sent, that is one part where we can scale up Apache JMeter or fine-tune it altogether. We do have some methods where we can distribute the complete load between multiple systems and then try to do our testing. This is one thing where we can really enhance a bit.

I have never had experience working with support from Apache. Since it is open source, we have an open community. We do post our needs, and most of the time it gets answered there. We do not have any support as such.

Locust was one which we used briefly. However, cost and everything adds up, so we fall back to Apache JMeter.

It is quite easy to install Apache JMeter; it is just a stand-alone thing, and you do not need to do much.

I have not used much of the plugins in Apache JMeter, but recently I used Kafka. Other than that, I did not use much. With Kafka, we did just one test case, so I am not completely familiar with it because we had some help from developers, but that is all.

I have started working on Playwright with MCP server, although I still work with the same products with Amazon, Apache, and Microsoft products today.

Playwright is the new product I am working with. Along with the other ones which I was working on already, this is the added thing, so it is not the only solution I am using today.

I do work with Azure DevOps and Cypress today as well. DevOps is the only product from Microsoft that I work with. Currently, I am not using anything from Amazon. I work with Apache JMeter as an end user, rather than having some partnership with Apache.

Apache JMeter does not have a license, so it is 100% open source. I got Apache JMeter from their website itself, and since it is open source, you can directly download and use it.

My review rating for Apache JMeter is 8.5.