Skip to main content

JMeter: Creating First Load Test

What we want to do
  1. Simulate concurrent users
  2. Simulate requests
  3. Generate reports
  4. Troubleshooting

JMeter GUI
Test Pan Plan is a root element where all test related settings are define.
In Thread Group we can define pool of user to simulate load on the test
Work Bench is for non test helpers

Common terms in JMeter
  • User           ⇒ Thread
  • Request     ⇒ Sampler
  • Report       ⇒ Listeners

Setting up the load test

1. Simulate concurrent users

  • Add thread > Thread Group
    • Number of Threads - concurrent users =10
    • Ramp-Up Period - seconds until all users are active =1 (eg. if user define 10 Threads and 100 Ramp-Up Period then, it means each thread will start in 100/10=10 seconds time difference)
    • Loop Count - how many repetitions =1
    • Calculating think time

                                     Ramp-up time                 = 120 seconds
                                     Number of users             =  30
                                     Then think time will be  =  ramp up time/number of users
                                                                            = 120/30 = 4 seconds


    2. Simulate requests

      • Add Sampler > HTTP Request
      • image

    3. Generate reports

    • Add > Listener > Aggregate Graph
    • Add > Listener > View Results Tree

    Running the load test
    • Click on Run > Start or "ctr+r"
    • Click on "Aggregate Graph"
      • Click "Display Graph" for chart




    • Click on "View Results Tree"





    • To Re-run the test
      • Click on Run > Clear All or "ctr+e"
      • Click on Run > Start or "ctr+r"

    View Results Tree hold the "Request" and "Response" data for each request so it's a really good place to verify, if test is running correctly or not.
    "Request" Tab shows data sent to web server
    "Response Data" Tab shows server response body


    Popular posts from this blog

    ERROR: Ignored call to 'alert()'. The document is sandboxed, and the 'allow-modals' keyword is not set.

    Recently I found this issue while writing code snippet in "JSFiddle". And after searching, found this was happening because of new feature added in "Chrome 46+". But at the same time Chrome doesn't have support for "allow-modals" property in "sandbox" attribute.

    Chromium issue for above behavior:

    To make it work you have to add "allow-scripts allow-modals" in "sandbox" attribute, and use "window.alert" instead of "alert".

    <!-- Sandbox frame will execute javascript and show modal dialogs --> <iframe sandbox="allow-scripts allow-modals" src="iframe.html"> </iframe>

    Feature added: Block modal dialog inside a sandboxed iframe.

    Feature working Demo page:

    JavaScript [ExtJs3]: EditorGridPanel Read-Only (dynamically)

    Many time we face the scenerio where we have to make the editor grid read-only dynamically.

    Ext.override(Ext.ux.grid.CheckColumn, { editable: true, onMouseDown: function (e, t) { if ( { e.stopEvent(); var me = this, grid = me.grid, view = grid.getView(), index = view.findRowIndex(t), colindex = view.findCellIndex(t), record =; if (!grid.isReadOnly && grid.colModel.isCellEditable(colindex, index)) { record.set(me.dataIndex, ![me.dataIndex]); } } } }); var grid = new Ext.grid.EditorGridPanel({ ... isReadOnly: true, //set to flag to make check column readonly ... }); //to make other column readonly grid.on('beforeedit', function () { return false; });

    CSS Specificity

    Many time different CSS rules overlap on one or more element. And some people always get confuse about, which rule will take higher priority then other and why? CSS Specificity is the answer of all these kind of questions.
    As the name suggest, the CSS rule which is more specific to the element will take higher priority then other. Means something like “#some_id{}” will always take higher priority then “*{}” universal selector.  And if duplicate rules are define then the last rule will be applied to the element.

    The following list of selectors is by increasing specificity:
    Type selector (e.g., div) and pseudo-elements in selector (e.g., :after) Class selectors (e.g., .some_class), attributes selectors (e.g., [type=”radio”]) and pseudo-class selector (e.g., :hover) Id selectors (e.g., #some_id)

    ID takes higher priority then Class, Type and Universal selector (Note: Universal selector has no effect on specificity, see below special conditions). 

    If duplicate rules are given, then last…