Brock Friedrich la-mar

Redis in Production at Smyte

To be clear we continue to run many Redis services in our production environment. It’s a great tool for prototyping and small workloads. For our use case however, we believe the cost and complexity of our setup justifies urgently finding alternate solutions.

Each of our Redis servers are clearly numbered with a current leader in one availability zone, and a follower in another zone.
The servers run ~16 different individual Redis processes. This helps us utilize CPUs (as Redis is single-threaded) but it also means we only need an extra 1/16th memory in order to safely perform a BGSAVE (due to copy-on-write), though in practice it’s closer to 1/8 because it’s not always evenly balanced.
Our leaders do not every run BGSAVE unless we’re bringing up a new slave which is carefully done manually. Since issues with the slave should not affect the leader and new slave connections might trigger an unsafe BGSAVE on the leader, slave Redis processes are set to not automatically rest

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

General rules

Follow standard conventions.
Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
Boy scout rule. Leave the campground cleaner than you found it.
Always find root cause. Always look for the root cause of a problem.

Design rules

Let's list here crates that enhance Rust as a language.

It not "batteries" like in stdx, but Rust-specific crates for workarounds for various missing features and experimental ideals from non-accepted/postponed RFCs, or just hacky tricks.

The list is supposed to contain (mostly) crates that are internal to Rust, not ones for making Rust deal with "external world" like other languages bindings, file formats, protocols and so on.

Primary focus should be on crates that are not easy to find by conventional means (e.g. no algorithm name, format or protocol to search for).

Note that quality of the listed crates may vary from proof-of-concept to stable-and-widely-used.

	-- show running queries (pre 9.2)
	SELECT procpid, age(clock_timestamp(), query_start), usename, current_query
	FROM pg_stat_activity
	WHERE current_query != '<IDLE>' AND current_query NOT ILIKE '%pg_stat_activity%'
	ORDER BY query_start desc;

	-- show running queries (9.2)
	SELECT pid, age(clock_timestamp(), query_start), usename, query
	FROM pg_stat_activity
	WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'

	# import config.
	# You can change the default config with `make cnf="config_special.env" build`
	cnf ?= config.env
	include $(cnf)
	export $(shell sed 's/=.*//' $(cnf))

	# import deploy config
	# You can change the default deploy config with `make cnf="deploy_special.env" release`
	dpl ?= deploy.env
	include $(dpl)

	import asyncio
	from concurrent import futures
	import functools
	import inspect
	import threading

	from grpc import _server

	def _loop_mgr(loop: asyncio.AbstractEventLoop):

	""" Until Sendgrid updates the Python SDK to handle the new dynamic template data, you can use this Gist to
	manage dynmaic template data in your python application.

	The DynamicTemplateData is used to assign the key and value of the data, then NewPersonalizations is a subclass
	of the existing Personalizations to which the DynamicTemplateData can be added.

	This Gist takes inspiration from Sendgrid's Python SDK custom_args and CustomArgs.

	Hopefully, other finds this useful and Sendgrid updates their Python SDK soon
	"""

	#!/bin/bash

	echo 'update brew'

	brew update

	echo 'upgrade brew'

	brew upgrade