Thursday, 26 March 2020

Linux Metricbeat Counters Mapping

Performance Counters Linux

We are using counters provided by metricbeat modules, iostat, sar

Server Stats

CPU [Command: /proc/stat]           

CPU Total

( ( system.cpu.user.pct + system.cpu.system.pct ) / system.cpu.cores ) * 100

Total User

( system.cpu.user.pct / system.cpu.cores ) * 100

Total System

( system.cpu.system.pct / system.cpu.cores ) * 100

CPUIOWait

( system.cpu.iowait.pct / system.cpu.cores ) * 100
Above 4 metrics were extracted from metricsets system.cpu.user.pct, system.cpu.system.pct and system.cpu.cores
system.cpu.user.pct The percentage of CPU time spent in user space. On multi-core systems, you can have percentages  that are greater than 100%. For example, if 3 cores are at 60% use, then the system.cpu.user.pct will be 180%.
system.cpu.system.pct The percentage of CPU time spent in kernel space.
system.cpu.cores The number of CPU cores present on the host.
system.cpu.iowait.pct The percentage of CPU time spent in wait (on disk)
               

Memory [Command: /proc/meminfo]

Total Memory (MB)

 ( system.memory.total / 1024 / 1024 )
Total amount of physical RAM in the machine

Used Memory (MB)

( system.memory.used.bytes / 1024 / 1024 )
Amount of physical memory used by system

Actual Used Memory (MB) { MemFree - Buffers – Cached }

 ( system.memory.actual.used.bytes / 1024 / 1024 )        

Total Swap Memory (MB)

( system.memory.swap.total.bytes / 1024 / 1024 )

Used Swap Memory (MB)

( system.memory.swap.used.bytes / 1024 / 1024 )

Disk [Command: iostat -dxk]

DiskReadsPerSec

The number of read requests that were issued to the device per second.

DiskWritesPerSec

The number of write requests that were issued to the device per second.

DiskReadKBPerSec

The number of read requests that were issued to the device per second.

DiskWriteKBPerSec

The number of kilobytes written to the device per second.

DiskQueueLength

The average queue length of the requests that were issued to the device.

DiskReadWaitTime

The average time (in milliseconds) for read requests issued to the device to be served.

DiskWriteWaitTime

The average time (in milliseconds) for write requests issued to the device to be served.

Network [Command: sar -n DEV]

ReceivedBytesRate

Total number of kilobytes received per second.

TransmittedBytesRate

Total number of kilobytes transmitted per second.

PacketsReceivedRate

Total number of packets received per second.

PacketsTransmittedRate

Total number of packets transmitted per second.

MongoDB Insights

the server information.

MongoDB operation counters [Command: db.serverStatus().opcounters]

This visualization gives count of following number of operations since mongo instance start

Command

The total number of commands issued to the database since the mongod instance last started.

Delete

The total number of delete operations received since the mongod instance last started.

GetMore

The total number of getmore operations received since the mongod instance last started.

Insert

The total number of insert operations received since the mongod instance last started.

Query

The total number of queries received since the mongod instance last started.

Update

The total number of update operations received since the mongod instance last started.

MongoDB WiredTiger Cache [Command: db.serverStatus().wiredTiger.cache]

WiredTiger is tefault srorage engines used in mongodb. It has some cool features like MVCC, Document level concurrency and journal (write-ahead log).
Default internal cache size is larger of either:
·         50% of (RAM - 1GB), or
·         256 MB

Max

Maximum cache size

Used

Size in byte of the data currently in cache.

Dirty

Size in bytes of the dirty data in the cache.
This is the size of the dirty data in the cache. This value should be less than the bytes currently in the cache value. Looking at these values, we can determine if we need to up the size of the cache for our instance. Additionally, we can look at the wiredTiger.cache.bytes read into cache value for read-heavy applications. If this value is consistently high, increasing the cache size may improve overall read performance.

MongoDB asserts [Command: db.serverStatus().asserts]

number of assertions raised since the MongoDB process started. If there are non-zero values for the asserts, you should check log file for information.

Message

The number of message assertions raised since the MongoDB process started.

Regular

The number of regular assertions raised since the MongoDB process started.

Rollover

The number of times that the rollover counters have rolled over since the last time the MongoDB process started. The counters will rollover to zero after 230 assertions. Use this value to provide context to the other values in the asserts data structure.

User

The number of “user asserts” that have occurred since the last time the MongoDB process started. These are errors that user may generate, such as out of disk space or duplicate key. You can prevent these assertions by fixing a problem with your application or deployment.

Warning

the number of warnings raised since the MongoDB process started.

MongoDB Concurrent transactions Read [Command: db.serverStatus().wiredTiger.concurrentTransactions]

Returns information on the number of concurrent of read and write transactions allowed into the WiredTiger storage engine. Default value is 128.

Read Available

Number of concurrent read tickets available.

Read Used

Number of concurrent read transaction in progress.

Write Available

Number of concurrent read tickets available.

Write Used

Number of concurrent read transaction in progress.

Modelling - Mongo DB - Wired Tiger - Log Writes [Command: db.serverStatus().wiredTiger.log]

Log Writes

Number of write operations.

Modelling - Mongo DB - Wired Tiger - Log Writes (Bytes) [Command: db.serverStatus().wiredTiger.log]

Log Writes (Bytes)

Number of bytes written into the log.

Modelling - Mongo DB - Wired Tiger - Log Syncs [Command: db.serverStatus().wiredTiger.log]

Log Syncs

Number of sync operations.

Modelling - Mongo DB - Wired Tiger - Log Max Size (Bytes) [Command: db.serverStatus().wiredTiger.log]

Log Max Size (Bytes)

Maximum file size. This is constant value set.

Modelling - Mongo DB - Wired Tiger - Log Flushes [Command: db.serverStatus().wiredTiger.log]

Log Flushes

Number of flush operations.

Modelling - Mongo DB - Wired Tiger - Log Scans [Command: db.serverStatus().wiredTiger.log]

Log Scans

Number of scan operations.

Modelling - Mongo DB - Wired Tiger - Log Size [Command: db.serverStatus().wiredTiger.log]

Log Size (Bytes)

Total log size in bytes.

Modelling - Mongo DB - Wired Tiger - Log Cache Pages Read [Command: db.serverStatus().wiredTiger.log]

Cache Pages Read

Number of pages read into the cache. If this value is consistently high, increasing the cache size may improve overall read performance.

Modelling - Mongo DB - Wired Tiger - Log Cache Pages Write [Command: db.serverStatus().wiredTiger.log]

Cache Pages Write

Number of pages written from the cache.

Modelling - Mongo DB - Wired Tiger - Cache Pages Evicted[Command: db.serverStatus().wiredTiger.log]

Cache Pages Evicted

Number of pages evicted from the cache.

Modelling - Mongo DB - Wired Tiger - Cache Dirty Bytes[Command: db.serverStatus().wiredTiger.log]

Cache Dirty Bytes

Size in bytes of the dirty data in the cache. This value should be less than the bytes currently in the cache value.

Modelling - Mongo DB - Resident Memory (MB) [Command: db.serverStatus().mem]

Resident Memory (MB)

The amount of RAM, in megabytes (MB), currently used by the database process.

Modelling - Mongo DB - Virtual Memory (MB) [Command: db.serverStatus().mem]

Virtual Memory (MB)

The amount, in megabytes (MB), of virtual memory used by the mongod process.

Modelling - Mongo DB - Memory Stats (MB) [Command: db.serverStatus().mem]

Resident

The amount of RAM, in megabytes (MB), currently used by the database process.

Virtual

The amount, in megabytes (MB), of virtual memory used by the mongod process.

Mapped

The amount of mapped memory, in megabytes (MB), used by the database. Because MongoDB uses memory-mapped files, this value is likely to be to be roughly equivalent to the total size of your database or databases.

Mapped with Journal

The amount of mapped memory, in megabytes (MB), including the memory used for journaling.

Modelling - Mongo DB – Objects

Modelling - Mongo DB – Objects

Modelling - Mongo DB - Total Connections Created [Command: db.serverStatus().connections]

Total Connections Created

The total number of current clients connected to this instance

Modelling - Mongo DB - Current Connections Created [Command: db.serverStatus().connections]

Current Connections Created

The total number of current clients connected to this instance

Modelling - Mongo DB - Available Connections Created [Command: db.serverStatus().connections]

Available Connections Created

The total number of unused connections available to clients for this instance

Modelling - Mongo DB - Indexes and Collections

Indexes

Number of indexes

Collections

Number of collections

MongoDB Journalling

To provide durability in the event of a failure, MongoDB uses write ahead logging to journal files in Disk. WiredTiger uses checkpoints to recover.
With journaling, WiredTiger creates one journal record for each client initiated write operation. The journal record includes any internal write operations caused by the initial write. For example, an update to a document in a collection may result in modifications to the indexes; WiredTiger creates a single journal record that includes both the update operation and its associated index modifications.
MongoDB configures WiredTiger to use in-memory buffering for storing the journal records. Threads coordinate to allocate and copy into their portion of the buffer. All journal records up to 128 kB are buffered.
WiredTiger syncs the buffered journal records to disk upon many conditions.
Below picture depicts the simple illustration is log write operations






MongoDB Jounal
Below picture depicts the simple illustration is log write operations
MongoDB stats are extracted from serverStatus collection. This Collection has documents that gives 


Sunday, 12 January 2020

JMeter - Selenium


Objective
POC to perform test with JMeter Selenium Web driver that helps in analysis of client side performance

Observation
We have observed following four major hurdles during the process
1.       JMeter WebDriver Compatibility
2.       Code Reusability
3.       Sub Sample Timer
4.       Response time variation

JMeter WebDriver Compatibility with Application
JMeter Webdriver sampler has limited set of options during instantiation. Application automation will be blocked with this limitation. One such example is popup to accept/reject notifications during login.
This pop should be disabled before performing any actions in the web page and there is no such option to handle in JMeter by default.
Resolution
  • We have overcome this by tweaking code in the plugin and adding required chrome options that were picked during instantiation.


Code Maintenance 
With script editor provided by Jmeter Webdriver, there are following 3 challenges
1.       Duplicate locators for same web elements
2.       Test script maintenance
3.       readability 
Resolution
  • We have implemented Page Object Model for webpage action automation. This has been achieved by importing the web page objects to the JMeter.


Sub Sample Timer 
JMeter provides a function to capture timing for individual parts of the script. But, this data will only be available in View Results tree element and not in Results table or Result file
For example for a transaction Login with LoginPage, TenantSelectionPage, HomePage as sub areas, following is the result
Output - View Results tree  
                                Machine generated alternative text:
LoginPage 
ogn age 
TenantSeIectonPage 
Homepage 
FileCabinetPage 
2. NavigateToFiIeCabinet 
DynamicReportFoIderPage 
3. NavigateToFoIder 
DynamicReportPage 
4RUnDynamicReport 
aackToLoginPage 
5. Logout 
Sampler result Request Resguynse data 
Thread Name: Thread Group I-I 
sample start: 2019-10-22 
Load time: 27689 
Latency: O 
Size in bytes: O 
Headers size in bytes: O 
Body size in bytes: O 
Sample Count: I 
Error Count: O 
Response code: 
Resguynse message: 
Resw•se headers: 
SampleResuI t fields: 
ContentType: 
Da taEncoding : null

Output - View Results Table 
                                Machine generated alternative text:
Status 
LoginPage 
I. Login 
FileCabinetPage 
2. NavigateToFiIeCabinet 
DynamicReportFoIderPage 
3. NavigateToFoIder 
DynamicReportPage 
4 RunDynamicReport 
aa ckToLoginP ag e 
5. Logout 
Sample Time (ms) 
30993 
30993  
Resolution
  • We can distribute functionality to individual samplers and grouped them under transaction controller. Below is the result:
Machine generated alternative text:
LoginPage 
enantSeIectonPage 
Homepage 
I. Login 
Sample Tme (ms) 
10332 
Status


Difference in response time 
We have observed variance in response times due to the difference in the request simulation by JMeter with and without WebDriver Sampler. Following table represents the response time in secs for 5 transactions. We can observe response time is high in case of Jmeter when compared to Selenium Webdriver.

Transaction Response Time (sec)
               
Transaction
JMeter Selenium Webdriver
Jmeter
Count
Avg
Min
Max
Stdev
Count
Avg
Min
Max
Stdev
1.Login
10
6.5
5.51
10.41
1.4
10
1.89
1.46
2.21
0.25
2.NavigateToFileCabinet
10
1.35
1.17
1.56
0.11
10
0.62
0.49
0.72
0.09
3.NavigateToFolder
10
0.39
0.35
0.41
0.02
10
0.08
0.07
0.1
0.01
4.OpenDashboard
10
6.23
5.88
7.85
0.6
10
9.96
3.96
12.48
3.08
4.RunReport
10
3.2
2.92
4.15
0.45
10
3.88
3.35
4.53
0.46
5.Logout
10
0.82
0.68
1.03
0.1
10
0.22
0.16
0.26
0.03


This is due to following reasons:
a.       Way of handling Async requests by client
b.       Number of concurrent web server connections created by client
    1. Following table represents comparison of connection creations to WebServer from client for Login transaction.

Chrome
JMeter

c.       Handling the request queue by client. We can’t simulate the request queue of the browser from JMeter.

Resolution
    1. Pick max of response times for Async
Following is the response time comparison after picking max values
Transaction
JMeter Selenium Webdriver
Jmeter
Count
Avg
Min
Max
Stdev
Count
Avg
Min
Max
Stdev
1.Login
10
6.5
5.51
10.41
1.4
10
1.89
1.46
2.21
0.25
2.NavigateToFileCabinet
10
1.35
1.17
1.56
0.11
10
0.62
0.49
0.72
0.09
3.NavigateToFolder
10
0.39
0.35
0.41
0.02
10
0.08
0.07
0.1
0.01
4.OpenJarvisDashboard
10
6.23
5.88
7.85
0.6
10
4.14
2.47
5.24
0.88
4.RunDynamicReport
10
3.2
2.92
4.15
0.45
10
3.88
3.35
4.53
0.46
5.Logout
10
0.82
0.68
1.03
0.1
10
0.22
0.16
0.26
0.03
    1. We couldn’t find resolution for simulation  of browser request queue and browser concurrent connections.