Monday, August 28, 2017

AWR—"log file sync" Wait Event Analysis

There are some DB wait events could be caused by poor storage performance in Oracle.  For example,
In this article, I will discuss the log file sync wait event in Oracle AWR reports, which in many cases is caused by poor storage performance.

Top 10 Foreground Events by Total Wait Time


EventWaitsTotal Wait Time (sec)Wait Avg(ms)% DB timeWait Class
DB CPU2590.996.6
SQL*Net break/reset to client5,864,510546.4020.4Application
log file sync19,57525.511.0Commit
SQL*Net message to client15,493,939100.4Network
library cache: mutex X8,042.60.0Concurrency
db file sequential read93.55.0User I/O
direct path read158.32.0User I/O
Disk file operations I/O89.11.0User I/O
SQL*Net more data to client945.10.0Network
cursor: pin S39.11.0Concurrency

Log File Sync


An Oracle user session issuing a commit command must wait until the LGWR (Log Writer) process writes the log entries associated with the user transaction to the log file on the disk. Oracle must commit the transaction’s entries to disk (because it is a persistent layer) before acknowledging the transaction commit. The log file sync wait event represents the time the session is waiting for the log buffers to be written to disk.

Sometimes you can find "log file sync" wait event appears on the top list of an AWR report:
Top 10 Foreground Events by Total Wait Time

What does it mean if log file sync is shown on the list?[1]
  • Is this noticeably slowing down all commits?
    • Disk throughput is only one aspect that affects LGWR. It consumes CPU while executing too. 
      •  If you've maxed out your CPU capacity processing "business transactions", then it will be starved for resource. This can lead to you seeing a lot of "log file sync" waits. 
      • If your datafiles are on the same disks as the redo logs, then DBWR will also be contending for the same disk. 
  • Is it just the top wait event on your system? 
    • Remember that there's always something that has to be "top". 

How to Reduce "log file sync" Wait Time


When a user commits or rolls back data, the LGWR flushes the session's redo from the log buffer to the redo logs. The log file sync process must wait for this to successfully complete.

If log file sync is a problem (e.g., avg wait > 2 ms), try the following solutions based on its causes:[1-4]
  • Slow disk I/O
    • Reduce contention on existing disks
    • Put log files on faster disks and/or increasing the log_buffer size above 10 megabytes
    • Put alternate redo logs on different disks to minimize the effect of archive processes (log files switches)
  • LGWR is not getting enough CPU
    • If the vmstat runqueue column is greater than cpu_count, then the instance is CPU-bound and this can manifest itself in high log file sync waits. The solution is to 
      • Tune SQL (to reduce CPU overhead)
      • Add processors
      • 'Nice' the dispatching priority of the LGWR process
  • High COMMIT activity
    • Review application design, use NOLOGGING operations where appropriate, and reduce the frequency of COMMIT statements in the application
  • LGWR is paged out
    • Check the server for RAM swapping, and add RAM if the instance processes are getting paged-out.

References

  1. Log file sync wait (Ask TOM)
  2. Log file sync wait
  3. Oracle Log File Sync Wait Event
  4. Expert Consolidation in Oracle Database 12c
  5. AWR Wait Events: Free Buffer Waits vs. Buffer Busy Waits (Xml and More)

Saturday, August 19, 2017

JMeter—How to Reorder and Regroup JMeter Elements

The JMeter test tree contains elements that are both hierarchical and ordered. Some elements in the test trees are strictly hierarchical (Listeners, Config Elements, Post-Processors, Pre-Processors, Assertions, Timers), and some are primarily ordered (controllers, samplers).[1,7]

When you add a new JMeter element to a parent element (i.e,. Test Plan, Thread Group, etc.), it adds the new element to the end of child list.  So, sometimes you need to reorder element on the list or regroup elements under different parent elements.  For this purpose, the following JMeter's GUI supports come in handy:
  • Drag and drop
  • Cut, copy, and paste
 In this article, we will demonstrate these editing capabilities of Apache JMeter.

Cut, Copy and Paste (Case #1)


In the following Test Plan, we have three different Thread Groups under Test Plan.  At beginning, all child elements were listed under jp@gc - Stepping Thread Group.


To move these child elements into Thread Group, I can click on CSV Data Set Config, press Shift Key, select all child elements using Down Arrow, and Ctrl-X to cut them.


To paste them into Thread Group, I click on Thread Group, and Ctrl-V to paste them.


In this scenario, it will be easy for you to experiment with three different Thread Group plugins and learn their different capabilities.

Cut, Copy, and Paste (Case #2)


Sometimes you want to copy JMeter elements from one .jmx to another .jmx.  In this case, you can launch two JMeter GUI's following the instructions here .  For example, you can click on jmeter.bat twice to start two different JMeter sessions in Windows.


After you open two Test Plans in two different GUI's, you can then copy-and-paste element from one JMeter to another similar to the previous example.



Drag and Drop


For elements stored in the test tree, you can also drag-and-drop them from one position to another or change their levels in the tree hierarchy.  Note that the level of elements in the test tree determines the scope of its effect.  Read [1,6,7] for more information.

To drag a child element from one position to another position, for example,  I can click on HTTP Cache Manager,


drag it to a new position (i.e., before HTTP Cookie Manager), and drop it.


Note that the ordering of Cookie and Cache Managers in this example doesn't matter.  Read [6] and [7] for the details of execution order and scoping rules in JMeter.

References

Monday, August 14, 2017

JMeter―Using the Transaction Controller

Apache JMeter is a performance testing tool written in Java and supports many operation systems. Controllers are main part of JMeter and they are useful to control the execution of JMeter scripts for load testing.  Logic controllers (e.g., Transaction Controller) also provide runtime scopes for JMeter test elements (read [9] for details).

For example, you can use Transaction Controller to get the total execution time of a transaction (i.e., an end-to-end scenario) which might include the following transaction steps:
Login → Compute Details → Billing Metrics → Back to Dashboard → Logout

Watch this video on YouTube for more details of Transaction Controller.

Controllers


JMeter has two types of Controllers:[3]

  • Samplers
    • Can be used to specify which types of requests to be sent to a server
    • You may add Configuration Elements to these Samplers to customize your server requests.
    • Examples of Samplers include, but not limited to:
      • HTTP Request
      • FTP Request
      • JDBC Request
      • Java Request
      • SOAP/XML-RPC Request
      • WebService (SOAP) Request
      • LDAP Request
      • LDAP Extended RequestAccess Log Sampler
      • BeanShell Sampler
  • Logic Controllers
    • Can be used to customize the logic that JMeter uses to decide when to send requests
      • For these requests, JMeter may randomly select (using Random Controller), repeat (using Loop Controller), interchange (using Interleave Controller) etc.
      • The child elements of a Logic Controllers may comprise 
    • Examples of Logic Controllers include, but not limited to:
      • Transaction Controller
      • Simple Controller
      • Loop Controller
      • Interleave Controller
      • Random Controller
      • Random Order Controller
      • Throughput Controller
      • Recording Controller
In this article, we will focus mainly on Transaction Controller which may be used to
  • Generate a “virtual” sample to measure aggregate times of all nested samples




Option: "Generate Parent Sample"


When "Generate parent sample" in Transaction Controller is
  • Checked 
    • Only Transaction Controller virtual sample will be generated and  all other Transaction Controller's nested samples will not be displayed in the report
  • Unchecked 
    • Additional parent sample (i.e. Transaction Controller virtual sample) after nested samples will be displayed in the report

Option: "Include Duration of Timer and Pre-Post Processors in Generated Sample"


Each Sampler can be preceded by one or more Pre-processor element, followed by Post-processor element. There is also an option in Transaction Controller to include and/or exclude timers, pre and post processors execution time into/from virtual samples.

When the check box "Include duration of timer and pre-post processors in generated sample" is
  • Checked
    • The aggregate time includes all processing within the controller scope, not just the nested samples
  • Unchecked
    • The aggregate time includes just the nested samples; however, excludes all pre-post processing within the controller scope


Sunday, August 13, 2017

JMeter: Using the HTTP Cookie Manager

In a stateless internet, many sites and applications use cookies to retain a handle between sessions or to keep some state on the client side. If you are planning to use JMeter to test such web applications, then cookie manager will be required.

To learn how to enable HTTP Cookie Manager and run tests in JMeter, you can watch below video.


HTTP Cookie Manager Usage & Example in JMeter (YouTube link)

In this article, we will cover two topics:
  1. Why cookie manager?
  2. Where to put cookie manager?

Why Cookie Manager


If you need to extract a cookie data from response body, one option is to use a Regular Expression Extractor on the response headers.[4] Another simpler option is adding a HTTP Cookie Manager which automatically handles cookies in many configurable ways.

HTTP Cookie Manager has three functions:
  1. Stores and sends cookies just like a web browser
    • Each JMeter thread has its own "cookie storage area".
      • Note that such cookies do not appear on the Cookie Manager display, but they can be seen using the View Results Tree Listener.
  2. Received Cookies can be stored as JMeter thread variables
    • Versions of JMeter 2.3.2+ no longer do this by default
    • To save cookies as variables, define the property "CookieManager.save.cookies=true" by
      • Setting it in jmeter.properties file, or
      • Passing a corresponding parameter to JMeter startup scrip
        • jmeter -JCookieManager.save.cookies=true
    • The names of the cookies contain the prefix "COOKIE_" which can be configured by the property "CookieManager.name.prefix"
    • See [4] for an example
  3. Supports adding a cookie to the Cookie Manager manually
    • Note that if you do this, the cookie will be shared by all JMeter threads—such cookies are created with an expiration date far in the future.

Where to Put Cookie Manager


Nearly all web testing should use cookie support, unless your application specifically doesn't use cookies. To add cookie support, simply add an HTTP Cookie Manager to each Thread Group in your test plan. This will ensure that each thread gets its own cookies, but shared across all HTTP Request objects.

To add the HTTP Cookie Manager, simply select the Thread Group, and choose AddConfig ElementHTTP Cookie Manager, either from the Edit Menu, or from the right-click pop-up menu.

References

  1. Using the HTTP Cookie Manager in JMeter
  2. Understanding and Using JMeter Cookie Manager
  3. Adding Cookie Support
  4. Header Cookie “sid” value to a variable
  5. Using RegEx (Regular Expression Extractor) with JMeter
  6. JMeter: How to Turn Off Captive Portal from the Recording Using Firefox (Xml and More)
  7. JMeter—Use Extractors (Post-Processor Elements) for Correlation (Xml and More)

Friday, August 11, 2017

JMeter: How to Turn Off Captive Portal from the Recording Using Firefox

Apache JMeter is an Apache project that can be used as a load testing tool for analyzing and measuring the performance of a variety of services, with a focus on web applications.

Assume you have installed JMeter and are familiar with it; otherwise, you can watch a good series of videos here to get started.  In this article, we will discuss how to remove the extra HTTP request (1 /success.txt ) in the recording (click below diagram to enlarge).


HTTP(S) Test Script Recorder


You can follow the instructions here to record your web test with "HTTP(S) Test Script Recorder".  In this article, we have chosen Firefox as the browser for JMeter's proxy recorder.

When we recorded a test plan, some repetitive HTTP requests related to Captive Portal feature in Firefox
GET http://detectportal.firefox.com/success.txt
have been captured.  These HTTP traffics are not related to the tested web application and should be excluded from the test plan.  So, how can we achieve that?


How to Turn Off "Captive Portal"


Captive Portal feature in Firefox covers the detection and implementation of handles for captive portals inside Firefox browser. Firefox is expected to handle the handling of a captive portal page upon detection of such.

There is no UI checkbox for disabling Captive Portal.  But, you can turn off Captive Portal using the Configuration Editor of Firefox:[3]
  1. In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful.
  2. In the search box above the list, type or paste captiv and pause while the list is filtered
  3. Double-click the network.captive-portal-service.enabled preference to switch the value from true to false
If you are in a managed environment using an autoconfig file, for example, you could use this to switch the default:
user_pref("network.captive-portal-service.enabled", false)


References

  1. Apache JMeter
  2. JMeter Beginner Tutorial 21 - How to use Test Script Recorder
  3. HTTP(S) Test Script Recorder 
  4. Proxy Step by Step (Apache JMeter)
  5. Book: Apache JMeter (Publisher: Packt Publishing) 
  6. Turn off captive portal (Mozilla Support)
  7. JMeter—Use Extractors (Post-Processor Elements) for Correlation (Xml and More)