14 August 2018
0 comments
Redis,
Django,
Web development,
Python
Here's the code. It's quick-n-dirty but it works wonderfully:
import functools
import hashlib
from django.core.cache import cache
from django.utils.encoding import force_bytes
def lock_decorator(key_maker=None):
"""
When you want to lock a function from more than 1 call at a time.
"""
def decorator(func):
@functools.wraps(func)
def inner(*args, **kwargs):
if key_maker:
key = key_maker(*args, **kwargs)
else:
key = str(args) + str(kwargs)
lock_key = hashlib.md5(force_bytes(key)).hexdigest()
with cache.lock(lock_key):
return func(*args, **kwargs)
return inner
return decorator
How To Use It
This has saved my bacon more than once. I use it on functions that really need to be made synchronous. For example, suppose you have a function like this:
def fetch_remote_thing(name):
try:
return Thing.objects.get(name=name).result
except Thing.DoesNotExist:
# Need to go out and fetch this
result = some_internet_fetching(name) # Assume this is sloooow
Thing.objects.create(name=name, result=result)
return result
That function is quite dangerous because if executed by two concurrent web requests for example, they will trigger
two "identical" calls to some_internet_fetching and if the database didn't have the name already, it will most likely trigger two calls to Thing.objects.create(name=name, ...) which could lead to integrity errors or if it doesn't the whole function breaks down because it assumes that there is only 1 or 0 of these Thing records.
Easy to solve, just add the lock_decorator:
@lock_decorator()
def fetch_remote_thing(name):
try:
return Thing.objects.get(name=name).result
except Thing.DoesNotExist:
# Need to go out and fetch this
result = some_internet_fetching(name) # Assume this is sloooow
Thing.objects.create(name=name, result=result)
return result
Now, thanks to Redis distributed locks, the function is always allowed to finish before it starts another one. All the hairy locking (in particular, the waiting) is implemented deep down in Redis which is rock solid.
Bonus Usage
Another use that has also saved my bacon is functions that aren't necessarily called with the same input argument but each call is so resource intensive that you want to make sure it only does one of these at a time. Suppose you have a Django view function that does some resource intensive work and you want to stagger the calls so that it only runs it one at a time. Like this for example:
def api_stats_calculations(request, part):
if part == 'users-per-month':
data = _calculate_users_per_month() # expensive
elif part == 'pageviews-per-week':
data = _calculate_pageviews_per_week() # intensive
elif part == 'downloads-per-day':
data = _calculate_download_per_day() # slow
elif you == 'get' and the == 'idea':
...
return http.JsonResponse({'data': data})
If you just put @lock_decorator() on this Django view function, and you have some (almost) concurrent calls to this function, for example from a uWSGI server running with threads and multiple processes, then it will not synchronize the calls.
The solution to this is to write your own function for generating the lock key, like this for example:
@lock_decorator(
key_maker=lamnbda request, part: 'api_stats_calculations'
)
def api_stats_calculations(request, part):
if part == 'users-per-month':
data = _calculate_users_per_month() # expensive
elif part == 'pageviews-per-week':
data = _calculate_pageviews_per_week() # intensive
elif part == 'downloads-per-day':
data = _calculate_download_per_day() # slow
elif you == 'get' and the == 'idea':
...
return http.JsonResponse({'data': data})
Now it works.
How Time-Expensive Is It?
Perhaps you worry that 99% of your calls to the function don't have the problem of calling the function concurrently. How much is this overhead of this lock costing you? I wondered that too and set up a simple stress test where I wrote a really simple Django view function. It looked something like this:
@lock_decorator(key_maker=lambda request: 'samekey')
def sample_view_function(request):
return http.HttpResponse('Ok\n')
I started a Django server with uWSGI with multiple processors and threads enabled. Then I bombarded this function with a simple concurrent stress test and observed the requests per minute. The cost was extremely tiny and almost negligable (compared to not using the lock decorator). Granted, in this test I used Redis on redis://localhost:6379/0 but generally the conclusion was that the call is extremely fast and not something to worry too much about. But your mileage may vary so do your own experiments for your context.
What's Needed
You need to use django-redis as your Django cache backend. I've blogged before about using django-redis, for example Fastest cache backend possible for Django and Fastest Redis configuration for Django.
13 August 2018
0 comments
Django,
Web development,
Python
django-html-validator is a Django project that can validate your generated HTML. It does so by sending the HTML to https://html5.validator.nu/ or you can start your own Java server locally with vnu.jar from here.
The output is that you can have validation errors printed to stdout or you can have them put as .txt files in a temporary directory. You can also include it in your test suite and make it so that tests fail if invalid HTML is generated during rendering in Django unit tests.
The project seems to have become a lot more popular than I thought it would. It started as a one-evening-hack and because there was interest I wrapped it up in a proper project with "docs" and set up CI for future contributions.
I kinda of forgot the project since almost all my current projects generate JSON on the server and generates the DOM on-the-fly with client-side JavaScript but apparently a lot of issues and PRs were filed related to making it work in Django 2.x. So I took the time last night to tidy up the tox.ini etc. and the necessary compatibility fixes to make it work with but Django 1.8 up to Django 2.1. Pull request here.
Thank you all who contributed! I'll try to make a better job noticing filed issues in the future.
10 August 2018
0 comments
Python
Whenever you want to quickly bombard a URL with some concurrent traffic, you can use this:
import random
import time
import requests
import concurrent.futures
def _get_size(url):
sleep = random.random() / 10
# print("sleep", sleep)
time.sleep(sleep)
r = requests.get(url)
# print(r.status_code)
assert len(r.text)
return len(r.text)
def run(url, times=10):
sizes = []
futures = []
with concurrent.futures.ThreadPoolExecutor() as executor:
for _ in range(times):
futures.append(executor.submit(_get_size, url))
for future in concurrent.futures.as_completed(futures):
sizes.append(future.result())
return sizes
if __name__ == "__main__":
import sys
print(run(sys.argv[1]))
It's really basic but it works wonderfully. It starts 10 concurrent threads that all hit the same URL at almost the same time.
I've been using this stress test a local Django server to test some atomicity writes with the file system.
20 June 2018
0 comments
Django,
Web development,
Python
I use this a lot. It has served me very well. The code:
import hashlib
import functools
import markus # optional
from django.core.cache import cache
from django import http
from django.utils.encoding import force_bytes, iri_to_uri
metrics = markus.get_metrics(__name__) # optional
def json_response_cache_page_decorator(seconds):
"""Cache only when there's a healthy http.JsonResponse response."""
def decorator(func):
@functools.wraps(func)
def inner(request, *args, **kwargs):
cache_key = 'json_response_cache:{}:{}'.format(
func.__name__,
hashlib.md5(force_bytes(iri_to_uri(
request.build_absolute_uri()
))).hexdigest()
)
content = cache.get(cache_key)
if content is not None:
# metrics is optional
metrics.incr(
'json_response_cache_hit',
tags=['view:{}'.format(func.__name__)]
)
return http.HttpResponse(
content,
content_type='application/json'
)
response = func(request, *args, **kwargs)
if (
isinstance(response, http.JsonResponse) and
response.status_code in (200, 304)
):
cache.set(cache_key, response.content, seconds)
return response
return inner
return decorator
To use it simply add to Django view functions that might return a http.JsonResponse. For example, something like this:
@json_response_cache_page_decorator(60)
def search(request):
q = request.GET.get('q')
if not q:
return http.HttpResponseBadRequest('no q')
results = search_database(q)
return http.JsonResponse({
'results': results,
})
The reasons I use this instead of django.views.decorators.cache.cache_page() is because of a couple of reasons.
cache_page generates cache keys that don't contain the view function name. cache_page tries to cache the whole http.HttpResponse instance which can't be serialized if you use the msgpack serializer.cache_page also sends Cache-Control headers which is not always what you want. - Not possible to inject your own custom code such as my usage of
metrics.
Disclaimer: This snippet of code comes from a side-project that has a very specific set of requirements. They're rather unique to that project and I have a full picture of the needs. E.g. I know what specific headers matter and don't matter. Your project might be different. For example, perhaps you don't have markus to handle your metrics. Or perhaps you need to re-write the query string for something to normalize the cache key differently. Point being, take the snippet of code as inspiration when you too find that django.views.decorators.cache.cache_page() isn't good enough for your Django view functions.
07 June 2018
2 comments
Python
tl;dr; Use except GeneratorExit if your Python generator needs to know the consumer broke out.
Suppose you have a generator that yields things out. After each yield you want to execute some code that does something like logging or cleaning up. Here one such trivialized example:
The Problem
def pump():
numbers = [1, 2, 3, 4]
for number in numbers:
yield number
print("Have sent", number)
print("Last number was sent")
for number in pump():
print("Got", number)
print("All done")
The output is, as expected:
Got 1
Have sent 1
Got 2
Have sent 2
Got 3
Have sent 3
Got 4
Have sent 4
Last number was sent
All done
In this scenario, the consumer of the generator (the for number in pump() loop in this example) gets every thing the generator generates so after the last yield the generator is free to do any last minute activities which might be important such as closing a socket or updating a database.
Suppose the consumer is getting a bit "impatient" and breaks out as soon as it has what it needed.
def pump():
numbers = [1, 2, 3, 4]
for number in numbers:
yield number
print("Have sent", number)
print("Last number was sent")
for number in pump():
print("Got", number)
# THESE TWO NEW LINES
if number >= 2:
break
print("All done")
What do you think the out is now? I'll tell you:
Got 1
Have sent 1
Got 2
All done
In other words, the potentially important lines print("Have sent", number) and print("Last number was sent") never gets executed! The generator could tell the consumer (through documentation) of the generator "Don't break! If you don't want me any more raise a StopIteration". But that's not a feasible requirement.
The Solution
But! There is a better solution and that's to catch GeneratorExit exceptions.
def pump():
numbers = [1, 2, 3, 4]
try:
for number in numbers:
yield number
print("Have sent", number)
except GeneratorExit:
print("Exception!")
print("Last number was sent")
for number in pump():
print("Got", number)
if number == 2:
break
print("All done")
Now you get what you might want:
Got 1
Have sent 1
Got 2
Exception!
Last number was sent
All done
Next Level Stuff
Note in the last example's output, it never prints Have sent 2 even though the generator really did send that number. Suppose that's an important piece of information, then you can reach that inside the except GeneratorExit block. Like this for example:
def pump():
numbers = [1, 2, 3, 4]
try:
for number in numbers:
yield number
print("Have sent", number)
except GeneratorExit:
print("Have sent*", number)
print("Last number was sent")
for number in pump():
print("Got", number)
if number == 2:
break
print("All done")
And the output is:
Got 1
Have sent 1
Got 2
Have sent* 2
Last number was sent
All done
The * is just in case we wanted to distinguish between a break happening or not. Depends on your application.
21 May 2018
2 comments
Python
Datadog is an awesome sofware-as-a-service where you can aggregate and visualize statsd metrics sent from an application. For visualizing timings you create a time series graph. It can look something like this:
This time series looks sane because because it's timings made very very frequently. But what if it happens very rarely. Like once a day. Then, the graph doesn't look very useful. See this example:
Not only is it happening rarely, the amount of seconds is really quite hard to parse. I.e. what's 2.6 million milliseconds (answer is approximately 45 minutes). So to solve that I used the Datadog API. Now I can get a metric of every single point in milliseconds and I can make a little data table with human-readable dates and times.
The end result looks something like this:
SCOPE: ENV:PROD
+-------------------------+------------------------+-----------------------+
| WHEN | TIME AGO | TIME TOOK |
+=========================+========================+=======================+
| Mon 2018-05-21T17:00:00 | 2 hours 43 minutes ago | 23 minutes 32 seconds |
+-------------------------+------------------------+-----------------------+
| Sun 2018-05-20T17:00:00 | 1 day 2 hours ago | 20 seconds |
+-------------------------+------------------------+-----------------------+
| Sat 2018-05-19T17:00:00 | 2 days 2 hours ago | 20 seconds |
+-------------------------+------------------------+-----------------------+
| Fri 2018-05-18T17:00:00 | 3 days 2 hours ago | 2 minutes 24 seconds |
+-------------------------+------------------------+-----------------------+
| Wed 2018-05-16T20:00:00 | 4 days 23 hours ago | 38 minutes 38 seconds |
+-------------------------+------------------------+-----------------------+
It's not gorgeous and there are a lot of caveats but it's at least really easy to read. See the metrics.py code here.
I don't think you can run this code since you don't have the same (hardcoded) metrics but hopefully it can serve as an example to whet your appetite.
What I'm going to do next, if I have time, is to run this as a Flask app instead that outputs a HTML table on a Herokup app or something.
15 May 2018
8 comments
Python
It all started so innocently. The task at hand was to download an inventory of every single file ever uploaded to a public AWS S3 bucket. The way that works is that you download the root manifest.json. It references a boat load of .csv.gz files. So to go through every single file uploaded to the bucket, you read the manifest.json, the download each and every .csv.gz file. Now you can parse these and do something with each row. An example row in one of the CSV files looks like this:
"net-mozaws-prod-delivery-firefox","pub/firefox/nightly/latest-mozilla-central-l10n/linux-i686/xpi/firefox-57.0a1.gn.langpack.xpi","474348","2017-09-21T13:08:25.000Z","0af6ce0b494d1f380a8b1cd6f42e36cb"
In the Mozilla Buildhub what we do is we periodically do this, in Python (with asyncio), to spot if there are any files in the S3 bucket have potentially missed to record in an different database.
But ouf the 150 or so .csv.gz files, most of the files are getting old and in this particular application we can be certain it's unlikely to be relevant and can be ignored. To come to that conclusion you parse each .csv.gz file, parse each row of the CSV, extract the last_modified value (e.g. 2017-09-21T13:08:25.000Z) into a datetime.datetime instance. Now you can quickly decide if it's too old or recent enough to go through the other various checks.
So, the task is to parse 150 .csv.gz files totalling about 2.5GB with roughly 75 million rows. Basically parsing the date strings into datetime.datetime objects 75 million times.
Python
What this script does is it opens, synchronously, each and every .csv.gz file, parses each records date and compares it to a constant ("Is this record older than 6 months or not?")
This is an extraction of a bigger system to just look at the performance of parsing all those .csv.gz files to figure out how many are old and how many are within 6 months. Code looks like this:
import datetime
import gzip
import csv
from glob import glob
cutoff = datetime.datetime.now() - datetime.timedelta(days=6 * 30)
def count(fn):
count = total = 0
with gzip.open(fn, 'rt') as f:
reader = csv.reader(f)
for line in reader:
lastmodified = datetime.datetime.strptime(
line[3],
'%Y-%m-%dT%H:%M:%S.%fZ'
)
if lastmodified > cutoff:
count += 1
total += 1
return total, count
def run():
total = recent = 0
for fn in glob('*.csv.gz'):
if len(fn) == 39: # filter out other junk files that don't fit the pattern
print(fn)
t, c = count(fn)
total += t
recent += c
print(total)
print(recent)
print('{:.1f}%'.format(100 * recent / total))
run()
Code as a gist here.
Only problem. This is horribly slow.
To reproduce this, I took a sample of 38 of these .csv.gz files and ran the above code with CPython 3.6.5. It took 3m44s on my 2017 MacBook Pro.
Let's try a couple low-hanging fruit ideas:
- PyPy 5.10.1 (based on 3.5.1): 2m30s
- Using asyncio on Python 3.6.5: 3m37s
- Using a thread pool on Python 3.6.5: 7m05s
- Using a process pool on Python 3.6.5: 1m5s
Hmm... Clearly this is CPU bound and using multiple processes is the ticket. But what's really holding us back is the date parsing. From the "Fastest Python datetime parser" benchmark the trick is to use ciso8601. Alright, let's try that. Diff:
6c6,10
< cutoff = datetime.datetime.now() - datetime.timedelta(days=6 * 30)
---
> import ciso8601
>
> cutoff = datetime.datetime.utcnow().replace(
> tzinfo=datetime.timezone.utc
> ) - datetime.timedelta(days=6 * 30)
14,17c18
< lastmodified = datetime.datetime.strptime(
< line[3],
< '%Y-%m-%dT%H:%M:%S.%fZ'
< )
---
> lastmodified = ciso8601.parse_datetime(line[3])
Version with ciso8601 here.
So what originally took 3 and a half minutes now takes 18 seconds. I suspect that's about as good as it gets with Python.
But it's not too shabby. Parsing 12,980,990 date strings in 18 seconds. Not bad.
Go
My Go is getting rusty but it's quite easy to write one of these so I couldn't resist the temptation:
package main
import (
"compress/gzip"
"encoding/csv"
"fmt"
"log"
"os"
"path/filepath"
"strconv"
"time"
)
func count(fn string, index int) (int, int) {
fmt.Printf("%d %v\n", index, fn)
f, err := os.Open(fn)
if err != nil {
log.Fatal(err)
}
defer f.Close()
gr, err := gzip.NewReader(f)
if err != nil {
log.Fatal(err)
}
defer gr.Close()
cr := csv.NewReader(gr)
rec, err := cr.ReadAll()
if err != nil {
log.Fatal(err)
}
var count = 0
var total = 0
layout := "2006-01-02T15:04:05.000Z"
minimum, err := time.Parse(layout, "2017-11-02T00:00:00.000Z")
if err != nil {
log.Fatal(err)
}
for _, v := range rec {
last_modified := v[3]
t, err := time.Parse(layout, last_modified)
if err != nil {
log.Fatal(err)
}
if t.After(minimum) {
count += 1
}
total += 1
}
return total, count
}
func FloatToString(input_num float64) string {
// to convert a float number to a string
return strconv.FormatFloat(input_num, 'f', 2, 64)
}
func main() {
var pattern = "*.csv.gz"
files, err := filepath.Glob(pattern)
if err != nil {
panic(err)
}
total := int(0)
recent := int(0)
for i, fn := range files {
if len(fn) == 39 {
// fmt.Println(fn)
c, t := count(fn, i)
total += t
recent += c
}
}
fmt.Println(total)
fmt.Println(recent)
ratio := float64(recent) / float64(total)
fmt.Println(FloatToString(100.0 * ratio))
}
Code as as gist here.
Using go1.10.1 I run go make main.go and then time ./main. This takes just 20s which is about the time it took the Python version that uses a process pool and ciso8601.
I showed this to my colleague @mostlygeek who saw my scripts and did the Go version more properly with its own repo.
At first pass (go build filter.go and time ./filter) this one clocks in at 19s just like my naive initial hack. However if you run this as time GOPAR=2 ./filter it will use 8 workers (my MacBook Pro as 8 CPUs) and now it only takes: 5.3s.
By the way, check out @mostlygeek's download.sh if you want to generate and download yourself a bunch of these .csv.gz files.
Rust
First @mythmon stepped up and wrote two versions. One single-threaded and one using rayon which will use all CPUs you have.
The version using rayon looks like this (single-threaded version here):
extern crate csv;
extern crate flate2;
#[macro_use]
extern crate serde_derive;
extern crate chrono;
extern crate rayon;
use std::env;
use std::fs::File;
use std::io;
use std::iter::Sum;
use chrono::{DateTime, Utc, Duration};
use flate2::read::GzDecoder;
use rayon::prelude::*;
#[derive(Debug, Deserialize)]
struct Row {
bucket: String,
key: String,
size: usize,
last_modified_date: DateTime<Utc>,
etag: String,
}
struct Stats {
total: usize,
recent: usize,
}
impl Sum for Stats {
fn sum<I: Iterator<Item=Self>>(iter: I) -> Self {
let mut acc = Stats { total: 0, recent: 0 };
for stat in iter {
acc.total += stat.total;
acc.recent += stat.recent;
}
acc
}
}
fn main() {
let cutoff = Utc::now() - Duration::days(180);
let filenames: Vec<String> = env::args().skip(1).collect();
let stats: Stats = filenames.par_iter()
.map(|filename| count(&filename, cutoff).expect(&format!("Couldn't read {}", &filename)))
.sum();
let percent = 100.0 * stats.recent as f32 / stats.total as f32;
println!("{} / {} = {:.2}%", stats.recent, stats.total, percent);
}
fn count(path: &str, cutoff: DateTime<Utc>) -> Result<Stats, io::Error> {
let mut input_file = File::open(&path)?;
let decoder = GzDecoder::new(&mut input_file)?;
let mut reader = csv::ReaderBuilder::new()
.has_headers(false)
.from_reader(decoder);
let mut total = 0;
let recent = reader.deserialize::<Row>()
.flat_map(|row| row) // Unwrap Somes, and skip Nones
.inspect(|_| total += 1)
.filter(|row| row.last_modified_date > cutoff)
.count();
Ok(Stats { total, recent })
}
I installed it like this (I have rustc 1.26 installed):
▶ cargo build --release --bin single_threaded
▶ time ./target/release/single_threaded ../*.csv.gz
That finishes in 22s.
Now let's try the one that uses all CPUs in parallel:
▶ cargo build --release --bin rayon
▶ time ./target/release/rayon ../*.csv.gz
That took 5.6s
That's rougly 3 times faster than the best Python version.
When chatting with my teammates about this, I "nerd-sniped" in another colleague, Ted Mielczarek who forked Mike's Rust version.
Compile and running these two I get 17.4s for the single-threaded version and 2.5s for the rayon one.
In conclusion
- Simplest Python version: 3m44s
- Using PyPy (for Python 3.5): 2m30s
- Using
asyncio: 3m37s
- Using
concurrent.futures.ThreadPoolExecutor: 7m05s
- Using
concurrent.futures.ProcessPoolExecutor: 1m5s
- Using
ciso8601 to parse the dates: 1m08s
- Using
ciso8601 and concurrent.futures.ProcessPoolExecutor: 18.4s
- Novice Go version: 20s
- Go version with parallel workers: 5.3s
- Single-threaded Rust version: 22s
- Parallel workers in Rust: 5.6s
- (Ted's) Single-threaded Rust version: 17.4s
- (Ted's) Parallel workers in Rust: 2.5s
Most interesting is that this is not surprising. Of course it gets faster if you use more CPUs in parallel. And of course a C binary to do a critical piece in Python will speed things up. What I'm personally quite attracted to is how easy it was to replace the date parsing with ciso8601 in Python and get a more-than-double performance boost with very little work.
Yes, I'm perfectly aware that these are not scientific conditions and the list of disclaimers is long and boring. However, it was fun! It's fun to compare and constrast solutions like this. Don't you think?
11 May 2018
1 comment
Django,
Python
By default, when you hook up a model to Django REST Framework and run a query in JSON format, what you get is a list. E.g.
For GET localhost:8000/api/mymodel/
[
{"id": 1, "name": "Foo"},
{"id": 2, "name": "Bar"},
{"id": 3, "name": "Baz"}
]
This isn't great because there's no good way to include other auxiliary data points that are relevant to this query. In Elasticsearch you get something like this:
{
"took": 106,
"timed_out": false,
"_shards": {},
"hits": {
"total": 0,
"hits": [],
"max_score": 1
}
}
Another key is that perhaps today you can't think of any immediate reason why you want to include some additonal meta data about the query, but perhaps some day you will.
The way to solve this in Django REST Framework is to override the list function in your Viewset classes.
Before
# views.py
# views.py
from rest_framework import viewsets
class BlogpostViewSet(viewsets.ModelViewSet):
queryset = Blogpost.objects.all().order_by('date')
serializer_class = serializers.BlogpostSerializer
After
# views.py
from rest_framework import viewsets
class BlogpostViewSet(viewsets.ModelViewSet):
queryset = Blogpost.objects.all().order_by('date')
serializer_class = serializers.BlogpostSerializer
def list(self, request, *args, **kwargs):
response = super().list(request, *args, **kwargs)
# Where the magic happens!
return response
Now, to re-wrap that, the response.data is a OrderedDict which you can change. Here's one way to do it:
# views.py
from rest_framework import viewsets
class BlogpostViewSet(viewsets.ModelViewSet):
queryset = Blogpost.objects.all().order_by('date')
serializer_class = serializers.BlogpostSerializer
def list(self, request, *args, **kwargs):
response = super().list(request, *args, **kwargs)
response.data = {
'hits': response.data,
}
return response
And if you want to do the same the "detail API" where you retrieve a single model instance, you can add an override to the retrieve method:
def retrieve(self, request, *args, **kwargs):
response = super().retrieve(request, *args, **kwargs)
response.data = {
'hit': response.data,
}
return response
That's it. Perhaps it's personal preference but if you, like me, prefers this style, this is how you do it. I like namespacing things instead of dealing with raw lists.
"Namespaces are one honking great idea -- let's do more of those!"
From import this
Note! This works equally when you enable pagination. Enabling pagination immediately changes the main result from a list to a dictionary. I.e. Instead of...
[
{"id": 1, "name": "Foo"},
{"id": 2, "name": "Bar"},
{"id": 3, "name": "Baz"}
]
you now get...
{
"count": 3,
"next": null,
"previous": null,
"items": [
{"id": 1, "name": "Foo"},
{"id": 2, "name": "Bar"},
{"id": 3, "name": "Baz"}
]
}
So if you apply the "trick" mentioned in this blog post you end up with...:
{
"hits": {
"count": 3,
"next": null,
"previous": null,
"items": [
{"id": 1, "name": "Foo"},
{"id": 2, "name": "Bar"},
{"id": 3, "name": "Baz"}
]
}
}
02 May 2018
0 comments
Python
tl;dr; It's ciso8601.
I have this Python app that I'm working on. It has a cron job that downloads a listing of every single file listed in an S3 bucket. AWS S3 publishes a manifest of .csv.gz files. You download the manifest and for each hashhashash.csv.gz you download those files. Then my program reads these CSV files and it is able to ignore certain rows based on them being beyond the retention period. It basically parses the ISO formatted datetime as a string, compares it with a cutoff datetime.datetime instance and is able to quickly skip or allow it in for full processing.
At the time of writing, it's roughly 160 .csv.gz files weighing a total of about 2GB. In total it's about 50 millions rows of CSV. That means it's 50 million datetime parsings.
I admit, this cron job doesn't have to be super fast and it's OK if it takes an hour since it's just a cron job running on a server in the cloud somewhere. But I would like to know, is there a way to speed up the date parsing because that feels expensive to do in Python 50 million times per day.
Here's the benchmark:
import csv
import datetime
import random
import statistics
import time
import ciso8601
def f1(datestr):
return datetime.datetime.strptime(datestr, '%Y-%m-%dT%H:%M:%S.%fZ')
def f2(datestr):
return ciso8601.parse_datetime(datestr)
def f3(datestr):
return datetime.datetime(
int(datestr[:4]),
int(datestr[5:7]),
int(datestr[8:10]),
int(datestr[11:13]),
int(datestr[14:16]),
int(datestr[17:19]),
)
# Assertions
assert f1(
'2017-09-21T12:54:24.000Z'
).strftime('%Y%m%d%H%M') == f2(
'2017-09-21T12:54:24.000Z'
).strftime('%Y%m%d%H%M') == f3(
'2017-09-21T12:54:24.000Z'
).strftime('%Y%m%d%H%M') == '201709211254'
functions = f1, f2, f3
times = {f.__name__: [] for f in functions}
with open('046444ae07279c115edfc23ba1cd8a19.csv') as f:
reader = csv.reader(f)
for row in reader:
func = random.choice(functions)
t0 = time.clock()
func(row[3])
t1 = time.clock()
times[func.__name__].append((t1 - t0) * 1000)
def ms(number):
return '{:.5f}ms'.format(number)
for name, numbers in times.items():
print('FUNCTION:', name, 'Used', format(len(numbers), ','), 'times')
print('\tBEST ', ms(min(numbers)))
print('\tMEDIAN', ms(statistics.median(numbers)))
print('\tMEAN ', ms(statistics.mean(numbers)))
print('\tSTDEV ', ms(statistics.stdev(numbers)))
Yeah, it's a bit ugly but it works. Here's the output:
FUNCTION: f1 Used 111,475 times
BEST 0.01300ms
MEDIAN 0.01500ms
MEAN 0.01685ms
STDEV 0.00706ms
FUNCTION: f2 Used 111,764 times
BEST 0.00100ms
MEDIAN 0.00200ms
MEAN 0.00197ms
STDEV 0.00167ms
FUNCTION: f3 Used 111,362 times
BEST 0.00300ms
MEDIAN 0.00400ms
MEAN 0.00409ms
STDEV 0.00225ms
In summary:
f1: 0.01300 millisecondsf2: 0.00100 millisecondsf3: 0.00300 milliseconds
Or, if you compare to the slowest (f1):
f1: baselinef2: 13 times fasterf3: 6 times faster
UPDATE
If you know with confidence that you don't want or need timezone aware datetime instances, you can use csiso8601.parse_datetime_unaware instead.
from the README:
"Please note that it takes more time to parse aware datetimes, especially if they're not in UTC. If you don't care about time zone information, use the parse_datetime_unaware method, which will discard any time zone information and is faster."
In my benchmark the strings I use look like this 2017-09-21T12:54:24.000Z. I added another function to the benmark that uses ciso8601.parse_datetime_unaware and it clocked in at the exact same time as f2.
19 April 2018
0 comments
PostgreSQL,
Python
tl;dr; Use best-explain-analyze.py to benchmark a SQL query in Postgres.
I often benchmark SQL by extracting the relevant SQL string, prefix it with EXPLAIN ANALYZE, putting it into a file (e.g. benchmark.sql) and then running psql mydatabase < benchmark.sql. That spits out something like this:
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------
Index Scan using main_song_ca949605 on main_song (cost=0.43..237.62 rows=1 width=4) (actual time=1.586..1.586 rows=0 loops=1)
Index Cond: (artist_id = 27451)
Filter: (((name)::text % 'Facing The Abyss'::text) AND (id <> 2856345))
Rows Removed by Filter: 170
Planning time: 3.335 ms
Execution time: 1.701 ms
(6 rows)
Cool. So you study the steps of the query plan and look for "Seq Scan" and various sub-optimal uses of heaps and indices etc. But often, you really want to just look at the Execution time milliseconds number. Especially if you might have to slightly different SQL queries to compare and contrast.
However, as you might have noticed, the number on the Execution time varies between runs. You might think nothing's changed but Postgres might have warmed up some internal caches or your host might be more busy or less busy. To remedy this, you run the EXPLAIN ANALYZE select ... a couple of times to get a feeling for an average. But there's a much better way!
best-explain-analyze.py
Check this out: best-explain-analyze.py
Download it into your ~/bin/ and chmod +x ~/bin/best-explain-analyze.py. I wrote it just this morning so don't judge!
Now, when you run it it runs that thing 10 times (by default) and reports the best Execution time, its mean and its median. Example output:
▶ best-explain-analyze.py songsearch dummy.sql
EXECUTION TIME
BEST 1.229ms
MEAN 1.489ms
MEDIAN 1.409ms
PLANNING TIME
BEST 1.994ms
MEAN 4.557ms
MEDIAN 2.292ms
The "BEST" is an important metric. More important than mean or median.
Raymond Hettinger explains it better than I do. His context is for benchmarking Python code but it's equally applicable:
"Use the min() rather than the average of the timings. That is a recommendation from me, from Tim Peters, and from Guido van Rossum. The fastest time represents the best an algorithm can perform when the caches are loaded and the system isn't busy with other tasks. All the timings are noisy -- the fastest time is the least noisy. It is easy to show that the fastest timings are the most reproducible and therefore the most useful when timing two different implementations."
