How to ensure an application's performance | IT's time to talk #8

00:00 → 00:01

Hello, ladies and gentlemen.

00:01 → 00:04

In today's episode of It's Time to Talk,

00:04 → 00:07

we will be discussing matters related to performance.

00:07 → 00:11

How can we improve performance? How can we measure performance?

00:11 → 00:16

What kind of activities can we do in order to secure

00:16 → 00:20

and preserve good performance of both mobile and web applications.

00:20 → 00:23

And together with me is my special guest,

00:23 → 00:26

Paweł Ławiński. Hello, Paweł. How are you doing?

00:27 → 00:31

Hello. I'm fine. Thanks a lot. Good to see you, Mike.

00:35 → 00:39

Please tell me a few words about characteristics of the

00:39 → 00:42

projects that you've been working recently?

00:42 → 00:46

How your impact as a quality assurance tester

00:46 → 00:51

could improve the performance of the applications that you've been working on?

00:51 → 00:52

Sure.

00:52 → 00:54

So right now, I'm in a little bit

00:54 → 00:56

specific project.

00:56 → 01:01

So we are focusing on the front end Because

01:03 → 01:07

our client gave us his back end.

01:07 → 01:10

We have a lot of data which we need to

01:11 → 01:11

work on.

01:11 → 01:14

And so we create a lot of charts, lot of columns,

01:14 → 01:17

a lot of calculators.

01:17 → 01:18

And

01:18 → 01:21

so this is it.

01:21 → 01:22

Usually,

01:23 → 01:26

in my projects, the biggest effort was on the back end.

01:26 → 01:29

In here, it's a little bit different,

01:29 → 01:31

a really big

01:32 → 01:35

a really big impact, a really big

01:36 → 01:39

complexity is on the front end side.

01:40 → 01:42

It's unusual.

01:43 → 01:45

But a few months ago,

01:45 → 01:49

I was in the project which is

01:50 → 01:52

which is a classic project.

01:52 → 01:55

So a lot of logic were on the back end,

01:55 → 01:59

and I had possibility to perform

02:00 → 02:01

performance test.

02:01 → 02:02

Correct.

02:02 → 02:07

And that was a client from event industry.

02:07 → 02:11

So we needed to check if during those

02:11 → 02:16

events, everything will be fine because on those days,

02:16 → 02:21

on those events, traffic could be much bigger than, you know, usual.

02:21 → 02:24

I can tell you more details a little bit later,

02:24 → 02:28

but it was also really fascinating product.

02:28 → 02:29

Okay.

02:29 → 02:33

You mentioned that that the first projects that you're

02:33 → 02:36

currently working on is full of biases.

02:36 → 02:37

And

02:39 → 02:42

so is it related to data visualization?

02:43 → 02:44

Yes. Yes. Yes. Yes.

02:44 → 02:46

We have a lot of

02:46 → 02:51

different pages, charts, and elements which are

02:52 → 02:56

not so easy to create and test on the performant on

02:56 → 03:00

the the front end side.

03:01 → 03:04

And this is challenge for us, but,

03:04 → 03:08

actually, this project is in Merix from

03:09 → 03:11

three or even four years.

03:11 → 03:16

So I think that client is happy with our work.

03:16 → 03:17

Alright then. No.

03:17 → 03:21

I was asking about this because our audience perhaps may be

03:21 → 03:24

interested in our other episode when

03:24 → 03:26

we are typically tackling the issue

03:26 → 03:31

of designing beautiful dashboards analytical dashboards.

03:31 → 03:32

Okay then.

03:32 → 03:36

So let's talk a little bit about

03:36 → 03:38

gathering requirements when it

03:38 → 03:41

comes to performance.

03:41 → 03:43

How does this process look like?

03:43 → 03:47

What kind of metrics clients are outlining

03:47 → 03:53

when describing performance expected performance of their application?

03:54 → 03:54

Sure.

03:54 → 03:59

So I think that the best possible place or a person

03:59 → 04:03

Who can give us knowledge is a client. Okay.

04:03 → 04:07

And sometimes clients know their specific

04:07 → 04:09

requirements.

04:09 → 04:13

They know about the potential traffic in the future.

04:13 → 04:16

But, of course, it's not the only place.

04:16 → 04:20

Sometimes they are industries, like

04:23 → 04:28

when lives of people or animals

04:28 → 04:33

are in danger or are connected with

04:33 → 04:34

our app sometimes.

04:34 → 04:39

So we need to be sure that everything works there in

04:39 → 04:43

case of a little big bigger traffic because, you know,

04:43 → 04:47

some people can rely on on this

04:47 → 04:48

app simply.

04:48 → 04:49

Okay.

04:49 → 04:53

So for intense maybe, you know, this example,

04:53 → 04:54

there is an app.

04:54 → 04:56

When you are in Polish mountains,

04:56 → 05:01

you can call for emergency specifically from the app.

05:01 → 05:03

You don't need to know any other details.

05:03 → 05:07

So we need to be sure that in case of a

05:07 → 05:11

long weekend in Poland, there can be many

05:11 → 05:14

situation when people call for for help.

05:14 → 05:19

We need to be sure that everything's work fine during that time.

05:19 → 05:22

But let's imagine that we have

05:22 → 05:24

ecommerce product.

05:26 → 05:30

You have shop with, I don't know,

05:32 → 05:36

And there are some days like Black Friday or Cyber

05:36 → 05:37

Monday.

05:37 → 05:41

And on ninety nine percent during

05:41 → 05:45

that time, the traffic would be higher than on

05:45 → 05:47

any any other week and

05:47 → 05:51

or any other day during here.

05:51 → 05:54

So we can talk with our client.

05:54 → 05:58

We can check other other ecommerce products and

05:58 → 06:02

be prepared for really

06:02 → 06:07

high traffic or even sometimes we can test

06:08 → 06:12

traffic bigger than expected to to check what will

06:12 → 06:14

happen with our product.

06:15 → 06:17

Alright then.

06:17 → 06:20

It's a good thing that you mentioned the mountaineering

06:20 → 06:25

application because I'm personally I like to

06:25 → 06:27

walk around Polish mountains, me and my wife,

06:27 → 06:31

and I know that this solution saved a

06:31 → 06:35

lot of lives and helped intervene in a lot of

06:35 → 06:40

situations because the tourism movement in Poland

06:40 → 06:43

is quite strong around the mountaining site.

06:43 → 06:44

Okay then.

06:44 → 06:47

So what is the good moment to actually start working on the

06:47 → 06:49

performance of the application?

06:51 → 06:54

So like many other situation,

06:54 → 06:58

probably the best moment is from the very beginning.

06:58 → 06:59

But

07:00 → 07:04

maybe not even testing and and working on the performance

07:05 → 07:09

in a way that we can imagine so many

07:09 → 07:11

thousands of users.

07:11 → 07:14

But probably during gathering requirements,

07:14 → 07:17

if we know some details from the client

07:18 → 07:23

that, for instance, he or she expects

07:23 → 07:26

thousands of people from the the refuse day,

07:26 → 07:28

It can affect

07:29 → 07:32

back end and the DevOps work.

07:32 → 07:36

So the whole architecture, the whole

07:37 → 07:40

idea of some endpoints of some

07:40 → 07:42

functionalities

07:43 → 07:46

because, you know, usually, we can

07:47 → 07:52

create something very simple, working,

07:52 → 07:55

but probably not prepared for

07:56 → 07:59

hundreds or thousands of people.

07:59 → 08:04

When we will know it from the very beginning, our

08:05 → 08:07

our thinking can be different,

08:07 → 08:10

our awareness can be different,

08:11 → 08:15

and it will be very useful to to know those things.

08:16 → 08:18

When we are thinking about testing,

08:20 → 08:24

probably a good moment is when the whole functionality

08:24 → 08:29

is ready or a few functionalities are ready

08:29 → 08:34

to to test whole user user

08:34 → 08:38

journey, to know how it will

08:38 → 08:41

behave under high traffic.

08:41 → 08:42

Alright.

08:42 → 08:44

So simply

08:45 → 08:50

sometimes, I notice that in project or

08:52 → 08:56

discussion with the client starts at the end

08:56 → 08:58

of the project about performance.

08:58 → 09:01

Alright? So how our performance looks like.

09:01 → 09:06

In my opinion, it's a little bit light and can be pretty

09:07 → 09:08

expensive.

09:09 → 09:15

In that case, sooner probably means better.

09:16 → 09:17

Alright.

09:17 → 09:22

And so to summarize, because I think this is

09:22 → 09:24

a very important thought,

09:25 → 09:29

Many people believe in this misconception where

09:30 → 09:34

they think that the app can be built and the

09:34 → 09:36

performance can be measured or improved.

09:36 → 09:39

I mean, it can be improved at further stages. Yeah.

09:39 → 09:42

But it's much, much easier to secure good performance of the

09:42 → 09:47

application if the application is from the beginning

09:47 → 09:51

built following some good practices and principles.

09:51 → 09:51

Yes?

09:51 → 09:54

So this is why it's so important to get to know what

09:54 → 09:59

kind of performance we may need to expect in the beginning of the project.

09:59 → 09:59

Yeah.

09:59 → 10:02

Because it helps us to limit the budget.

10:02 → 10:07

It helps us to spend less time on the product and so on and so on.

10:07 → 10:08

Okay. Exactly.

10:08 → 10:12

Probably, we can spend some extra time on some endpoint,

10:12 → 10:16

which in normal case, we will just leave because because

10:16 → 10:17

everything is fine.

10:17 → 10:20

But we will be super focused on

10:20 → 10:24

query to database that it will be

10:25 → 10:29

as fast as possible because in situation of

10:29 → 10:33

thousands of people, it can have some impact.

10:33 → 10:36

In case of normal traffic, probably,

10:36 → 10:39

it would be good enough to to stop

10:40 → 10:41

earlier.

10:42 → 10:44

Sure. Alright. Thank you.

10:44 → 10:48

So, Pavel, what is the toolbox of a

10:48 → 10:51

modern quality assurance tester?

10:51 → 10:53

What kind of tools,

10:54 → 10:59

solutions, services do you use to come up with an efficient work?

11:01 → 11:01

Sure.

11:01 → 11:02

So

11:03 → 11:04

at the very back beginning,

11:04 → 11:08

we can we can think about

11:08 → 11:10

Chrome DevTools and Postman.

11:10 → 11:15

Those are really those are basics and probably

11:15 → 11:19

testers use it not only for performance testing,

11:19 → 11:25

but to simply test API or test some features.

11:25 → 11:29

But this is really good basic to

11:29 → 11:33

to check single endpoints to

11:33 → 11:38

check how long it takes to give us a response.

11:39 → 11:42

But probably more

11:47 → 11:50

tools which are more connected with a performance

11:50 → 11:52

are k

11:52 → 11:55

six, locus, or j meter.

11:55 → 11:59

And those tools give us possibility to

12:00 → 12:04

test this high traffic, those thousands of people to

12:04 → 12:09

actually handle a situation when so many people

12:09 → 12:11

are using it.

12:11 → 12:16

We can add their additional checks and

12:16 → 12:20

additional we can expect additional things

12:20 → 12:21

during those tests.

12:21 → 12:25

So sometimes we don't need to

12:28 → 12:30

spend a lot of time

12:33 → 12:37

during checking reports after those tests.

12:37 → 12:40

Because if we create those tests properly,

12:40 → 12:44

we will know everything after those tests ends

12:44 → 12:46

because we have those checks with that.

12:46 → 12:48

We have those

12:49 → 12:50

expectation.

12:51 → 12:54

There are two more types

12:54 → 12:57

of tools which I should mention.

12:57 → 13:01

So this is monitoring tools.

13:01 → 13:01

Okay.

13:01 → 13:03

For instance,

13:03 → 13:05

it's Grafana.

13:05 → 13:07

This is a kind of tool.

13:07 → 13:11

So we simply monitor some

13:11 → 13:13

important metrics,

13:14 → 13:19

like CPU usage or memory consumption.

13:20 → 13:24

We know which endpoints or which places in

13:24 → 13:28

our app use a lot of those memories.

13:28 → 13:34

And also, sometimes, when clients have

13:34 → 13:36

already production

13:38 → 13:42

set up and people are there, during high traffic,

13:42 → 13:46

we also get some information about some

13:46 → 13:51

problems or some places we should focus on.

13:52 → 13:56

And one last but not least is

13:56 → 13:58

CICD integration tools.

13:58 → 13:59

Alright.

13:59 → 14:02

So for instance, we are working with a GitLab

14:02 → 14:04

c CI.

14:04 → 14:06

So

14:06 → 14:12

QA testers usually integrate those performance tests

14:13 → 14:17

in in in that kind of tool to be sure that

14:18 → 14:20

after some changes in the code,

14:20 → 14:24

the performance is still on a high level.

14:25 → 14:27

Alright then. Thank you very much.

14:27 → 14:31

I met an opinion that modern testers are actually

14:31 → 14:34

sentenced to k six

14:35 → 14:36

or Locust.

14:36 → 14:40

Can you explain why or maybe not?

14:40 → 14:41

Alright.

14:41 → 14:42

So

14:43 → 14:46

I think that's yes. They are sentenced.

14:46 → 14:51

But from some level of testing.

14:51 → 14:52

Because at the very beginning,

14:52 → 14:57

when we know that we should be aware about performance,

14:57 → 15:02

we can check some things with post on on Chrome DevTools,

15:02 → 15:05

and we can

15:05 → 15:09

alarm people from our project or a

15:09 → 15:12

client that something is wrong.

15:12 → 15:15

But when we want to perform

15:16 → 15:20

those tests, like, tens of users,

15:20 → 15:25

hundreds of users, thousands of users, probably,

15:25 → 15:29

the there there is no better there there is no better

15:29 → 15:32

possibility or opportunity than those tools,

15:32 → 15:34

so k six or Locust,

15:34 → 15:38

and simply check if we have some bottlenecks with those tools.

15:38 → 15:42

Can you recall any problem with performance in the project and

15:42 → 15:46

actions that team had to introduce

15:46 → 15:50

to improve the performance of the application?

15:50 → 15:54

Sure. I I remember the great example.

15:54 → 15:56

So

15:57 → 16:01

on this call, I mentioned this ecommerce product product project.

16:01 → 16:01

Yes?

16:01 → 16:07

So we had a product

16:07 → 16:10

which give you a possibility to

16:10 → 16:11

sell some things.

16:11 → 16:16

So let's imagine, Mike, that you have a cup

16:16 → 16:19

and you want to sell it to to other people.

16:19 → 16:22

And you add some details like

16:23 → 16:25

description, price,

16:27 → 16:32

some other details which you want to share with people.

16:32 → 16:37

But also, you can add, for instance, shared.

16:37 → 16:37

Alright.

16:37 → 16:39

And in case of shirt,

16:39 → 16:42

it's a little bit different case because you can have

16:42 → 16:47

five sizes of this shirt and five colors.

16:48 → 16:53

So during setup, during creating this product,

16:53 → 16:56

you already create twenty five

16:56 → 16:58

possibilities

16:58 → 17:03

or possible products because every size can

17:03 → 17:04

have every color.

17:04 → 17:05

Right?

17:05 → 17:09

And because of that, the database,

17:09 → 17:14

we needed to create twenty five products, not one.

17:14 → 17:18

And, actually, we find out

17:19 → 17:22

it was actually a bit

17:23 → 17:26

a little bit late because almost before

17:26 → 17:32

the the release to production that this feature

17:33 → 17:36

is really complicated and

17:36 → 17:40

maybe not the best from the performance perspective.

17:40 → 17:44

And if you want to to create that kind of

17:44 → 17:47

product, so a lot of

17:48 → 17:51

different possibilities, a lot of different

17:52 → 17:54

color, sizes, factors.

17:54 → 17:55

This

17:58 → 18:03

this creation could be really slow.

18:03 → 18:09

And in case of in case of that situation,

18:10 → 18:14

the response from the server could be so long that you

18:14 → 18:17

even could see time out.

18:17 → 18:17

So

18:18 → 18:20

The response is too long,

18:20 → 18:23

and we server can't respond

18:23 → 18:27

to you to your request.

18:27 → 18:29

And we needed some time

18:30 → 18:32

to to improve that.

18:33 → 18:39

It occurs that the problem was in the crow the query to database.

18:39 → 18:39

Alright.

18:39 → 18:41

We needed to set up

18:42 → 18:46

a staging a little bit earlier that we

18:46 → 18:51

wanted because maybe you know or maybe you're not you don't

18:51 → 18:54

know that usually staging

18:55 → 19:00

has very similar settings like production.

19:00 → 19:05

I mean, the resources which we can use.

19:05 → 19:07

Our

19:07 → 19:11

our development environments usually has those

19:11 → 19:16

two those resources really small because of money.

19:16 → 19:18

You know, resources are money.

19:18 → 19:22

So we needed to set up staging earlier

19:22 → 19:27

to actually test this feature properly and be sure that

19:27 → 19:29

everything works there great.

19:31 → 19:33

Alright then. Thank you very much.

19:33 → 19:38

So speaking about resources, what kind of resources

19:38 → 19:41

are needed to secure good performance?

19:43 → 19:44

Alright.

19:44 → 19:49

So for sure, people, and It's not only

19:49 → 19:54

QA specialist who is familiar with

19:54 → 19:58

performance testing, but also back end developer.

19:58 → 20:00

And

20:01 → 20:04

a person from DevOps team.

20:04 → 20:04

Okay.

20:04 → 20:06

And at the very beginning,

20:06 → 20:08

this DevOps

20:09 → 20:12

person, this DevOps specialist

20:13 → 20:18

to set up our environment to

20:18 → 20:21

to give possibility to scale

20:21 → 20:24

To scale up because

20:26 → 20:29

even if a back end developer work,

20:29 → 20:31

I don't know, ten years on some feature,

20:31 → 20:35

it will be hard to handle thousands of

20:35 → 20:37

users at one time.

20:37 → 20:42

We need to give some additional resources.

20:42 → 20:42

Okay.

20:42 → 20:46

But like like we mentioned just

20:47 → 20:51

few minutes ago, resources resources are

20:51 → 20:55

really expensive or can be expensive.

20:55 → 21:00

So we want to have those resources on a high level

21:00 → 21:03

only in case of high traffic.

21:03 → 21:08

So DevOps specialist need to

21:09 → 21:13

set up environment in a way that only in case

21:13 → 21:15

of high traffic, we add resources.

21:15 → 21:21

We add some memory or CPU

21:21 → 21:22

resources.

21:22 → 21:25

And we thanks to that,

21:25 → 21:28

we will be sure that our client won't

21:28 → 21:32

pay too much, but we are sure

21:32 → 21:36

that this high traffic will be

21:37 → 21:39

will be handled.

21:39 → 21:43

Also, back end developer because

21:44 → 21:46

when we find out something,

21:46 → 21:49

we will need to discuss it with,

21:49 → 21:53

with back end developer to be sure,

21:54 → 21:56

to know,

21:56 → 21:59

actually what needs to be improved,

22:00 → 22:04

which places which endpoints in one case.

22:04 → 22:09

So we need to be in touch with back end developer all the time.

22:09 → 22:12

And also,

22:12 → 22:14

during performance tests,

22:14 → 22:19

client knowledge and client person would

22:19 → 22:23

be really useful

22:23 → 22:26

because we can share

22:28 → 22:32

share with results with with the client and

22:32 → 22:36

decide what to do, what also should be checked

22:36 → 22:39

if this

22:40 → 22:41

these results are satisfying.

22:41 → 22:46

So that team that small team in our project team will

22:46 → 22:49

be really useful to to secure good performance.

22:49 → 22:49

Okay then.

22:49 → 22:51

Ladies and gentlemen,

22:52 → 22:55

securing good performance of the applications is not just a

22:55 → 22:58

matter or it's not just a subject of interest of

22:58 → 23:00

quality assurance testers.

23:00 → 23:04

It actually is dependable on activities

23:04 → 23:07

done by entire team.

23:07 → 23:10

Therefore, the team has to be skilled,

23:10 → 23:14

competent, but also well coordinated.

23:14 → 23:16

There needs to be a good communication between testers,

23:16 → 23:20

developers, project management, other stakeholders,

23:20 → 23:24

and members who are involved in the process.

23:24 → 23:27

If you would like to learn more about the way how to

23:27 → 23:29

secure good performance,

23:29 → 23:31

how to improve performance of existing app,

23:31 → 23:34

or how to build from scratch an app,

23:34 → 23:37

both mobile or web or some other app,

23:39 → 23:42

If you would like to learn how to improve the performance of

23:42 → 23:44

such app or make it good from the beginning,

23:44 → 23:46

feel free to reach out to us.

23:46 → 23:47

We are all yours.

23:47 → 23:50

Thank you very much for watching today's episode.

23:50 → 23:53

This was it's time to talk from Merixstudio. Thank you.

23:53 → 23:54

Have a great day.

23:54 → 23:56

Thank you very much. Bye.