OpenText Professional Performance Engineering (LoadRunner Professional) Reviews

What we like the most is that it integrates with UC. We use UC for our front-end user experience. It's a more realistic user experience. 

We use the script from the user experience and we use the action times from the UC.

If they were able to, I would say that the scalability could be improved. If the costs were not as expensive to upgrade, then we would scale it more.

The initial setup could be simplified.

I would like to see better licensing costs. 

I have been working with this solution for ten years.

It's a stable solution. In the ten years that we have been using it, I have only had an issue once.  We had an issue with the protocol where it didn't support the job. We contacted support.

It's a scalable solution but I think that the Enterprise version is more scalable and more manageable.

It's fine for us, as we only have a few projects a year. On a larger scale, Enterprise would be better than the Professional edition.

When I had contacted technical support they very helpful.

Previous versions were easy to install but we struggled with the LoadRunner Enterprise to get it to work. It was a bit challenging.

LoadRunner Professional is an expensive product.

I like using LoadRunner and I recommend it.

I would rate this solution an eight out of ten.

All of our installations are on-premises at the moment.  

One of the most valuable features to me is that LoadRunner is familiar. I have worked with it for so long that I know where everything is and I know how it is supposed to work.  

But focusing on actual program features, all I can say is it has good protocol coverage.  

I have not had a really good look at the newest versions of LoadRunner. The problem I have always had with LoadRunner — and even more so with Performance Center — is that it is not very good with agile delivery and it is very difficult to integrate. Software engineers who have been working in agile delivery have been saying this for some time, and have been having success with alternatives.

Also, Performance Center has historically been quite unreliable and difficult. It tends to fail at collation. I think that is because of the Load Runner architecture that Performance Center inherited. Everything waits until the end of a test to collate and it does not always work out well. I know that Micro Focus has done something about that in the new version. But that is the worst thing that happens: with LoadRunner or Performance Center you run a big critical test and you can't get the results.  

I have personally been using LoadRunner and Performance Center for 20 years. I think it's been the backbone of performance testing for 20+ years and must be given credit for helping establish the discipline.

Stability has been an issue. It has really been a big problem for us with Performance Center in particular. Crashing or exiting during collation is not acceptable.   

We have not been totally satisfied with the scalability. We tend to have more issues with Performance Center. The more you try to grow use with it on-prem, the more headaches you have. Often working with LoadRunner and smaller environments is more reliable. We believe the SaaS solution might be better because you have got centralized management.  

Most of my experience is in the early days of Mercury, they were brilliant. They were really good and helped resolve issues. I have not been using them recently.  

Right now we use LoadRunner and Performance Center depending on what we believe are best practices for different situations. We are considering evaluating other options as well, including LoadRunner SaaS.

The two Micro Focus products are interesting to compare. LoadRunner is very easy to set up. Performance Center needs an expert. I can install LoadRunner in minutes by myself. To do the installation properly with Performance Center needs a specialist and takes weeks.  

Plenty of people seem to have installed Performance Center in a couple of days, but when they use it they usually have problems. You really need to do it properly. I do plan to have a look at the newer versions, and maybe those implementations will be smoother.  

Advice that I would give people considering LoadRunner is that I would recommend exploring other tools first or at least in comparison. There are lots of really good open-source or even just cheaper alternatives. Depending on your use case, the other options might be much better. LoadRunner has broad protocol coverage. Sometimes you have got no choice but to go with a solution because of what it can do. But I think the days of LoadRunner being the only solution out there for this kind of testing have gone. There are some very good competitors now and where the competitor can do the job, you will save money.  

On the scale from one to ten where one is the worst and ten is the best, I would rate Micro Focus LoadRunner Professional as about a six. I have not taken a good look at the latest version, but my current experience with the version of the product we use has not been great.  

We have several use cases for this solution. One of them is an automobile website for a huge dealership and we are doing load testing for them. We have projects in the hospitality industry, like hotel bookings. Our projects involve both API testing as well as browser-based load testing.

The reporting mechanism is a valuable feature that generates good reports.

The auto-correlation is much better than the different protocols that it supports.

LoadRunner is easy to use.

The debugging capability is difficult to use and should be improved. This is one area where some of the other products we use are better.

I have been using LoadRunner for five years.

We use LoadRunner on a daily basis and it is good.

It is easier to scale when you have the online, cloud option.

We probably have about 200 users and in the future, we may increase our usage.

We have been in touch with technical support but not very often. They were helpful when we did contact them.

We have used multiple testing tools like Visual Studio and NeoLoad. We have all of these as options. LoadRunner is easier to use and has support for better protocols.

Five to six engineers are required to maintain this solution.

Our in-house team deployed this solution.

NeoLoad was one of the options that we considered, but we ultimately went with LoadRunner.

I would rate this solution a nine out of ten.

I am primarily using LoadRunner to perform tests on HTTP and HTTPS.

This solution provides a one-stop-shop for what we need.

I think that analytics is very good and that the analytics features are very powerful.

You can do live monitoring, which is very useful compared to Apache JMeter.

This is good for a large-scale organization because it supports a lot of protocols.

One of the problems with LoadRunner was always outside sharing. However, now that they are offering a cloud version, this may already work well. 

The infrastructure support can be improved because there are a lot of limitations with the hardware that you can use.

I would like to have better support for adding more users per load generator.

I have been using LoadRunner for about ten years.

This solution is very stable. We use it very frequently.

LoadRunner is scalable, although there are some limitations that depend on the application type. That is where you need to scale by adding more load generators. 

We have approximately ten people who are using LoadRunner in the company.

Technical support for LoadRunner is quite good. I would rate them an eight out of ten.

In addition to LoadRunner, I was also using Apache JMeter for about three years. JMeter does not support live monitoring unless you use a plugin. However, JMeter has better infrastructure support than LoadRunner.

My company did not switch from JMeter to LoadRunner. They already had already purchased LoadRunner licenses. There are a lot of inherent limitations with JMeter, including analytics capabilities.

The initial setup for the standalone version is very simple and very easy compared to a solution like Apache JMeter. If you have the licenses then you can get started very soon.

It takes perhaps 20 minutes to deploy, depending on the machine configuration. Only one person is required because it has an auto-install package.

For the standalone version of LoadRunner, you don't need help from consultants. However, for something like a performance center then you need a consultant to help.

The licensing fees are based on the number of users. There is also a free community edition, but it depends on what protocol you're using and how many users you want. Essentially, the licensing fees are based on the need.

This is a very mature tool that is always improving and has very good support as well. More or less, they're always trying to revolve their limitations.

In order to use LoadRunner, you need specific skills. In order to use tools of this type then you need performance engineering skills. My advice for anybody who is implementing this solution is first to be clear about your use case and what you are trying to do. Develop and follow up on your own performance-testing strategy before implementing LoadRunner. That said, I highly recommend this product.

I would rate this solution an eight out of ten.

We primarily use the solution for performance testing and performance tuning.

I like the user interface. I like the way we can divide our scenarios and can tune them. The integration with the quality center is great. These features are really good.

Pricing should be lowered on the solution. Right now it's quite expensive.

The solution uses a lot of memory and then it dies. It's difficult to work with the solution sometimes when you run a scenario it dies. They need to make the solution lighter somehow.

If the correlation can be adjusted so that it's a dynamic correlation, it could be a little bit better and it would help a lot of users.

I've been using the solution for ten years.

The solution is stable.

The solution is scalable. I don't see a problem with scaling, because you can schedule multiple instances.

Technical support has been good so far.

We've basically used LoadRunner since the beginning; we find it more user-friendly than other tools.

The initial setup is easy. It's not difficult.

I handled the implementation myself. How log deployment takes depends on the application. It could take anywhere from a few days to a few weeks.

We started using the solution when it was version 8.2 and now we are on version 10.6. We use the on-premises deployment model. 

I would recommend the solution to others. I'd rate it eight out of ten.

We primarily use the solution for a variety of cases; the use case depends on the application.

The load testing, reporting, and scripting features are all valuable features.

The solution needs to reduce its pricing. Right now, it's quite expensive.

The solution should offer more monitoring features.

The stability of the solution is good.

The scalability is good.

Technical support is fine.

I'm quite experienced with the solution, so I haven't had any issues with the initial setup.

There's the licensing fee, and then additional fees on top of that as well.

We use the on-premises deployment model.

I'd rate the solution eight out of ten.

Our primary use case of this solution is to do testing for banks and financial institutions. 

At the moment I like to use the TruClient port, add them and create other versions of TruClient, because TruClient is usually too big to handle heavy loads, so you need to recreate a vamp version for whatever you will need. 

Sometimes I have problems when I want to record a script if the application is a little special, like the login part. I think the TruClient works well and they are developing new things there all the time. So it's getting better. I would like to see an easier way to move things from SoapUI to the same addressed services and postman or something like that. Because the developers will use the other products and then the website and then load them at no cost. So if it was just one step to move from one system to another it would be a great improvement.

The solution is quite stable. I've seen a few bugs of course - they will always be there. That's not a big deal and I just work around it. 

I guess scalability becomes a problem when you use things like TruClients. It eats lots of memory, so usually, I have two or three low generators while I have the one controller. We have had some problems with when we are using a BPM system. In the beginning, it was quite difficult when we changed to this other system and we wanted to connect to the home computer. 

We have about 12 users, mostly testers, working on the solution currently. Then we have two people working in our performance center. 

The technical support is good. Whenever we had a problem, they solved it. 

The initial setup was quite straightforward and it's quite easy to install the standard version. Everything takes less than an hour.

My advice to others would be to look into the application differently. In the next version, I would like to see an easier way to create and use TruClient for development and to move it to another version. They already have this function, but it is not very user-friendly. You cannot do a correlation of things now, because it is on a higher level now. So you have to do a lot of work. 

My rating for this solution is nine out of ten. I've used it a lot, so I guess it's possible to make things better, but it's been around for a while, so I think it's very good.

Our primary use case of this solution is for performance testing and load testing.

The solution improves our organization because we can use it for recording scripts, enhancing the scripts and for running test revisions. We can therefore preform test revisions and do analysis.

What I really like about this solution, is the user-friendly interface and the loading and repair properties.

Currently the solution doesn't have recording options or sometimes we're not be able to see the recording options. So that needs to improve. I also think the solution should have more screen compatibility, even if you're using a different operating system like Windows 10, Windows 8 or Windows 8.1. Sometimes we find that there is a difference between the desktop screen and the laptop screen. So, it should be compatible for both screens.

The solution is stable and the only compatibility issues lie within the screens. I think there should be an improvement to the compatibility to both laptop and desktop screens. Sometimes we are not be able to click on some of the buttons due to the screen mismatching and compatibility issues. 

We have about 200 users and the scalability is good so far. We don't plan to increase our usage so I am not sure how scalable it will be with more users.

We get really good support from the support team.

The initial setup and installation of the software were very easy and straightforward. 

LoadRunner has a variety of options and different protocols that will support all types of applications categories like web application, monitor and any internal applications or desktop applications. The customization protocol also is user-friendly and if I have to rate the solution, I will give it a nine out of ten. In the next version I would like to see specific protocols when I want to do performance settings for any desktop clients. 

We use this solution for performance testing, and to identify bottlenecks.

This solution has helped us to eliminate software performance risk before going live.

The most valuable feature of this solution is VuGen, the Virtual User Generator. The scripting can be done easily.

The Analysis feature makes it easy to analyze cross-data and we can pin to the focus period.

The price of this solution should be cheaper.

The primary use is for load testing and stress testing of applications. It tests whether services are running at an optimal point or not. It can also be used for benchmarking with other industry standards.

My admin was very useful for finding out how the system responds to load, stress, and normal situations, as well as benchmarking with other industry competitors. It also improved our response time, memory delegation, and CPU delegation. In addition, we used LoadRunner to optimize our database and website.

The features that are most valuable are synchronization capabilities and the ability to interact with it on different types of systems and protocols. It is a market leader and it integrates with different applications. When you compare it to JMeter, LoadRunner is more flexible and has more capabilities than JMeter to support different technologies.

There is room for improvement of the pilot processing and forwarding results based on the dump analysis. We have a generator, root controller, different agents, and an analyzer, so all of these are very important when it comes to LoadRunner.

LoadRunner also has to create a low-cost version that supports simpler testing and only some of the simple features would be included. This would allow people to use LoadRunner and get support from LoadRunner in terms of application testing. It is a principle that if people will get to use LoadRunner for free, LoadRunner will get more business and major payback.

I would rate it 6 out of 10, because LoadRunner is a vast thing, starting from those scenarios and then getting more into users, putting more points, correlation, load testing, and benchmarking. I have this part and hope it works well with the system. All of this is very complex. It takes a long time to learn the system well.

The stability of the solution is mostly good. The only thing is that we used a distributor to fix the problems when something went wrong at one point. If it was working out well, the results of that thing would still give you wrong results. So the distributor is not really good with problems, but the local setup is good with no problems.

We can scale it up at any point in time because we can get a distributor. We can add variants, controllers, claims, and analyzers, so it will support different types of protocols.

We just created load scenarios and we will load the scenarios to a number of virtual users. For example, we can load around 1,000 users for each scenario. In abnormal conditions, we could have 10,000 users. Also, loading them depends upon the role alias and role controller's configuration.

The size of staff required for deployment and maintenance depends upon what application and how many load scenarios you want to do, as well as the complexity of your application, how much hardware you have, and how much software support you have. All of those things will come into the picture.

They would be different types of users like a read-only user, a write-only user, etc.

We use JMeter and LoadRunner together: When we're stress testing and for service or load testing we use JMeter, while we use LoadRunner for basic load testing. We keep it like that but we can see how that mitigation works and the application is also for internal users, so we consider what it does there and we can do a lot of those things.

We are not actually concerned with the technical support of the LoadRunner. We get support for the LoadRunner through the internet.

We previously used JMeter.

The initial setup is not that difficult. When it comes to distribution systems then it will be somewhat difficult, and you need to have a proper network to work on. Another consideration is that at the distribution level and onward we need to put different controllers, unions, and claims at different locations to have a product as accurate as this.

The deployment took some time because we needed to know what type of load is expected in the future and what the break-even point would be, at which point of load. We needed to know the different scenarios that were expected and plan the load testing and the load batterings and always stick to the plan. We needed load analysis, a load plan, and benchmarking standards. All of these need to be collected. This equipment needs to be connected before we can actually begin testing.

The deployment takes around one month man days based on the application status.

We used a consultant for deployment.

We did some return on investment analysis, by using the POC (proof of concept). We compared other tools with LoadRunner, JMeter, and LoadRunner and we got a generated a scenario testing based on the place of publication and we determined that LoadRunner is good.

I don't know the licensing cost, but I think that you would get a discount for normal usage. I think there are different yearly options for different types of usage. It is not only how many users, but also whether it is shareable or not and other criteria involved in each feature. There are additional fees for the users and hardware linked to the processing.

We evaluated JMeter and LoadRunner together to form the selection process. For some scenarios we can use LoadRunner for specification road testing, while for other types of testing we prefer JMeter.

When you compare other products to LoadRunner, LoadRunner has been in the market for a long time. You could use it to integrate with everything. Also, it can generate an input that we can use in any version, it can improve our performance, and we can put input in and we get a command from LoadRunner for that.