DEV Community: Keith Darragh

Performance testing

Keith Darragh — Sun, 09 Aug 2020 22:22:42 +0000

I've recently been tasked with performance testing an application, here are things to consider for anyone starting to do this or if you've just started a new project.

Be realistic:

Be realistic with the number of requests you expect to hit your application. It may be useful to think of these in terms of user actions. Example is login, where the action will be create a new user. Try to get a hold on how many requests per second you expect your application to handle and the total requests during a specific period. These numbers will help decide how to run your test.

Loadtest tool

Think carefully about the tool to use. It's important to get a tool that simulates how actions would occur in real life. A tool like locust is designed to randomise requests, which is great for testing how randomised requests affect performance. If however you need to identify a specific issue, you may want to specify numbers. This can also be useful to produce an entirely repeatable test.

Short feedback

Short feedback is important, try to run some shorter tests first to check the accuracy of your load test and build up to longer running tests. This should help identify errors in your test code.

Constants

Be clear on what stays constant and what should vary. You may want to vary the instance size, number of instances or even db size. This will help identify how best to deploy your application.

Loadtest early

Start load testing early during development and continually run these tests to ensure performance doesn't degrade. Running this often will help identify what causes any performance degradation. It will help identify bottlenecks sooner so that they can be fixed before they become an issue. Having your loadtest in a specific build pipeline may help satisfy this requirement. It may not need to run on every commit but weekly should be a minimum consideration.

Environment

Create an environment identical to production to run your tests, this will allow for more accurate results than running against an existing test stack. Running load tests against production may not be a good idea, if your application reaches breaking point, you don't want users being unable to use your system.

Cost

Think about the cost involved, a whole new environment can be expensive. Think about the tool being used, there are plenty of free tools out there which may do the job but some paid for tools may offer more features. Check out what tool best suits your needs. Think too about the cost of developer time, how many are working on this, can it be automated to save on cost?

A git intro

Keith Darragh — Sun, 09 Aug 2020 21:41:23 +0000

Git allows for central storage of code so that it can be easily distributed and managed throughout a team. The central storage of code is called a repository. We talk of two types of repositories:

Remote: This is code that can be accessed by all developers. Stored in services such as github, gitlab etc
Local: This is the code present on your local machine

Who wants to access your code:

Developers
Testers
Dev ops
Bots ( for build processes)

Git provides each member with access to the codebase. Each member can get access to the code by cloning the repository. Cloning takes a copy of the code from a remote repository and places it on your local machine.

Clone a repository:

git clone <project-path>

Now we can work on the codebase but what if two people are working on the same file, how do we avoid conflicts?

This is partly solved by branches, when we develop a feature we take a branch from master. Write our code before pushing and asking for a pull request. Once reviewed we merge back to master.

How this looks in Git commands

First create a new branch:

git checkout -b <new-branch-name>

Once you’ve made your changes, select the files you’d like to add:

git add <file1> <file2> ...

Now let’s check the staging area. This will give a summary of what files we would like to add:

git status

Staging area: the staging area checks for differences in the last commit of the current branch and the code you’re currently working with. This allows you to be selective in what changes you are committing to your branch. It shows files which have been selected to commit. Generally this is how we select what code should be reviewed.

To place the added files as the next commit:

git commit -m ‘a descriptive message’

Note: it’s important that the commit message is succinct but descriptive so other developers can tell what the commit is for.

Now let’s push our branch to origin so that it can be reviewed.

git push origin <branch-name>

We open a pull request at this point, which is usually done through the UI of your chosen git repository. We add a reviewer and once they have approved we can merge our branch back into master.

To do this we checkout master:

git checkout master

Then merge our branch into master

git merge <branch-name>

This merge adds to the history of our master branch. Branch history is made up of a series of commits, each added in order. We can view our commit history by looking at the git log:

git log

commit 60b0abf5f61bc4ab3b4fd8734df0184b3cc11bc7
Author: John Smith <john.smith@company.com>
Date:   Fri Jul 17 07:50:33 2020 +0100

    Adding landing page

commit 9e45460f4b5c4caeba59adb2343125ca1d63169e
Author: John Smith <john.smith@company.com>
Date:   Thu Jul 16 22:14:30 2020 +0000

  Adding a readme

commit 775bcb0e43b9efae8b5318f72697d45e60c56d7
Author: John Smith <john.smith@company.com>
Date:   Thu Jul 16 23:06:57 2020 +0100

  Initial project start

What happens if we want to change something about a branches past? Maybe reword a commit message? This can be done by rebasing. Rebasing allows the altering of git history.

When rebasing we need the commit hash of a commit before we want to edit. To get this we can can look at the git log, then we can run the rebase command.

git rebase -I <commit hash>

This enters an interactive command prompt where we can select actions. We will cover a sample of these

reword - allows you to reword a specific commit message
squash - allows you to merge commits together, creating one new commit which will rewrite the branch history.
pick - selected by default in interactive mode. It will use this commit.

With the commit messages and hashes we select an action on each commit and close the file. The rebase command will process the actions and complete.

Now if we do a git log we can see the new branch history. For example if we reworded our last commit to as we forgot it included an about page:

commit 60eba59af611d631fd8733125ca84b3cc11bc75ca
Author: John Smith <john.smith@company.com>
Date:   Fri Jul 17 07:50:33 2020 +0100

    Adding landing and about pages

commit 9e45460f4b5c4caeba59adb2343125ca1d63169e
Author: John Smith <john.smith@company.com>
Date:   Thu Jul 16 22:14:30 2020 +0000

  Adding a readme

commit 775bcb0e43b9efae8b5318f72697d45e60c56d7
Author: John Smith <john.smith@company.com>
Date:   Thu Jul 16 23:06:57 2020 +0100

  Initial project start

There are many more git commands to go through but these are the most common ones I've used so far.

Git process

Keith Darragh — Thu, 06 Feb 2020 12:35:22 +0000

We have had a debate on our git process, how we branch and release into production.

My preference is to continuously commit and release from master by tagging each release. Features can be branched from this and pushed for code review before merge. Generally I like to continuously deploy and have features which are not yet available behind configuration.

The team I'm in prefers a different approach which I find messy. They would rather have a development branch along with the master branch. To build a feature you branch from development, and merge back to development. On release in development will get merged into master. I think this is harder to maintain and allows issues to arise if master gets ahead of development due to a bug fix.

What is your preferred git process?