Upload
dilip-sharma
View
50
Download
2
Embed Size (px)
Citation preview
Some Essentials of Performance Testing Type of Performance Testing Main parameter to focusLoad Testing
Load Testing help us to study the behavior of the application under various loads. The main parameter to focus is response time. This study reveals how the application handles concurrent users effectively.
Response Time
Stress TestingStress Testing help us to observe the stability of the application. The main intention is to identify the breaking point of the server. The main parameter to focus is throughput (how much data is being transferred between client and server)
Response Time and Throughput
Endurance TestingEndurance testing reveals about memory utilization when you load your test for prolong executions. Say if you execute your test 1 hour to perform load testing. But in endurance testing, you execute your test at least for 8 hours with significant load.
Memory Leakage
Spike TestingSpike Testing is performed by sudden increase/decrease in load and observing the behavior of the application. This help us to determine whether the application can handle or not under significant changes in the load.
Response Time
Volume TestingVolume Testing is performance to identify whether the server can handle more number of high complex queries under significant load. To observe how the database acts under various circumstances.
Response Time of Queries
Availability TestingThis test ensures whether the application is available 24x7x365 days. If you would’ve noticed any website hosting providers, they advertise as 99.9 per cent up time. Availability testing helps us to determine whether the application is up and running fine without any issues.
Response Time
Scalability TestingSay, your website has 1000 visitors per month with 10% increase in unique visitors. By forecasting the number of visitors by expected business growth and performing the load test is called scalability testing.
Response Time and Maximum Transactions Per Second
Some interesting Q&A for Performance Testing
Question :- What's the difference between load and stress testing?
One of the most common, but unfortunate misuses of terminology is treating "load testing" and "stress testing" as synonymous. The consequence of this ignorant semantic error is usually that the system is neither properly "load tested" nor meaningful stress test.STRESS TESTINGStress Testing consider unreasonable load while denying it the resources (e.g., RAM, disc, mips, interrupts, etc.) needed to process that load. The idea behind stress a system to the breaking point in order to find bugs that will make that break potentially harmful. The system is not expected to process the overload without adequate resources, but to behave (e.g., fail) in a decent manner (e.g., not corrupting or losing data). The load (incoming transaction stream) in stress testing is often deliberately distorted so as to force the system into resource depletion.
Dilip K Sharma Post your queries @:- [email protected]
LOAD TESTINGLoad testing is subjecting a system to a statistically representative (usually) load. The two main reasons for using such loads is in support of software reliability testing and in performance testing. The term "load testing" by itself is too vague and imprecise to warrant use. For example, do you mean representative load," "overload," "high load," etc. In performance testing, load is varied from a minimum (zero) to the maximum level the system can sustain without running out of resources or having, transactions suffer (application-specific) excessive delay.
Question :- Hide out of Application Bottlenecks Database:
Working size exceeds available RAM Long & short running queries Write-write conflicts Large joins taking up memory
Virtualization: Sharing a HDD, disk seek death Network I/O fluctuations in the cloud
Programming: Threads: deadlocks, heavyweight as compared to events, debugging, non-
linear scalability, etc... Event driven programming: callback complexity, how-to-store-state-in-
function-calls, etc... Lack of profiling, lack of tracing, lack of logging One piece can't scale, SPOF, non horizontally scalable, etc... Stateful apps Bad design : The developers create an app which runs fine on their
computer. The app goes into production, and runs fine, with a couple of users. Months/Years later, the application can't run with thousands of users and needs to be totally re-architectured and rewritten.
Algorithm complexity Dependent services like DNS lookups and whatever else you may block on. Stack space
Disk: Local disk access Random disk I/O -> disk seeks Disk fragmentation
Dilip K Sharma Post your queries @:- [email protected]
SSDs performance drop once data written is greater than SSD size OS:
Fsync flushing, linux buffer cache filling up TCP buffers too small File descriptor limits Power budget
Caching: Not using memcached (database pummeling) In HTTP: headers, etags, not gzipping, etc.. Not utilizing the browser's cache enough Byte code caches (e.g. PHP) L1/L2 caches. This is a huge bottleneck. Keep important hot/data in L1/L2.
This spans so much: snappy for network I/O, column DBs run algorithms directly on compressed data, etc. Then there are techniques to not destroy your TLB. The most important idea is to have a firm grasp on computer architecture in terms of CPUs multi-core, L1/L2, shared L3, NUMA RAM, data transfer bandwidth/latency from DRAM to chip, DRAM caches DiskPages, DirtyPages, TCP packets travel thru CPU<->DRAM<->NIC.
CPU: CPU overload Context switches -> too many threads on a core, bad luck w/ the linux
scheduler, too many system calls, etc... IO waits -> all CPUs wait at the same speed CPU Caches: Caching data is a fine grained process (In Java think volatile for
instance), in order to find the right balance between having multiple instances with different values for data and heavy synchronization to keep the cached data consistent.
Backplane throughput Network:
NIC maxed out, IRQ saturation, soft interrupts taking up 100% CPU DNS lookups Dropped packets Unexpected routes with in the network Network disk access
Dilip K Sharma Post your queries @:- [email protected]
Shared SANs Server failure -> no answer anymore from the server
Process: Testing time Development time Team size Budget Code debt
Memory: Out of memory -> kills process, go into swap & grind to a halt Out of memory causing Disk Thrashing (related to swap) Memory library overhead Memory fragmentation
In Java requires GC pauses
Dilip K Sharma Post your queries @:- [email protected]