We deliver it to the clients about the reports etc.

We have clients for whom we are upgrading their applications from old versions to new ones. Initially, we conduct assessments to compare the performance of the old applications with the new ones. For example, we might upgrade an application from a desktop environment to a web application. After the upgrade, we demonstrate how the new application handles load across the front end, API, and database. For this purpose, we use performance testing tools to showcase the improvements.

It is focused on concurrency testing, which has been especially beneficial for us. Their previous experiences had caused major setbacks.

The pricing is high because the advanced version comes with different features. Unlike JMeter, which offers a free version, BlazeMeter requires you to upgrade to a higher tier to access those advanced features.

BlazeMeter comes with a cost, so our client must agree. We've settled for the basic plan, which limited our ability to explore the higher versions. This is one drawback, especially since JMeter already provides many features that are out of the box. However, a positive aspect of BlazeMeter is that it offers various options for capturing different formats, such as JSON, XML, etc.

I have been using BlazeMeter for seven months.

It is stable. It depends on the client's requirements. There's no hard-n-fast rule. We have multiple clients, and when they request it, we perform the testing for them. It's done once a week or once a month, depending on the needs. Unlike KN automation, it's not a regular process. We conduct performance testing primarily for assessment purposes and system improvements based on client requirements.

It is scalable but distributed, and everything comes with a price. We haven't explored much but expect to explore in the future.

We are around five to six people using BlazeMeter in our organization.

We are experiencing some delays with BlazeMeter, as running or executing tests takes a bit of time. For example, running a test with a hundred clicks for a conference user takes approximately twenty minutes. This is one of the issues we're facing. We're exporting from BlazeMeter and importing the test into JMeter for the KN to address this.

I rate the solution’s scalability a seven out of ten.

We switched to BlazeMeter because of issues related to proxy handling in JMeter. BlazeMeter is more reliable in managing proxy errors, which was a significant reason for our transition. It also supports custom configurations, allowing you to define your own ports, etc. Additionally, BlazeMeter provides multiple options for recording and storing test scripts, which can be easily converted to UI or GUI formats. These features were the primary reasons for our switch to BlazeMeter.

The initial setup is not difficult. There is ready documentation and some videos to guide you.

It is a bit pricey, especially if you're primarily interested in its recording and script conversion features. However, you'll need to opt for the higher-priced plans to access advanced features like scalability and distribution, as these features aren't included in the basic version. Additionally, the resources available in the basic plan are limited compared to the higher tiers.

Report-wise, everything is good. However, the execution time is slightly higher compared to other tools. Everything is consistent regarding recording, and I haven't encountered any bugs. However, the execution time is inconsistent. Sometimes, when I run the same script at different times, it takes longer to execute.

Overall, I rate the solution a seven or eight out of ten.

The solution is used as a performance system.

It has a unique programming dashboard that is very user-friendly. The auto-collision feature is also robust.

The scanning capability needs improvement.

I have been using BlazeMeter for a year.

The solution is highly scalable. Five people are using the solution at present. I rate the scalability an eight out of ten.

The initial setup is straightforward. The deployment takes few minutes time and a couple of people were involved in the process.

Overall, I would rate the solution a seven out of ten.

Whenever I am not able to record the script with the JMeter, I use BlazeMeter extensions to record the scripts. Whenever there is a need to execute something in the cloud, my company uses BlazeMeter.

There are some advantageous features that are available in BlazeMeter. The type of HTML reports that can be downloaded from BlazeMeter can be shown to the clients so that they can be provided with a clear picture in a clean way, allowing even a layperson to be able to understand the metrics our company shows with the help of BlazeMeter.

Whenever we use BlazeMeter for the ramp-up and designing the scenarios in our company, we also use JMeter or other load testing tools, which provide some convenience in areas where the granularity can be maintained in seconds. The ramp-up and ramp-down require our company to use the granularity for a few minutes, making it an area where improvements are required to be able to use the granularity in seconds. From a performance perspective, BlazeMeter needs to be improved.

Whenever we discuss the development stage, JMeter has plug-ins and other extensions in the area of WebSockets, and it is the same case in terms of the kind of extensions provided by JMeter that are available in LoadRunner. BlazeMeter has not found the extensions for WebSockets or Java Applet. Decoding the scripts that contain the applications with Java Applet is not possible with BlazeMeter or even with JMeter, and it includes some Oracle and desktop applications, too.

I have experience with BlazeMeter.

I didn't get much opportunity to work on the tool, but as per my experience, I can say that BlazeMeter serves as an alternate tool whenever my company faces some hurdles or challenges with the JMeter and k6. To record the scripts, I use BlazeMeter as an extension. With BlazeMeter, it is very easy to identify if a request belongs to an application or not, and in the initial phase itself, we can neglect the requests that don't belong to the application. In BlazeMeter, depending upon the requests, users can select a particular domain.

Though the product is scalable, I found the tool to be a bit tricky while setting up the scenario for the stress test and during step-up and step-down kind of scenario setup.

I have experience with Grafana and JMeter.

Whenever a comparison is made between JMeter and BlazeMeter, there are a lot of differences one can observe. With JMeter, our company has to concentrate on the features as it is an open-source tool that works with Java. The configuration of the systems should have some high-end configuration, and the heap size depends upon the load our company uses. JMeter can be used in UI or GUI mode or in a non-GUI mode. If users have to go with a smoke test and the preparation of scripts, the GUI mode of JMeter can be used. For the actual execution of load testing, we have to go with JMeter's non-GUI mode. With the non-GUI mode, until the completion of the test, I could see the percentage of the error, but I couldn't see what kind of error was there in the application. In JMeter, I had to wait until the completion of the entire test. When we use the BlazeMeter cloud as a licensed tool in our company, we do have to deal with the setup of any configuration area. With BlazeMeter, whenever our company executes the load test, parallelly we can monitor what kind of errors we get, and if possible, we can have a word with the development team in parallel and we can solve all the issues so we don't need to wait until the completion of the tests as some of them may be longer than thirty minutes to an hour. In current situations, everything works in the cloud, and every request and every click gets counted in the cost. In BlazeMeter, there is no need to wait till completion of the one hour or until the end of the testing phase. BlazeMeter provides better reporting, but it takes much longer to do so, making it an area of concern where improvements are required. It is not always sufficient to only use BlazeMeter.

The product's initial setup phase was simple.

The solution can be deployed in less than five minutes.

When compared with the cost of the licenses of other tools, BlazeMeter's license price is good.

Currently, I am looking out for Java Applet and Oracle applications. I want something that will support the load testing phase for the tools that Java Applet and Oracle support.

I rate the overall tool between six and seven out of ten.

I use BlazeMeter for the different samplers it provides.

The product currently doesn't allow users to run parallel thread groups, making it an area that should be considered for improvement.

I have been using BlazeMeter for two years. My company is a customer of the solution.

Right now, I don't know about the product's stability. I did not experience any downtime or performance issues with the solution.

For support, I generally use Google or other online sources.

Though I have experience with a solution from OpenText, I feel BlazeMeter is the best. The main reason my company chose BlazeMeter was because it was preferred by one of our clients.

The product's initial setup phase was straightforward.

The product's installation deployment phase

The solution can be deployed in thirty minutes.

The solution did not help save money or time, and neither did it improve security since it was mainly used in our company to deal with the network part.

I have not integrated the tool with any other solutions.

Though it is a good tool, there are certain areas where improvements are required in the product.

Compared to BlazeMeter, multiple options are available in the market for people to choose from to meet their requirements.

I rate the overall solution a seven out of ten.

Most of my company's use cases related to the tool stem from the needs of our customers. Basically, my company deals in the area of using the tool for mimicking contact center-related scenarios. When a customer calls an agent, the tool helps check whether the agent answers the call.

Basically, my company wanted to use BlazeMeter to act as a trigger for around 1,05,000 users who communicate with each other. For the aforementioned aspect, the first option was to choose between NeoLoad and LoadRunner, while the second option was to choose BlazeMeter, which runs on the cloud. With Blazemeter, it was easy for my company to create a script and then trigger it.

The most valuable features of the solution stem from the fact that BlazeMeter provides easy access to its users while also ensuring that its reporting functionalities are good. Users can schedule BlazeMeter to run, especially when the need to build a new application comes up since it allows them to manage and know the performance parameters easily.

For a new user of BlazeMeter, it might be difficult to understand it from a programming perspective. BlazeMeter should provide its users with a seamless experience in the area of programming. The tool should be made in such a way that in whatever scenario a need arises for it, new users should be able to use it without difficulty. It will be better if BlazeMeter can handle call scenarios using behavior-driven development, allowing technical and non-technical people to understand the tool.

The technical support team's turnaround time or response time is high, making it one of the product's shortcomings that requires improvement.

I have been using BlazeMeter for three and a half years. I am a user of the solution.

Stability-wise, I rate the solution a seven out of ten.

The scalability of BlazeMeter is good. The scalability of BlazeMeter is good. As BlazeMeter is a tool that allows me to trigger over 1,00,000 deployment-wise, I consider its scalability to be good.

Scalability-wise, I rate the solution a seven out of ten.

Around five or six people in my company use BlazeMeter.

I rate the technical support a six out of ten.

I have experience with LoadRunner and TAF.

I rate the setup phase of BlazeMeter a seven and a half on a scale of one to ten, where one is a difficult setup process and ten is an easy setup phase.

BlazeMeter can be deployed in three to four minutes, especially if the scripts and artifacts are ready, as users may only need to push the ready artifacts into their environments to trigger the deployment process.

The solution is deployed on the cloud.

My company has opted for a pay-as-you-go model, so we don't make use of the free version of the product. The pricing part of BlazeMeter is fine, in my opinion. BlazeMeter is not a super expensive product for corporate businesses, considering that the product has evolved into a much more stable software.

Against BlazeMeter, my company had evaluated other options like NeoLoad and Visual Studio. Though all the options evaluated by my company were okay products in the market, BlazeMeter offers a more stable product. When using BlazeMeter, my company can get support and figure out areas where we lag through Google. BlazeMeter has a strong customer base.

BlazeMeter offers options like test scope that provide visibility of what a user does. Moreover, the option provides users with a crystal clear outline of every step, which consists of things like what the request is for a particular response.

Considering its load-testing capabilities, I recommend BlazeMeter to those who plan to use it. It's a good tool that anyone can use either in their production environment or before entering the production phase. The tool performs well even with real traffic while providing good scalability options to its users.

I rate the overall tool a seven and a half out of ten.

I work in a bank where we use BlazeMeter to conduct our load testing or performance testing. In our company, we utilize multiple machines, and multiple projects are hosted on BlazeMeter.

The baseline comparison in BlazeMeter is very easy, especially considering the different tests that users can easily compare. The response time and the calls we make in our company are easy to trace with the help of BlazeMeter.

There is a tab in Blazemeter named Request Stats Report where improvements are required. If I have to go and find a particular timeline, which might be in a 15 or 20-minute window, there are no places or options where I can enter the perfect or exact timelines I want to find. You have the pointers to drag from one place to another, but that doesn't give me much freedom to get or find a timeline. Basically, on a tab in Blazemeter named Request Stats Report, there should be the start time and end time. In BlazeMeter's Request Stats Report, users should have an option where they can select and manually enter the test start and test end time to get the stats for a particular time period.

Scalability is an area of concern in BlazeMeter, where improvements are required.

I have been using BlazeMeter for a year.

The load testing time in BlazeMeter is too high since, in our company, we have seen that it takes four to five minutes to do an entire load testing process, and after that, we run the tests, which is a big problem for us.

Stability-wise, I rate the solution a five out of ten.

I see certain limitations when it comes to the scalability part of BlazeMeter since, in our company, we have faced multiple interruptions, because of which we had to stop certain testing processes.

Scalability-wise, I rate the solution a five out of ten.

I cannot give you an exact number related to the number of users of BlazeMeter in our company since we are just one of the teams in the company that uses the tool. I believe that around 150 to 200 people in my company use BlazeMeter.

I rate the technical support an eight out of ten.

I only have experience with BlazeMeter.

I rate the product's initial setup around seven on a scale of one to ten, where one is a difficult setup, and ten is an easy setup.

The time taken for the deployment of BlazeMeter varies since we have multiple types of applications in our company. If I have to deploy something on BlazeMeter, the time range for the deployment process can be somewhere between 30 to 120 minutes.

The solution is deployed on the cloud.

BlazeMeter is a supportive tool in terms of the fact that it is easy to migrate from one system to another. BlazeMeter offers an easy infrastructure that allows for migration, if needed, in a well-organized manner, but it is not an optimized tool yet since I still see a lot of problems in it.

I rate the overall tool a seven out of ten.