Perftiquette #4

Now for the long awaited episode 4 of hashtag#perftiquette
It was requested by both my followers so it seems important

Running performance tests you’ve probably stumbled upon the terms Concurrency and Parallelism (yes, it’s not the same). As well as challenges affiliated with them.

One of the problems that may occur during highly paralleled workload is a race condition. It’s a common problem where two processes (or threads) try to modify or access the same variable at the same time. The problem is, your CPU can only access the same address once at a time so you may be in for a surprise when you fetch the value of the variable and it’s not the same you expected it to be, because other thread just overriden your variable. Your process is completely unaware of that tries to process the given value with its predefined instructions.

Functions and classes protected from concurrent overrides are commonly referred to as thread safe and variables as atomic types. They are protected by a Mutex (Mutual Exclusion block) or Lock if you use Java, that guarantees access to a specific block of code to a single thread at a time, protecting the code to access same variable “twice”. It’s important to note that even programming languages constrained to a single physical thread or CPU are subject to race conditions – especially during asynchronous updates and virtual thread dispatching.
So now that we know that concurrency may produce data inaccuracies – how do we test that?
While it’s a defect of functional nature, it’s most likely to manifest itself at high load, which the functional tests are usually not designed for and your only chance to assert for that is… a load test.
But what’s the possible impact of such a bug?
From single transaction errors, through messing up the data integrity of your application, up to taking it down completely.

I once wrote a web application, which had this nice little detail of welcoming you on a web page : Hello, {your_name}. This seemed easy enough to cache so I did…. and then everyone opening this application saw other people’s names on the top of the app. If this wasn’t an app written solely for test purposes, this would have been a GDPR incident and they tend to be pretty… costly. That’s just minor example but trust me, I’ve seen way worse.

So, like in all the testing activities – details matter. If you’re afraid that assertions “kill” your generators, write more efficient assertions, get better hardware. Your job is to show the risks and let the management decide what to do with them – if you sweep problems like that under the rug, make sure your stakeholders are aware of that.

So here are things to looks out for:
– Was the message successful?
– Was it addressed to me?
– Does it have a proper size (approximation is fine)
– Does it deserialize?
– Does it have all the elements given my inputs and test data?


hashtag#performanceengineering hashtag#performancetesting hashtag#assertions hashtag#perftiquette