JMeter vs Gatling protocol flexibility - jmeter

I read JMeter vs Gatling article and confused over section 9 Flexibility about JMeter:
Flexibility It supports only the HTTP protocol.
And Gatling
It supports HTTP protocol and also a few other protocols as well.
while in introduction it states other protocols for JMeter:
The different types of services can be tested by using the Apache JMeter tool such as Web Services, HTTP, FTP, JMS, LDAP, generic processes or different TCP connections etc.
What is the HTTP protocol restriction the article is referring to? what are Gatling other protocols that defer it from JMeter?
EDIT
Found another discrepancy in section 8 Ease of use, while JMeter describe as
It is a bit difficult to use.
And Gatling:
It is easier to use
It states the opposite in conclusion:
Finally, to conclude JMeter has more number of features and easier to use compared to Gatling.

JMeter supports multiple protocols:
HTTP 1.0
HTTP 1.1
HTTP 2 with 3rd party plugin
JMS
JDBC
LDAP
FTP
SOAP
UDP with 3rd party plugin
MQTT with 3rd party plugin
XMPP with 3rd party plugin
RTE with 3rd party plugin
SSH with 3rd party plugin
And it's highly extensible since its architecture is built with plugins in mind, as of now there are at least 73 OSS plugins and more than 10 commercial plugins.
There is no particular HTTP protocol restriction.
I think the blog is just wrong in formulation and considering all the other errors in it, I am not sure it is worth reading or trusting what is written.
As examples of errors or false statements:
it says JMeter has no dashboard which is wrong since it has the HTML report which contains 17 graphs and 4 tables since version 3.0
difficulty is relative and really depends on type of test being built. Is customization through scala in Gatling simple ?
do you understand this, I don't :
Apache JMeter supports recording the users’ clicks or actions while testing the web applications where as Gatling also supports the user actions and also any other simulated scenarios.
What about those statements :
Apache JMeter is less efficient and effective to be used with odd GUI features that are difficult to use where as Gatling has GUI as well as command line features that provide efficient and effective outputs.
=> What are odd GUI features ?
=> JMeter is an IDE for test building, Gatling uses the test as code approach
Apache JMeter does not have code scripting facility whereas Gatling has the code scripting facility. => Does the author know about JSR223 Test Elements ? functions ?
Apache JMeter has more number of lines of code to configure and setup the testing where as Gatling has less number of lines of code to be used in its’ configuration to run the load tests. => Really ? what are those ?
...

Related

WinInet Implementation in JMeter

I am looking for a small help regarding JMeter. I have one application that is recorded in LoadRunner using WinInet setting (Port Mapping => Capture Level as WinInet).
Is there a way in Jmeter where we can have WinInet setting?
Out of the box it is not possible, JMeter uses either Java sockets or Apache HttpComponents in order to execute HTTP Requests with its HTTP Request sampler. No OS-specific code is included into JMeter so it can be run on all platforms
If your test relies on some very specific features of Windows Internet, be aware that there is no easy way of adding this functionality to JMeter
Developer audience
WinINet is designed for use by C/C++ programmers. It requires a basic understanding of the FTP and HTTP protocols.
So theoretically you can load the .dll(s) implementing WinInet protocol using JNI from JSR223 Test Elements using Groovy language and call the function(s) you need.
However my expectation is that you don't need this and you can just simply convert your LoadRunner script to JMeter using HTTP(S) Test Script Recorder or online LoadRunner/SoapUI to JMeter script converter
Check out How to Convert LoadRunner Tests to JMeter article for more details.

Can we do Load testing for Video or Audio call in jmeter

Is there any way we can do performance testing for voice or video call ? Jmeter or any other open source tools provide anything ? Please reommend any tool if we can achieve this.
It depends on a network protocol which is being used under the hood of the video and/or audio call.
First of all you need to determine which protocol(s) is (are) used by your application. It can be done using a sniffer tool like Wireshark. Once you know the protocol(s) you should be able to check whether JMeter (or other open source tool) supports this protocol or not.
The options could be in:
JMeter supports the protocol out of the box via one of its Samplers. For example if the protocol is simple enough and can be recorded and replayed you can capture the requests using the aforementioned Wireshark and simulate them with the TCP Sampler, however the chance it will work is minimal
JMeter supports the protocol via one of its Plugins
There is a Java (or other language) client library implementing the protocol, in this case you will be able to use JSR223 Sampler and implement the use cases in Groovy (or other language, but it has to be JVM/JSR223 compabitle) or JUnit Request sampler and implement the use cases in Java
The protocol is proprietary and there are no client libraries for it. In this case you won't be able to conduct the load test without reaching out to the call system vendor and asking them for the implementation details and instructions on how it can be tested.
You can use UBIK Load Pack which is a paid version for load test videos using JMeter with free trail
Realistic and Scalable Load Testing for MPEG Dash, Apple's HTTP Live, Microsoft Smooth and Adobe HDS Streaming formats

Jmeter wamp-protocol integration

Here is the story:
we have several servers connected to wamp (crossbar.io)
I am creating load tests for part of this system and need a way to get info from wamp server to Jmeter.
So far I found only WS plugin for Jmeter, but it wont work with wamp.
Any bright ideas?
Clearly wamp is a whole new protocol and JMeter doesn't support it out-of-the-box. Thankfully you can extend JMeter quite easily. If there are java or java family language bindings for your protocol system, you can use beanshell sampler (relatively less performant) or groovy through JSR223 sampler (better performance)
If you feel like it, you can always write up your own Wamp sampler as well.

Can you performance test Siebel applications using JMeter?

Is it possible to record JMeter scripts for performance testing Siebel?
Siebel uses a custom format for ENCODING its requests plus some necessary technical parameters.
So it's possible provided it's the http module but rather hard job as there are a lot of correlations to do on technical IDs.
For recording, see this:
JMeter record Siebel CRM System
You can use this commercial plugin that will do auto-correlation for you:
https://ubikloadpack.com/
Yes, it is possible to test Siebel with JMeter. I have done so for one of my projects with my client TataSky where I have used JMeters distributed testing approach for generating upto 2000 users with 4 - 5 normal desktops. Siebel uses http protocol so it is finally about understanding the requests sent by browser and responses by the web-server and correlating between them. It gets really messy though, so my suggestion is correlate parameters which are mandatory.
You can use JMeter-Siebel-plugin which provides Siebel HTTP(S) Test Script Recorder test element handy for capturing and correlating Siebel traffic.
The plugin can be installed using JMeter Plugins Manager
Check out Introducing the Siebel CRM Correlation Plugin in JMeter article for comprehensive instructions.

JMeter versus The Grinder? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm looking at stress testing our website and having trouble picking the right tool.
It looks to me like two of the most popular are JMeter and The Grinder. Can anyone help with reasons in favor of either?
Thanks!
I have worked a bunch with The Grinder and there are three main reasons I like it.
It's free. I assume from your question, you are only looking at free solutions. There are some excellent commercial products as well, but most of the time, I cannot justify the cost
It is easy to start up processes on other machines. When really trying to crank up load on a cluster, I need to easily distribute the load out to remote machines. Grinder is great for that.
The scripts are all Jython. That allows me to easily customize my scripts to programatically tweak my scripts (e.g. randomize certain paths).
I haven't used JMeter in a long time, so I cannot say authoritatively how it compares on points 2 & 3.
As of Jmeter:
It's free.
it's easy to Start with lot of documentation on its Website and on internet
it has a proxy feature to easily create test plan from browser navigation
It is easy to start up processes on other machines. It remote testing, can be done from GUI or console.
The scripts can be written in beanshell, java, or any jsr223 language ( groovy, Javascript, scala, jexl ...)
it has a lot of built- in samplers and thanks to its plugin architecture it's very Easy to add new ones or use any scripting engine to do what's missing
it has great user mailing list
it has very reactive support
it's now a top Level Apache project
...
Use gatling.
http://gatling-tool.org/
Its lovely, great DSL, and you can just edit the .scala files and rerun and it will compile for you on demand. Also emits very nice graphs
http://gatling-tool.org/sample/index.html
If you're not familiar with Jython (like I wasn't) then there is also a great little tool that comes with Grinder (the TCP Proxy or some such name) that allows you to click around in a webapp and save your actions as a ready-made Jython script for Grinder, which you can then analyse/edit/adopt as necessary.
There is an excellent blog post that describes
Load Test Tools:
Grinder 3.11
Gatling 2.0.0.M3a
Tsung 1.51
JMeter 2.11
The Grinder
The Grinder consists of two main parts:
The Grinder Console - This is GUI application which controls various Grinder agents and monitors results in real time. The console can be used as a basic IDE for editing or developing test suites.
Grinder Agents - These are headless load generators; each can have a number of workers to create the load
Key Features of the Grinder:
TCP proxy - records network activity into the Grinder test script
Distributed testing - can scale with the increasing number of agent instances
Power of Python or Closure combined with any Java API for test script creation or modification
Flexible parameterization which includes creating test data on-the-fly and the capability to use external data sources like files, databases, etc.
Post processing and assertion - full access to test results for correlation and content verification
Support of multiple protocols
Apache JMeter
Key Features of the JMeter:
Cross-platform. JMeter can be run on any operating system with Java
Scalable. When you need to create a higher load than a single machine can create, JMeter can be executed in a distributed mode - meaning one master JMeter machine will control a number of remote hosts.
Multi-protocol support. The following protocols are all supported ‘out-of-the-box’: HTTP, SMTP, POP3, LDAP, JDBC, FTP, JMS, SOAP, TCP
Multiple implementations of pre and post processors around sampler. This provides advanced setup, teardown parametrization and correlation capabilities
Various assertions to define criteria
Multiple built-in and external listeners to visualize and analyze performance test results
Integration with major build and continuous integration systems - making JMeter performance tests part of the full software development life cycle
I just went through the process of trying at both and I would totally agree with Rob here. Grinder also seemed faster, and I really like how simple and lightweight it is compared to Jmeter. The grinder.properties file is totally easy to use, especially if you're more of a console guys then a UI guy.

Resources