Alden Jenkins

Omnipotent Service Level Indicators

2019-02-11T00:00:00-05:00

Your SLOs (Service Level Objectives) are what keep making your company money, and what keep you honest as a deployer of your application. At it’s core, an SLO is simply an objective of a specific attribute of your service such as availability, throughput, response time, etc.

Without ensuring that the SLOs you are creating are met as time progresses, you’ll run into angry customers, tarnishing the relationship that you had with them up to that point. At the same time, you will facilitate underconfident employees who will feel that the loss of your customer due to an error in service was either their personal fault, or that your mistakes as their leader are now compromising their job security by creating potential revenue uncertainty for the company. The solution to ensuring that your SLOs are met is simply an investment of time in optimizing your SLIs (Service Level Indicators).

Within the deployment of metoo.io, we use creative SLIs to give us reliable metrics throughout our deployment environments. We capture ALL of the telemetry between our microservices and scrape the metrics with Prometheus so that we can graph the data using Grafana, and perform other queries on the data when required. Grafana is awesome because it allows us to create multiple dashboards for simultaneous viewing which Prometheus does not support out of the box.

Beyond Grafana, we run AlertManager with custom rules for alerting us when our SLOs are not being met. Our SLO for uptime is a 4 nine SLO (99.99% uptime,) and use AlertManager to tell us when our past 10 minute SLO has not been met. We run a Prometheus query for each environment to check whether !(200 <= response status codes < 404) start to occur for more than 0.01% of responses, and other queries regarding communication between services. But how are we able to collect so much telemetry in the first place?

Enter Istio! This Service Mesh for Kubernetes allows us to:

Secure communication between pods using mTLS (beneficial for cross-cloud deployments)
Automatically collect Telemetry between pods,
Give every pod an L7 reverse proxy SideCar container (Envoy Proxy,) which reads from the Istio Global Virtual Service rules and Routing rules to give us the ability to:
- Route a dynamically specified amount of trafic to our staging environment,
- Route arbitrary device types to an environment of our choice as recorded by the L7 reverse proxy.

Since these specifications are all specified in deployment yaml files, it becomes easy to listen to a webhook sent by AlertManager regarding a 500 (or other status code) response coming from your Canary Environment and then automatically apply a

sed 's/weight: 10/weight: 0/' routing-canary.yaml && kubectl apply -f routing-canary.
yaml

change, making your SLIs literally a self-healing omnipotent force in your DevOps arsenal!!!!! >:D

Omnipotent Service Level Indicators was originally published by Alden Jenkins at Alden Jenkins on February 11, 2019.

Deploying GeoDjango in an Alpine Linux Docker Container

2019-01-19T00:00:00-05:00

In deploying metoo.io with Kubernetes, I wanted to reduce the time from launching a new deployment until the deployment was live as short as possible. In the beginning, metoo was containerized using the typical uncomplicated method of using an Ubuntu Docker image like most other GeoDjango builds. While the image worked fine, the image size was ~600MB. But why is this size an issue?

Smaller containers simply download and deploy faster than larger ones. While we already use Google Compute Engine for our remote servers, we found it easy to decide that we would store our Docker images in GCR instead of Dockerhub. This was because GCR allows for free storage and transfer to nodes within Google’s data centers. Additionally, polling GCR for container downloads on GKE servers hosted inside those same data centers inherently makes container download much faster.

While Ubuntu is not necessarily the most bloated operating system you could run inside Docker container, there is definitely room for improvement. Under further investigation, Alpine Linux was the most minimal while being (almost) fully-compatible-with-GeoDjango operating systems you could choose from. Compared with Ubuntu’s size of 600MB, Alpine sported a size of just ~200MB. We saw improvements of deployment times of just over 1 minute with Ubuntu images down to just about 10 seconds using Alpine.

Considerations

There are a few considerations you want to make in deciding whether or not to switch to alpine or not.

Be prepared to have a test suite to run after deploying.
- Understand that since you are likely not developing on the same Alpine Linux Environment, that you’re deploying on, there may be dependency issues that do not arise until you run the container and check literally everything that can be checked with your deployment. This is both a good thing and a bad thing because it will keep you honest about testing all of your code but will also really slap you in the face if you accidentally forget to test something which breaks. For example, we had a very outlandish error arise when we were using a specific GeoDjango admin module which would crash the server on our Alpine build when viewing an admin page that rendered a point on a map which didn’t occur on my Arch development environment.
If you are hosting an open source application that you want to be easily accessible to others, recognize that Alpine is much harder for the laymen programmer to work with.
Dependency Issues arise frequently and out of nowhere
- Anticipate for the worst case that you are going to run into a build issue at least once every 6 months at the cost of the smaller image size.

Alpine with GeoDjango

No released version of Alpine came with either the GEOS or GDAL libraries available for installation, and only the experimental edge version of alpine to this day has the packages downloadable. To solve for this, I build the python:alpine docker image from scratch within my Dockerfile then added the required build dependencies manually in a separate run layer.

Feel free to use the code for your GeoDjango Deployments and spread the love! :D

FROM alpine:3.8
# This^ sets the remote package index inside /etc/apk/repositories which we will manually override later to use the edge index.
 
# ensure local python is preferred over distribution python
ENV PATH /usr/local/bin:$PATH

# http://bugs.python.org/issue19846
# > At the moment, setting "LANG=C" on a Linux system *fundamentally breaks Python 3*, and that's not OK.
ENV LANG C.UTF-8

# install ca-certificates so that HTTPS works consistently
# the other runtime dependencies for Python are installed later
RUN apk add --no-cache ca-certificates

ENV GPG_KEY C01E1CAD5EA2C4F0B8E3571504C367C218ADD4FF
ENV PYTHON_VERSION 2.7.14

RUN set -ex \
   	&& apk add --no-cache --virtual .fetch-deps \
		gnupg \
		openssl \
		tar \
		xz \
	\
	&& wget -O python.tar.xz "https://www.python.org/ftp/python/${PYTHON_VERSION%%[a-z]*}/Python-$PYTHON_VERSION.tar.xz" \
	&& wget -O python.tar.xz.asc "https://www.python.org/ftp/python/${PYTHON_VERSION%%[a-z]*}/Python-$PYTHON_VERSION.tar.xz.asc" \
	&& export GNUPGHOME="$(mktemp -d)" \
	&& gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$GPG_KEY" \
	&& gpg --batch --verify python.tar.xz.asc python.tar.xz \
	&& rm -rf "$GNUPGHOME" python.tar.xz.asc \
	&& mkdir -p /usr/src/python \
	&& tar -xJC /usr/src/python --strip-components=1 -f python.tar.xz \
	&& rm python.tar.xz \
	\
	&& apk add --no-cache --virtual .build-deps  \
		bzip2-dev \
		coreutils \
		dpkg-dev dpkg \
		gcc \
		gdbm-dev \
		libc-dev \
		linux-headers \
		make \
		ncurses-dev \
		openssl \
		openssl-dev \
		pax-utils \
		readline-dev \
		sqlite-dev \
		tcl-dev \
		tk \
		tk-dev \
		zlib-dev \
# add build deps before removing fetch deps in case there's overlap
	&& apk del .fetch-deps \
	\
	&& cd /usr/src/python \
	&& gnuArch="$(dpkg-architecture --query DEB_BUILD_GNU_TYPE)" \
	&& ./configure \
		--build="$gnuArch" \
		--enable-shared \
		--enable-unicode=ucs4 \
	&& make -j "$(nproc)" \
# set thread stack size to 1MB so we don't segfault before we hit sys.getrecursionlimit()
# https://github.com/alpinelinux/aports/commit/2026e1259422d4e0cf92391ca2d3844356c649d0
		EXTRA_CFLAGS="-DTHREAD_STACK_SIZE=0x100000" \
	&& make install \
	\
	&& runDeps="$( \
		scanelf --needed --nobanner --format '%n#p' --recursive /usr/local \
			| tr ',' '\n' \
			| sort -u \
			| awk 'system("[ -e /usr/local/lib/" $1 " ]") == 0 { next } { print "so:" $1 }' \
	)" \
	&& apk add --virtual .python-rundeps $runDeps \
	&& apk del .build-deps \
	\
	&& find /usr/local -depth \
		\( \
			\( -type d -a \( -name test -o -name tests \) \) \
			-o \
			\( -type f -a \( -name '*.pyc' -o -name '*.pyo' \) \) \
		\) -exec rm -rf '{}' + \
	&& rm -rf /usr/src/python

# if this is called "PIP_VERSION", pip explodes with "ValueError: invalid truth value '<VERSION>'"
ENV PYTHON_PIP_VERSION 9.0.1

RUN set -ex; \
	\
	apk add --no-cache --virtual .fetch-deps openssl; \
	\
	wget -O get-pip.py 'https://bootstrap.pypa.io/get-pip.py'; \
	\
	apk del .fetch-deps; \
	\
	python get-pip.py \
		--disable-pip-version-check \
		--no-cache-dir \
		"pip==$PYTHON_PIP_VERSION" \
	; \
	pip --version; \
	\
	find /usr/local -depth \
		\( \
			\( -type d -a \( -name test -o -name tests \) \) \
			-o \
			\( -type f -a \( -name '*.pyc' -o -name '*.pyo' \) \) \
		\) -exec rm -rf '{}' +; \
	rm -f get-pip.py && mkdir -p /app

# Add Project-specific Dependencies
COPY ./requirements.txt /app

# GeoDjango Dependencies
ENV PACKAGES="\
    alpine-sdk \
    libffi-dev \
    jpeg-dev \
    python-dev \
    zlib-dev \
    musl-dev \
    libffi \
    postgresql-dev \
"

RUN \
	apk add --virtual .build-deps --no-cache --upgrade $PACKAGES \
   	&& echo "http://dl-cdn.alpinelinux.org/alpine/edge/testing" > /etc/apk/repositories \
   	&& echo "http://dl-cdn.alpinelinux.org/alpine/edge/community" >> /etc/apk/repositories \
   	&& echo "http://dl-cdn.alpinelinux.org/alpine/edge/main" >> /etc/apk/repositories  \
        \
        && apk add \
            gdal-dev \
            geos-dev  \
        \
        && apk add --virtual .build-deps postgresql-libs \
        \
	&& pip install --upgrade pip \
	&& pip install -r requirements.txt --no-cache-dir \
        \
	&& apk --purge del .build-deps

# Add application
COPY . /app

WORKDIR /metoo-backend
CMD gunicorn -b :8080 app.wsgi

Deploying GeoDjango in an Alpine Linux Docker Container was originally published by Alden Jenkins at Alden Jenkins on January 19, 2019.

Alpine Linux is Mandatory

2019-01-19T00:00:00-05:00

Alpine Linux can be one of the most useful tools in your DevOps arsenal once you know how to use it.

Depending on the complexity of your use case, it will be a true test of your Docker skills and once you get it down you will have learned so much along the way… or you may just be able to use a default image and be fine with no hassle! Regardless here you’ll learn what the hype about Alpine Linux containers is all about and how you can go about creating them when you need to.

You’ve probably seen a lot of Docker image tags ending in :alpine, :alpine-3.8, :alpine-edge, and are wondering what the heck those mean. At its core, Alpine Linux is a much more minimal Linux distribution that does not come with as many built-in features. This is intended though, because with less of what you don’t need you can build the image to have only what you do need. This helps cuts down the size of your images which ultimately decreases the time that it takes to start your containers. Additionally your container will be optimized to run operations only useful for your application. This means no Bloat-ware that takes up your system resources in these containers!

This is what makes Alpine Suckless.

For most of you that can use a standard docker image for your use case like python:3-alpine, that is all you really need to know about Alpine because all of the build work is already done for you. For the rest of you who need to know how it works, strap in!

Let’s take a look at an example Alpine Dockerfile that builds all of the system libraries and dependencies that you need to run curl

FROM alpine:3.8

RUN apk add --no-cache curl

ENTRYPOINT ["/usr/bin/curl"]

The --no-cache option for the apk package manager is important because it allows all of the source files used to build the shared objects and executables to be deleted from the system after building. This means that you will only be left with the executables after the command runs. This can be an issue for specific builds where the libraries of certain packages are required to build or use other packages.

The solution to this problem is to use the --virtual option when installing apk packages which allows you to specify a virtual directory to temporarily store all of the libraries, source code, and executables inside of and manually delete that directory after you’ve built the package that you need by running apk del .dir-name at any point in the image build process that you would like. Or, if you need those libraries and shared objects during production usage, you can simply run apk add package-name and it will keep everything like a normal package manager would.

Consider installing vim which requires gcc to build:

FROM alpine:3.8

RUN apk add --virtual .build-deps gcc \
    && apk add vim \
    && apk del .build-deps

ENTRYPOINT ["/usr/bin/vim"]

Here you download and build gcc and then build vim but are only left with the vim executable because you delete the directory where gcc was installed and now gcc is no longer installed

This is the crux of most peoples strife’s with Alpine Linux: build dependency issues. Since Alpine is able to give you such small images, it sometimes has to compromise with compatibility with specific packages, and when packages update and you’re building using :alpine-latest, you’re in for some big trouble if those packages don’t. Better hope you have your Docker build layers cached up to that point in the Dockerfile!

The art of creating a good, minimal Alpine Linux container comes from being very intimate with your library versions and build requirements. The only thing that will help you with this is practice, so go try making an alpine version of your build!

Alpine Linux is Mandatory was originally published by Alden Jenkins at Alden Jenkins on January 19, 2019.

Pair Programming from Anywhere on Earth over SSH

2018-12-10T00:00:00-05:00

Let’s admit it: We all hate pair programming, but we have to admit it is effective. In pair programming, we are always exposing ourselves to new methods of programming and are given the opportunity to challenge our own ideas to bring the best solutions to fruition. The fact of the matter is that Pair programming always helps atleast one of the parties involved by teaching one in the pair something or providing a new perspective for the most efficient means to complete a task.

The Issue

Now most of the time we like the person we’re working with, or can atleast tolerate them in person. But in some cases, they are impossible to be around in person! If you’re experiencing the latter (or just prefer to pair program remotely – a much more realistic scenario which also comes with plenty of inherent convenience,) then this tutorial is for you.

Solutions

There are a couple types of solutions which allow for being able to pair program remotely.

Perhaps the most archaic solution, coding over video chat often leaves one person doing most of the work and the other person squinting at where the other person’s cursor is. This is the solution most conducive to YATS (Yelling At The Screen) when you’re trying to get your partners attention as they’re scrolling through a file and you see the piece of code you were scanning for.

While Facetime solutions succeeds in the personal connection aspect, they fail in being able to allow for easy contribution to the code from either party in the partnership. If you wanted to change the code over voice call, you would need to tell your partner what to change exactly.

The Best of both worlds

Where Code sharing websites succeed, Video sharing solutions fail, and vice versa. You can’t both code at the same time while also being able to see and talk to each other at the same time. The following allows for the best of both worlds, from anywhere in the world.

Using Tmux over SSH combined with Appear.in

The SSH protocol allows for secure access to your code base from anywhere in the world. Think of it like traveling to your house in an armored car in layman terms. Your data could still be stolen, but it would be insurmountably more difficult to do as opposed to if you were using an insecure transport method (im looking at you Telnet!)

Once you’ve SSH’d into your server, the Tmux application allows a vast expanse of applicable usages besides pair programming.

It can be used as:

A more feature-filled replacement for the popular Nohup alternative Screen
A Terminal screen multiplexer (points to the the name TMUX)
A Pair Programming solution.

Tmux runs a local server which runs any number of terminals that you like. The key here is that the local server can be attached to and disconnected from.

See it in action!

Me attaching and detatching from one of my two live Tmux sessions at will.

The issue here is that to be able to connect to User1’s Tmux session, you must also be logged in as User1.

While most people who pair program together have no problem extending the trust needed to share their password to one another, some people don’t like that level of commitment. This is not an issue! You can use SSH keys to control who has access to your user.

Once someone has an SSH Key to your server, they can simply login using that key in lieu of a password. To delegate someone an SSH key, have them first create a Public/Private key pair using the following:

ssh-keygen -t rsa -C "your_email@example.com"

The Password which it asks you to fill out can be ignored or filled depending on whether you feels he won’t let anyone else gain access to the key they just produced. If they’re the type that’s usually late for work after the night of the Powerball winner announcement, they better have a password on their key! This password acts as the second factor of Two-factor auth because the authentication requires something you have (the newly generated key) and something you know (the aforementioned password which decrypts the key)

Have the key creator give you the .pub public key which was created from the previous command output and place the contents of that key in your $HOME/.ssh/authorized_keys file and then restart your SSH service by running sudo service ssh restart. Your SSH process is now loaded with the understanding that anyone who connects with a private key which when Diffie-Hellmann’d with your public key in authorized_keys should result in an affirmative value should be allowed access to your user.

You can control who has access to your user based on the public keys listed in authorized keys. Want to prevent someone from logging in? Simply remove their entry in the file.

To attach to a running Tmux session as shown above, you can run

tmux a

if there is only one session running. Or to pick a specific session, you can run

tmux ls
# Results shown here
tmux a -t <session number picked from above results>

While each of you now has easy access to your compile scripts, and the rest of the codebase, and direct system terminal access, the issue of no video/audio personal connection still exists.

Appear.in is the perfect solution. appear.in allows for audio, video, and screen sharing communication all within the browser. No other solution provides the same functionality while also being totally free.

Happy coding!

Honorable Mentions

The vim plugin CoVim, developed by Tufts Computer Scientists, allows for pair programming through vim sessions. The downfall to this is that you must compile your vim from source with python support if it does not already have it, and you also only have access to your partner’s vim session instead of their entire terminal. This means that you do not have access to the rest of the codebase outside of vims !command functionality, which is limiting in usability. You can read more about CoVim in their announcement post here!

Pair Programming from Anywhere on Earth over SSH was originally published by Alden Jenkins at Alden Jenkins on December 10, 2018.

How metoo works

2018-11-27T00:00:00-05:00

metoo.io is the largest, most complex web service I have ever deployed. It’s a really cool app, and I’m not just saying that because I made it. If you have a chance you should absolutely check it out.

Image courtesy of donnemartin

In deploying a stack, you want to be mostly certain of the way that you deploy it from the beginning, because certain containers begin to rely on the minutae of what its input from another API looks like and changing that is not as streamlined as one would like. If you are looking for a stack to replicate, you should be comfortable choosing the following applications for their current bleeding-egde reputations.

Reverse Proxy: Nginx lets us use LetsEncrypt, a free and open Certificate Authority which also allows us to generate free TLS Certificates for each of our subdomains, all while still maintaining a SSL Labs A+ rating.
Backend Framework: Django REST allows us to use the highly scalable Python Web framework while sending JSON data as response requests. This works perfectly in conjunction with our app’s frontend React Native which injests JSON as input.
Frontend Framework: React Native allows us to deploy to androids and iPhones seemlessly all while using Javascript, a forgiving, highl level, weakly typed language that’s relatively easy to debug.
Relational Database Management System: PostGreSQL with the PostGIS extension allows us to use geolocational data.
Cache: Redis is our highly scalable, master-slave ready, in-memory cache. We chose redis over memcached due to more support in Django.
Asynchronous task completion: Celery allows us to use run non-blocking tasks such as sending texts, emails, or creating notification objects outside of the user’s request.
Task Message Broker: RabbitMQ - as opposed to using Redis as a message broker - allows us to persist tasks even in the off chance that RabbitMQ needs to be restarted. Redis does not allow for this.
Containerization Strategy: Docker means we deploy each of the above strategies as microservices and then orchestrate them in a production environment using Kubernetes.
Orchestration Strategy: Kubernetes allows for zero downtime of the service through deployment updates and potential rollbacks.
Profiling: Django Silk Is an open source profiler for django which creates models in your applications database which can be updated on a variable scale and lets us see where bottlenecks in certain views occur, or where N+1 issues arise.
Error Reporting: Sentry.io is an entirely open source service that allows us to setup our own sentry service as a container of one of our GKE nodes.
Replicas: Due to the nature of microservices being extremely portable, it’s so easy to scale each of the above services to infinity based on the current required need. For example, say we need far more Asynchronous task workers deployed because we are currently undergoing a large amount of user signups and we need to be able to send a large amount of notifications to friends of the user signing up, emails, etc.

Now that we have our stack up and running, we would want in the most ideal circumstance to be able to access various data pertaining to each node, and pod container. For this, we deployed a stat stack.

First, we need a data aggregating tool. There are plenty of choices from StatsD to influxDB to Prometheus, but we decided to go with Prometheus.

Prometheus allows us to aggregate data into a queryable format and also provides an API from which we use Grafana to scrape from.
Grafana is originally a graphite extension that allows graphing a wide variety of data sources ranging from Prometheus, to a PostgreSQL or MySQL instance.
Additionally we use Node-exporter, cAdvisor, and Alertmanager for Prometheus to scrape from.

I would absolutely recommend the same or similar stack to anyone who wants to create a reliable, highly scalable infrastructure for their webservice or similar application, the ease of knowing that everything just works is just another reason that living in 2018 is something to be appreciative of. It’s the most bleeding edge of technological advancement which we have available to us today, and it’s only going to get more mainstreamed from here.

How metoo works was originally published by Alden Jenkins at Alden Jenkins on November 27, 2018.

Stop Using Disqus

2018-10-24T00:00:00-04:00

Disqus is gaining popularity every day in both the serverless and dynamic web communities because it is a mostly-free, all-in-one solution which handles authentication, spam prevention, allows the site owner’s comments and replies to be displayed highlighted in the among other commenters all without needing to worry about any maintenance.

These luxuries come at a cost of page weight, the guaranteed privacy of both you as the website owner and all of your users, and the need to login to Disqus for anyone to create a comment.

Response times with and without Disqus.

With Disqus enabled to load by default, the page-weight - also known as your web page’s load time - becomes a nightmare. This has implications on the SEO of your website, the time before your web page is completely usable, the amount of data which your users need to receive over a possible cellular connection, and thereby the probability that users will return to your website ever again.

Without Disqus, we see an entire 800ms difference in time it takes your website to fully render to the user. thats almost a second of time every request to your website that gets lost in the abyss of potential seo ranking.

Let’s take a deeper look at the websites we’re requesting here.

Hint: it’s whole lot of tracking

flavio.com - tracking
google.com - the literal botnet
derp.com - more tracking
flavio2.com - virustotal scan of this website says do not trust

My comment solution

After creating my serverless contact form, I was inspired to see if there were any other solutions I could implement in my serverless backend. After doing some research, I found a great solution here, but didn’t feel that it had enough out-of-the-box spam protection or abuse protection, or that It was easily deployable or updatable enough. I decided to create my own version which now uses Google’s reCAPTCHA verification, and uses gravatar

You can see more about how to install a serverless comment system by following my tutorial here

Stop Using Disqus was originally published by Alden Jenkins at Alden Jenkins on October 24, 2018.

What is a Serverless Backend?

2018-10-12T00:00:00-04:00

This website is completely serverless

Serverless backends are becoming the bleeding edge of web backend solutions. The irony of a serverless backend is that there is actually still a server, but it is unaccessible at the hardware level to both the public and you as the web service creator. The awesome part about serverless backends is that they still provides the same features and dynamic content available on a normally hosted server backend.

How is this possible?

The standard deployment of a web backend involves spinning up a rented bare-metal VPS and deploying your service onto the server and serving it to the public through a reverse-proxy like nginx or Apache. In this standard model, you as the server renter are responsible for maintaining the security from attacks like open ports, ensuring server uptime, and updates of the server’s operating system. This has been the standard since the beginning of web hosting, but has never providede the solution to the aforementioned set of security risks. Here’s where serverless backends come in.

At its core, a “serverless” backend is still one that is hosted on a server, but the server is maintained by a cloud provider like Amazon, Microsoft, or Google. This allows you to forego any concerns other than the pure function of your web service. The big players simply run your functions on their servers. This coins the term Function as a Service (FaaS).

As opposed to standard bare metal hosting model where you would pay for the server and resources on a monthly basis, serverless backends are charged based on their usage. This benefits the majority of websites who dont receive exorbitant amounts of traffic to a point where the cost of renting a server for an entire month outweighs the slightly more expensive price-per-second of FaaS running your code. For perspective, the Amazon Lambda FaaS let’s you run 1,000,000 requests per month, or 400,000GB-Seconds of compute time per month before you are charged a single cent, and after that, just $0.20 per 1,000,000 requests thereafter. This means you could get 1,000,000 contact form requests from my serverless contact form application before you are even charged a penny.

Serverless also means you can deploy a completely static site with dynamic features. This website includes functional mail This website was created using the static site generator Jekyll, and is hosted entirely for free on Github Pages.

Checkout my serverless applications on my github profile!

What is a Serverless Backend? was originally published by Alden Jenkins at Alden Jenkins on October 12, 2018.

Django's bulk_update() feature is God Mode

2018-10-06T00:00:00-04:00

One of the most common issues I run into with Django performance is extraneous database queries. Whether its an n+1 query issue, a misuse of complex Q objects, or just a misunderstanding of queryset best practices, it can be tough to get your head around what the issue is in your case. Django gives tons of functionality as a framework, but for most people just getting started it’s often too much functionality to comprehend. This post will dive into essential queryset best practices and a comparison of the number of queries backing them.

Imagine the following:

1
2
3
4
all_notifications = Notification.objects.all()
for notification in all_notifications:
  if notification.type in ['type1','type2','type3']:
    notification.update(seen=True)

This code runs a query for each object in the all_notifications queryset. Conversely, the following code runs a single query for the entire all_notifications queryset, and accomplishes the same goal in:

half the lines of code (you can even do it in one line)
literally one database query
twice the elegance

1
2
all_notifications = Notification.objects.all()
all_notifications.objects.filter(type__in=['type1','type2','type3']).update(seen=True)

What we’re doing here is a something you always want to do when given the opportunity. We’re making the database do most of the work instead of Django. By filtering the queryset’s type to include all 3 types we are looking for, we forego the need to iterate through each object in the query set to then check it’s value. Instead, we tell our database to get the objects we want for us.

See it in action!

Me using query_set.update() to save me countless queries

bulk_create()

this one is actually a function

bulk_create() it something I use all the time for making notifications in metoo on post_save signals for certain models. For example, anytime a Rabble comment is created, I make Notification objects for each user who the comment was replying to in addition to the author of the post.

bulk_create() works much like the query_set.update() in that it drastically reduces the number of queries that Django gives the database in contrast to the per-object amount you would run in the most pragmatic university-educated programmer style.

Bad implementation

1
2
for user in replied_to_users:
   Notification.objects.create(to=user, comment=the_comment, type="RepliedToRabble")

Don’t be fooled by the low line count here! This implementation runs a SQL query for each user in replied_to_users. Imagine if the number of Notification objects you were creating here was 100 or 100000! Considering an average query response from your database to Django takes ~25ms, you’re looking at some serious lag time. Let’s see a more elegant and efficient implementation.

Single query

1
2
3
4
new_notifications = []
for user in replied_to_users:
   new_notifications.append(Notification(to=user, comment=the_comment, type="RepliedToRabble"))
Notification.objects.bulk_create(new_notifications)

Taking the time to consider how you may be running unnecessary queries in your projects and reap the rewards of speed!

Django's bulk_update() feature is God Mode was originally published by Alden Jenkins at Alden Jenkins on October 06, 2018.

Alden Jenkins

Omnipotent Service Level Indicators

Deploying GeoDjango in an Alpine Linux Docker Container

Considerations

Alpine with GeoDjango

Alpine Linux is Mandatory

Pair Programming from Anywhere on Earth over SSH

The Issue

Solutions

The Best of both worlds

Using Tmux over SSH combined with Appear.in

See it in action!

Honorable Mentions

How metoo works

Stop Using Disqus

Response times with and without Disqus.

Let’s take a deeper look at the websites we’re requesting here.

Other solutions

Third Party

Hosted Solutions

Off-site hosting

No comments

My comment solution

What is a Serverless Backend?

This website is completely serverless

How is this possible?

Django's bulk_update() feature is God Mode

Imagine the following:

See it in action!

bulk_create()

Bad implementation

Single query

Alden Jenkins

Omnipotent Service Level Indicators

Deploying GeoDjango in an Alpine Linux Docker Container

Considerations

Alpine with GeoDjango

Alpine Linux is Mandatory

Pair Programming from Anywhere on Earth over SSH

The Issue

Solutions

Facetime (or other video/screen sharing solution):

Code Sharing websites like Google Docs

The Best of both worlds

Using Tmux over SSH combined with Appear.in

See it in action!

Honorable Mentions

How metoo works

Stop Using Disqus

Response times with and without Disqus.

Let’s take a deeper look at the websites we’re requesting here.

Other solutions

Third Party

Hosted Solutions

Off-site hosting

No comments

My comment solution

What is a Serverless Backend?

This website is completely serverless

How is this possible?

Django's bulk_update() feature is God Mode

Imagine the following:

See it in action!

bulk_create()

Bad implementation

Single query