16th June 2023
Concurrency is best explained by an example stolen from Miguel Grinberg.
Chess master Judit Polgár hosts a chess exhibition in which she plays multiple amateur players. She has two ways of conducting the exhibition: synchronously and asynchronously.
- 24 opponents
- Judit makes each chess move in 5 seconds
- Opponents each take 55 seconds to make a move
- Games average 30 pair-moves (60 moves total)
Synchronous version: Judit plays one game at a time, never two at the same time, until the game is complete. Each game takes (55 + 5) * 30 == 1800 seconds, or 30 minutes. The entire exhibition takes 24 * 30 == 720 minutes, or 12 hours.
Asynchronous version: Judit moves from table to table, making one move at each table. She leaves the table and lets the opponent make their next move during the wait time. One move on all 24 games takes Judit 24 * 5 == 120 seconds, or 2 minutes. The entire exhibition is now cut down to 120 * 30 == 3600 seconds, or just 1 hour.
Async IO takes long waiting periods in which functions would otherwise be blocking and allows other functions to run during that downtime. (A function that blocks effectively forbids others from running from the time that it starts until the time that it returns.)
New: Basic concepts.
New: Introduce aiohttp.
aiohttpis an asynchronous HTTP Client/Server for asyncio and Python. Think of it as the
ADD ./path/to/directory /path/to/destination
Infrastructure as Code⚑
- name: Modify permissions command: > chmod -R g-w /home/user tags: - skip_ansible_lint sudo: yes
The quickest way to fetch or retrieve EC2 instance metadata from within a running EC2 instance is to log in and run the command:
Fetch metadata from IPv4:
curl -s http://169.254.169.254/latest/dynamic/instance-identity/document
You can also download the
ec2-metadatatool to get the info:
wget http://s3.amazonaws.com/ec2metadata/ec2-metadata chmod +x ec2-metadata ./ec2-metadata --all
New: Alertmanager routes.
A route block defines a node in a routing tree and its children. Its optional configuration parameters are inherited from its parent node if not set.
Every alert enters the routing tree at the configured top-level route, which must match all alerts (i.e. not have any configured matchers). It then traverses the child nodes. If continue is set to false, it stops after the first matching child. If continue is true on a matching node, the alert will continue matching against subsequent siblings. If an alert does not match any children of a node (no matching child nodes, or none exist), the alert is handled based on the configuration parameters of the current node.
A basic configuration would be:
route: group_by: [job, alertname, severity] group_wait: 30s group_interval: 5m repeat_interval: 12h receiver: 'email' routes: - match: alertname: Watchdog receiver: 'null'