Forem: CSJcode

Ultimate Caching Guide 3: Browser/Chrome

CSJcode — Tue, 07 Mar 2023 13:25:44 +0000

This article is focused on caching in Chrome Browser.

Most of the concepts in this article are applicable to other browsers.
Chrome is most used and documented so it is a good place to start.

Caching in Chrome is important for performance and reducing latency, bandwidth and memory. It's also useful for offline functionality.

Asset/page caching is a major part of Chrome's capabilities, but there are many others you may not know about.
There are surprising number of obscure ways to cache in Chrome ranging from IndexDB to cookies to Service Workers.
PWAs (Progressive Web Apps) are a good example of using Service Workers in Chrome for offline functionality.
Even other specialized applications like Google AMP (Accelerated Mobile Pages) utilize Chrome's caching capabilities.

Before getting into implementation in Chrome, let's look at the basics of HTTP caching and how you can monitor it in Chrome browser.

Ultimate Caching Guide Series

Ultimate Caching Guide 1: Overview and Strategies

Ultimate Caching Guide 2: Javascript/React

This is an ongoing series. I have at least 7 planned.

HTTP Caching and Monitoring Caches in Chrome

HTTP Caching

MDN docs

Some general background about the HTTP caching model, which is the foundation of the browser cache:

Heuristic caching: responses are reused if conditions are met.
- Although conditions may be made in the Cache-Control http response header, they are not always enforced. Included are directives like "max-age", "no-cache", "no-store", "must-revalidate", "public", "private" and more.
Common header heuristics:
- max-age: Specifies the maximum age of the resource in seconds. After this time, the resource should be considered stale and a new copy should be fetched from the server.
- no-cache: Instructs the cache to revalidate the resource with the server before using a cached copy.
- no-store: Instructs the cache to not store any copies of the resource at all.
- public: Specifies that the resource can be cached by any cache, including intermediate proxies.
- private: Specifies that the resource can only be cached by the user's browser and not by any intermediate proxies.
Other headers are used to control caching.
- Vary (properties of the request that can change the response).
- Validation based other factors such as last modified, ETags, forced revalidation.
Private cache:
- Private cache is a cache tied to a specific client, such as the browser.
Shared cache:
- Proxy (gateway) cache: a shared cache between clients and servers.
- Managed cache: CDNs, services deployed by developers to offload the origin server and to deliver content efficiently.
HTTP can use HTTP caching though is complicated by TLS/SSL extra security measures, which may prevent proper caching..

View Cache Data in Chrome

https://developer.chrome.com/docs/devtools/storage/cache/

Test if you optimized your page for instant loads when using the browser's back and forward buttons.
Identify issues that may prevent your page from being eligible for this type of caching
Back-Forward Cache
Also you can use Chrome console commands which you can dig around on to see what's going on with your cache and other settings: https://www.webnots.com/useful-chrome-url-commands/

Chrome DevTools

You can use the DevTools Network tab to monitor requests and responses and see caching information such as cache hits and misses.

Open Chrome Dev Tools with "Ctrl+Shift+I" (Windows, Linux) or "Cmd+Opt+I" (Mac), on the Application tab of you can see the Cache Storage.

Network Tab

Here you can see the cache status of each request.

You can also disable the cache, if you want to be sure you are not getting cached data.

You can open dev tools and right click the browser's reload button and select "Empty Cache and Hard Reload"

Lighthouse

Open Chrome Dev Tools with "Ctrl+Shift+I" (Windows, Linux) or "Cmd+Opt+I" (Mac) , on the Lighthouse tab of you can analyze your app and get cache -related feedback among other metrics.

Lighthouse is an open-source tool that can audit a website's performance, including caching. It provides suggestions for improving caching behavior.
Serve static assets with an efficient cache policy
Long Cache TTL

In Chrome browser url input: chrome://serviceworker-internals

This page provides information about registered service workers and their cache storage.

Other possible ways to checking Caching from the browser:

Google Analytics
- Google Analytics can be used to track cache hits and misses by setting up custom events and tracking them in the Analytics dashboard.
Chrome extensions:
- There are several Chrome extensions available that can provide more detailed information about caching, such as "Cache Killer" and "Clear Cache."
Command Line:
- You can use the Chrome command line to view detailed caching information, such as cache size and usage, by running the command "chrome://net-internals/#httpCache" or chrome://net-internals/#dns in the Chrome address bar. List of shortcuts

Types of Caching in Chrome

Memory Caching / HTTP (browser) Cache

Caching that temporarily stores and retrieves web page resources, such as HTML, CSS, JavaScript, and images, in memory for faster access.
The Page (browser) Cache may store in memory and/or disk depending on the assets.
Managed by the browser's networking layer
"Ctrl+Shift+I" (Windows, Linux) or "Cmd+Opt+I" (Mac) + NETWORK tab. Click on the "Network" tab.
Used along with other types of caches like disk and service worker caches.
When a user visits a website, the browser initiates a request to fetch the web page and its resources.
If the resource is not in the memory cache, the browser fetches the resource from the network and stores it in the cache for faster access in the future.
The cache uses a Least Recently Used (LRU) algorithm to determine which resources to evict from memory when the cache becomes full.
Faster than disk-based caches because it doesn't require the time to read and write data to disk.
Limited size (can be modified by the user) and can quickly fill up with frequently used resources.
Checks HTTP headers to control cache behavior. For example, the Cache-Control header can be used to set the maximum age of a resource in the cache.

Disk Caching / HTTP (browser) Cache

Website assets, such as HTML files, CSS stylesheets, JavaScript files, images, and other resources, and stores them in the disk cache.
When users revisit the site, the browser checks the disk cache to see if the assets are already stored there, and if so, it retrieves them from the cache instead of downloading them again.
Chrome Disk Cache works in conjunction with the Memory Cache.
The Chrome Disk Cache uses Least Recently Used (LRU) algorithm to determine which resources to evict from the cache when it becomes full.
HTTP headers are also used on this like the memory cache.
Devs could use LocalStorage for caching as well, and Session Storage may be either in memory or disk.
SessionStorage uses disk caching.
IndexDB and WebSQL are also disk based.

Page Cache

The difference of the Page cache and Browser cache is a bit confusing.

There are 2 different methods in the Chrome API under "chrome.browsingData" to clear each (remove and removeCache). Although the examples given don't specify much of the difference (in the code itself). Some I'm going to leave this section general for now, just noting the difference.

The Page Cache caches the entire rendered content of a web page, including its HTML, CSS, and JavaScript, as well as any data fetched by the page through APIs or other means.
The Page Cache is stored separately from the regular browser cache.
It's only used for pages that have been visited recently or frequently.

Back/forward cache

Back/forward cache differs from browser cache and HTTP cache.

Back-Forward Cache

The Back-Forward Cache is different from the regular browser cache in that it only stores pages that the user has visited during the current browsing session, and it is optimized for quick access to those pages.
It is also different from the Page Cache, which is used to cache pages that are opened from links in new tabs.
- https://developer.mozilla.org/en-US/docs/Web/API/Cache

Cookies

Cookies can be used to store data in the browser cache.
Cookies can be set to expire after a certain time, or when the browser is closed (session cookie).
The topic of cookies is covered in more detail here: Cookies article.

Service Worker Cache

Service workers intercept network requests and cache responses in the browser (see code below in Cache Storage API section).
They can be used offline or on a slow internet connection.
Steps to implementation:
- Register a Service Worker using the navigator.serviceWorker.register() method.
- Implement the caching logic in the fetch event listener of the Service Worker. With an event listener, you can intercept requests made by the browser and cache the responses.
- Use the Cache API provided by the Service Worker. The Cache API provides methods like cache.addAll() and cache.match() to add and retrieve responses from the cache.
- You can see Service Workers as listed aboe in the article in Chrome DevTools in the Application panel.
- Cache versioning and expiration should also be implemented to ensure that the cache is updated when the service worker is updated.

Web Workers

Web Workers operate independently of the main thread of the web page
They use a similar mechanism of caching as the page cache, however this can be customized by the developer.
Stored in memory cache or disk cache, depending on the size and type of data being cached.

Cache Storage API

The Cache Storage API is a newer API that allows developers to cache network resources programmatically. It provides more control over caching behavior and allows for more advanced caching strategies.

Caching of HTTP responses: Developers cache HTTP responses.
Support for different cache strategies.
Separation of caches: You can create multiple caches with different names, to keep different types of resources separate. For example, create a cache for images and another for scripts.
Management of cache entries: The API provides methods for adding, retrieving, and deleting cache entries. Developers can also set expiration times for entries or update them if the original resource has changed.
Programmatic caching: The API allows developers to cache resources programmatically, which can be useful for pre-caching resources that are likely to be needed in the future or for updating the cache in the background.

Example:

// Define the name of the cache
const CACHE_NAME = 'my-static-cache';

// Define the URLs of the files to cache
const urlsToCache = [
  '/',
  '/styles.css',
  '/script.js',
  '/images/logo.png'
];

// Install the service worker and cache the static assets
self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(cache => cache.addAll(urlsToCache))
  );
});

// Serve cached files if available, otherwise fetch them from the network
self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => {
        if (response) {
          return response;
        }
        return fetch(event.request);
      })
  );
});

Push Cache

Used for push notifications in Chrome. When a user receives a push notification, Chrome stores the resource in the push cache so that it can be quickly accessed if the user wants to view it.
Separate from the browser's regular cache and is only available for the lifetime of a single session.
The server sends the resources along with a PUSH_PROMISE frame to the client, which tells the browser to cache the resources in the Push Cache.
The browser then stores the resources in the Push Cache and can retrieve them without making a request to the server.
HTTP/2 Push is required to use the Push Cache.
Monitor the Push Cache using the Chrome DevTools in the Application tab and select Push Cache. You can also use the Performance panel to see the requests.

DNS Cache

Chrome stores recently resolved DNS queries in a cache to reduce the time it takes to resolve domain names.

DNS prefetching:
- By including the dns-prefetch link relation in your HTML code, you can instruct the browser to resolve DNS records for a domain in advance, before the user clicks on a link to that domain. This can help reduce latency and improve page load times.

<!DOCTYPE html>
<html>
<head>
  <title>My Website</title>
  <link rel="dns-prefetch" href="//example.com">
</head>
<body>
  <h1>Welcome to My Website</h1>
  <p>This is an example of how to use the dns-prefetch link tag.</p>
</body>
</html>

Add a dns-prefetch link tag to the head section of the HTML document.
The href attribute specifies the domain name we want to pre-resolve, in this case, example.com.
**preconnect: **This option allows the browser to set up an early connection to a domain before the user requests any resources from it. This can reduce the latency of establishing a new connection and improve page loading speed.

<link rel="preconnect" href="https://example.com">

prefetch: This option allows the browser to fetch and cache a resource in advance, before the user requests it. This can improve page loading speed by reducing the time it takes to fetch the resource when the user requests it. *

<link rel="prefetch" href="https://example.com/styles.css">

prerender: This option allows the browser to pre-render a web page in the background, before the user requests it. This can improve page loading speed by pre-rendering the page's HTML, CSS, and JavaScript, and making it available immediately when the user requests it.

<link rel="prerender" href="https://example.com/page.html">

See more on preconnect, prefetch, and prerender in the Link prefetching.

HTTPS and SSL/TLS certificates: When a user visits a website with a valid SSL/TLS certificate, Chrome will cache the certificate for a certain period of time. This helps to speed up subsequent visits to the same site, as the browser does not need to download the certificate again. However, if the certificate is invalid or has expired, Chrome will not cache it and will require a new certificate to be downloaded.

Font Cache

The Font Cache is a specialized cache used to store font data. It caches font files downloaded so that they can be reused across different web pages on the same site. This helps improve performance by reducing the number of requests needed to download font files.

Form Data Cache

Form data can be saved in local storage and autofilled.

Plugin caching

Chrome caches plugin content like Flash and Java to speed up the loading of multimedia content on web pages.

AMP

AMP (Accelerated Mobile Pages) is not specifically designed for caching, but it does use caching as a key component of its optimization strategy at several levels to speed up the delivery of content on mobile devices. Some of the caching is done by the browser, while other parts are done by the AMP Cache a global Google CDN.

AMP uses a service worker to cache the content on the user's device.
When a user visits an AMP page, the Chrome browser may display a lightning bolt icon in the address bar, indicating that the page is an AMP page and has been cached by the AMP Cache.

Other useful pages:

Ultimate Caching Guide 2: Javascript/React

CSJcode — Mon, 27 Feb 2023 04:12:57 +0000

This article is focused on caching in Javascript and React.

Most of the concepts in this article are applicable to other languages and frameworks.
Javascript is familiar to many and intertwined with the browser caching APIs, so it is a good place to start.
In this article, I am not going into too much detail on browser cache-related APIs and will leave that to a future article.

Also see:
Ultimate Caching Guide 1: Overview and Strategies

Javascript caching

Using caching techniques at the application level can improve performance and reduce the load on the server.

There are a number of caching methods available to Javascript developers to improve performance.

Closure caching

Returning a closure from a function that caches the result of a computation.

function calculateSum() {
  let cache = 0
  return function (num) {
    if (num === undefined) {
      return cache
    } else {
      cache += num
      return cache
    }
  }
}

const sum = calculateSum()
console.log(sum(2)) // Output: 2
console.log(sum(4)) // Output: 6
console.log(sum()) // Output: 6 (cached value)
console.log(sum(5)) // Output: 11
console.log(sum()) // Output: 11 (cached value)

Data Structure Caching

Similar caching can be done with various data structures, such as arrays, objects, Maps, Sets, etc.

Basic object cache, usually placed inside a function:

const cache = {}

function getFromCache(key) {
  return cache[key]
}

function addToCache(key, value) {
  cache[key] = value
}

const complexCalculation = (a, b, c) =>
  Math.sqrt(Math.pow(a, 2) + Math.pow(b, 2) + Math.pow(c, 2)) /
  (Math.pow(Math.E, a) + Math.pow(Math.E, b) + Math.pow(Math.E, c))

addToCache('mathResult', complexCalculation(1, 2, 3))
console.log(getFromCache('mathResult')) // Output: '0.12392517788687459'

Set:

const cache = new Set()

function cachedData(data) {
  if (cache.has(data)) {
    console.log('Data is cached')
    return data
  }

  fetchData(data)
  cache.add(data)

  return data
}

// fetchData(data)
function fetchData(data) {
  return data
}

const data = { "a": 1, "b": 2 };
const result1 = cachedData(data)
console.log(result1) 
const result2 = cachedData(data)
console.log(result2)

Memoization

Object caching is focused on the data structures used by a program, while memoization is focused on the results of a function.

function memoize(fn) {
  const cache = {}
  return function (...args) {
    const key = JSON.stringify(args)
    if (cache[key]) {
      console.log('Returning from cache...')
      return cache[key]
    }
    const result = fn.apply(this, args)
    cache[key] = result
    return result
  }
}

function expensiveComputation(x, y) {
  console.log('Performing expensive computation...')
  return x + y
}

const memoizedComputation = memoize(expensiveComputation)

console.log(memoizedComputation(2, 3)) // Performing expensive computation... 5
console.log(memoizedComputation(2, 3)) // 5 (returned from cache)

Memory-based Storage API (eg. SessionStorage)

It's simple and straightforward to use the Storage API to cache data in the browser.

SessionStorage and LocalStorage are similar in terms of functionality, but LocalStorage persists data across browser sessions.

there is a separate sessionStorage for each tab or window.
When the tab or window is closed, the web browser ends the session and clears sessionStorage.
it's specific to the protocol of the page.

// Store data in SessionStorage
sessionStorage.setItem('myData', JSON.stringify({ foo: 'bar' }));

// Retrieve data from SessionStorage
const data = JSON.parse(sessionStorage.getItem('myData'));

Disk-based (LocalStorage, IndexDB)

LocalStorage is a key-value store persisting data across browser sessions.

https://developer.mozilla.org/en-US/docs/Web/API/Storage

IndexDB is a more complex API for storing data in the browser and allows more complex querying and indexing of structured data. It can store data in different formats, including binary data, and provides asynchronous APIs for better performance. IndexedDB is asynchronous, while LocalStorage is synchronous.

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API

SessionStorage is cleared when the browser is closed. LocalStorage is cleared when the user clears their browser cache.

const cacheKey = 'myData';
let cachedData = JSON.parse(localStorage.getItem(cacheKey));

if (!cachedData) {
  // Data is not in cache, fetch it from the server
  fetch('/my/data').then(response => {
    // Cache the response data
    response.json().then(data => {
      localStorage.setItem(cacheKey, JSON.stringify(data));
    });
  });
} else {
  // Use cached data
  console.log('Using cached data:', cachedData);
}

WebWorker

WebWorkers can be used for background caching and to store data in memory, basically non-blocking interaction with the app's main thread with 'postMessage'. Also it can be used for offline functionality.

// Listen for requests from the main thread
self.addEventListener('message', event => {
  const { url, cacheKey } = event.data;

  // Check if the data is cached in localStorage
  const cachedData = localStorage.getItem(cacheKey);
  if (cachedData) {
    // If cached data is found, send the data back to the main thread
    self.postMessage(JSON.parse(cachedData));
  } else {
    // If cached data is not found, fetch the data from the API
    fetch(url)
      .then(response => response.json())
      .then(data => {
        // Store the fetched data in localStorage for future use
        localStorage.setItem(cacheKey, JSON.stringify(data));
        // Send the fetched data back to the main thread
        self.postMessage(data);
      })
      .catch(error => {
        // If an error occurs, send an error message back to the main thread
        self.postMessage({ error: error.message });
      });
  }
});

Service Worker

Network Only, Network first, then cache, Stale-While-Revalidate, Cache First,fall back to network, Cache Only

The Service Worker is a bit more versatile than the WebWorker and will cache the specified files when it is installed, and intercept fetch requests to return cached responses if available. It will also clean up old caches when the new version of the Service Worker is activated.

You can think of it like a local reverse proxy server that intercepts requests and returns cached responses if available.

// Install the Service Worker and cache some files
self.addEventListener('install', event => {
  event.waitUntil(
    caches.open('my-cache').then(cache => {
      return cache.addAll([
        '/',
        '/index.html',
        '/styles.css',
        '/script.js',
        '/image.png'
      ]);
    })
  );
});

// Intercept fetch requests and return cached responses if available
self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request).then(response => {
      return response || fetch(event.request);
    })
  );
});

// Clean up old caches when activating the new version of the Service Worker
self.addEventListener('activate', event => {
  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames.filter(cacheName => {
          return cacheName !== 'my-cache';
        }).map(cacheName => {
          return caches.delete(cacheName);
        })
      );
    })
  );
});

Libraries

lru-cache

https://www.npmjs.com/package/lru-cache

provides a caching mechanism with a least recently used (LRU) eviction policy.
The LRU policy means that when the cache reaches its maximum size, the least recently used items are removed from the cache to make room for new items.
Optimize memory usage and performance by ensuring that the most frequently accessed items remain in the cache, while less frequently accessed items are evicted.

node-cache-manager

https://www.npmjs.com/package/cache-manager

React (other SPAs have similar options)

Memoization

React provides a built-in utility called React.memo() that can be used to memoize functional components. However, modern usage of React Hooks makes it easier and is the common usage.
useMemo
useCallback

A code example is below:

The two hooks are similar, but they have different use cases. useMemo is used to memoize the result of a function, while useCallback is used to memoize the function itself.

useMemo is used to memoize the result of the calculateSum function.
useCallback is used to memoize the calculateSum function. The calculateSum function will only be re-created if one of these values changes.

By using useCallback and useMemo, we're able to optimize our code and avoid unnecessary re-renders.

import React, { useState, useMemo, useCallback } from 'react';

function App() {
  const [num1, setNum1] = useState(0);
  const [num2, setNum2] = useState(0);

  const calculateSum = useCallback(() => {
    console.log("Calculating sum...");
    return num1 + num2;
  }, [num1, num2]);

  const sum = useMemo(() => calculateSum(), [calculateSum]);

  return (
    <div>
      <h1>Sum: {sum}</h1>
      <input type="number" value={num1} onChange={(e) => setNum1(parseInt(e.target.value))} />
      <input type="number" value={num2} onChange={(e) => setNum2(parseInt(e.target.value))} />
    </div>
  );
}

export default App;

Query caching

Another important React caching technique is query caching. Query caching is used to store the results of a query so that the query doesn't have to be executed again if the same query is made. This can be useful for reducing the number of API requests made to a server.

Most popular libraries have their own query caching mechanism.

This chart shows some of the varieties available:
https://redux-toolkit.js.org/rtk-query/comparison

Caching in Apollo Client
- https://www.apollographql.com/docs/react/caching/overview/
TanStack Query/React Query QueryCache
- https://tanstack.com/query/latest
- https://react-query-v3.tanstack.com/reference/QueryCache
RTK Query - Redux Toolkit
- https://redux-toolkit.js.org/rtk-query/usage/cache-behavior
SWR - React Hooks for Data Fetching
- https://swr.vercel.app/

PureComponent (deprecated, but still in some codebases)

PureComponent is a subclass of the React.Component that implements a shallow comparison of props and state to determine if a re-render is necessary. This can improve performance by preventing unnecessary re-renders.

https://beta.reactjs.org/reference/react/PureComponent

React.lazy() and Suspense

React.lazy() is a newer feature introduced in React 16.6 that allows for lazy loading of components. Suspense is a component that allows you to handle loading states and fallbacks.

It's mainly use for code-splitting, but could facilitate caching since it dynamically loads components of code and stores in memory to be re-used in other components.

Context API

The Context API provides a way to pass data through the component tree without having to pass props down manually at every level.

By using context, we are effectively caching props and can avoid unnecessary re-renders and improve performance.

import React, { useContext } from 'react';

// Define a context with a default value
const MyContext = React.createContext('default value');

// A component that uses the context
function MyComponent() {
  // Get the value of the context using useContext hook
  const contextValue = useContext(MyContext);

  return (
    <div>
      <p>Context value: {contextValue}</p>
    </div>
  );
}

// A parent component that provides the context value
function App() {
  return (
    <MyContext.Provider value="hello world">
      <MyComponent />
    </MyContext.Provider>
  );
}

Next.js and Server-side rendering

Server-side rendering is the process of rendering the initial HTML and React components on the server before sending it to the client. This can improve performance by reducing the time it takes for the client to receive and render the content.

Next.js provides several built-in caching mechanisms that allow pages to be cached in memory or on disk, reducing the need to re-render pages for subsequent requests.

Static file caching: there are static files for each page served directly from disk for subsequent requests. These files are cached in memory by default, and can also be cached by a reverse proxy server or CDN.
Incremental Static Regeneration (ISR): Next.js supports a feature called ISR, which allows pages to be revalidated and regenerated incrementally at a specified interval or on demand.
- https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration
Server-side rendering (SSR) caching: Next.js provides an API for caching the output of server-side rendering (SSR) for a given request. Cache-control headers can be used to control how long the cached output is valid for.
- https://nextjs.org/docs/api-reference/next.config.js/headers#cache-control
Memory caching: Next.js provides an in-memory cache that can be used to store arbitrary data, such as database queries or API responses.
ETags: Next.js supports the use of HTTP ETags to cache responses from the server.
- https://nextjs.org/docs/api-reference/next.config.js/disabling-etag-generation
Minimum Cache TTL
- https://nextjs.org/docs/api-reference/next/image#minimum-cache-ttl

Memoized selectors

Redux is a popular state management library used with React.

Memoized selectors are functions that compute derived data from the Redux store (stored state data in memory).

Redux and RTK provide built-in support for memoized selectors through the reselect library - https://github.com/reduxjs/reselect

By memoizing these functions, you can avoid re-computing the same data over and over again.

This is basically extending memoization to the Redux framework and state management data structures.

We've looked at how caching can be used at the application level in Javascript and React to improve performance.

There are quite a few choices to make when it comes to caching, and it's important to understand the tradeoffs and use cases for each.

Some like useMemo and useCallback are used to optimize the performance of React components.

Others like Apollo Client and React Query are used to cache API requests and reduce the number of requests made to a server.

While some like Next.js and SSR are used to cache the output of server-side rendering.

Also, in the first article in this series we already examined some of the main caching patterns which can be applied across all types of services.

Next article we'll continue to trace our caching options through the cloud and into large-scale distributed systems.

Also see:
Ultimate Caching Guide 1: Overview and Strategies

and

150+ Solutions Architect metrics/calculations cheatsheet

Ultimate Caching Guide 1: Overview and Strategies

CSJcode — Mon, 27 Feb 2023 03:08:15 +0000

Caching is a technique in the Dev toolbox that can work some "magic" to resolve scalability challenges.

Caching: storing frequently accessed or computationally expensive data in a temporary storage area, often closer in space/time to the requester.

A software or hardware component that does this is a cache and there are local or remote methods to accomplish this.

Potential app benefits from caching:
- better performance,
- better reliability,
- less resources required,
- less resources may reduce cost/complexity,
- decreasing latency and user-perceived lag,
- increasing resilience/uptime,
- extending existing capabilities,
- improving usability.

This article is a high-level introduction.

In future articles we will explore implementation in great detail from pure Javascript code to React to CDNs, microservices, APIs and databases.

Why is caching important?

What are some major caching patterns we should know about?

🛠 Implementation

Implementation of caching is interesting for a few reasons...

Ubiquitous.
- We have many areas of the application ecosystem to implement it.
- Multiply performance optimizations, from the client to CDN, database, and/or servers. Opportunities are abundant.
Fast Results. Easy benefits which can extend existing capabilities at low cost.
- Basic caching can be achieved without much difficulty.
- A simple approach can yield quick results and save a lot of money!
Reliability.
- Caching can potentially prevent users knowing about a service or website outage.
- We can mitigate the impact of a service outage by serving cached content.
Overcome geographic and offline obstacles.
- Caching can help with reliability and usability in a variety of geographic and low/no-connectivity challenges.
Increase performance knowledge of the app.
- Exploring caching techniques helps us better understand the apps' limitations, and areas for optimization throughout the entire system.

Sound great?

Almost.... because caching is not perfect for all cases.

❌ Risks

Possible downsides:

Complexity. May increase app complexity, especially when used a lot.
Debugging. A lot of of caching can lead to a lot of difficult debugging! (been there, done that!)
Data consistency and usability may be harmed if implemented incorrectly. Users may not be served the correct data/images
Security. Storing data remotely for example could result in security risk in some cases, such as with PII (Personally Identifiable Information).
Unnecessary? In some cases it simply may be unnecessary to implement.

💡 Considerations

Considerations:

Is your app making expensive/complex calculations or stalling from compute bottlenecks?
- If so, it may help to refactor code with caching for lower memory usage, read/writes and CPU cycles.
What is the response time of your application?
- If the response time is slow, caching may help improve performance.
Is it serving the same content to many users?
- If so, caching can help reduce the number of requests to the server and improve response times.
Do you have a large amount of static content on your website or app?
- Caching can help reduce the data over the network, improving performance.
Are there limited or unstable network resources?
- Caching can help reduce the amount of data that needs to be sent over the network, conserving bandwidth and reducing costs.
Do you have a high volume of concurrent users accessing your application
- It can help improve performance and reduce server load.
Is your application frequently requesting data from external sources?
- Caching can help reduce the load on external servers and improve response times.

Caching is used universally and a critical part of popular apps, despite potential drawbacks.

Caching Strategies

Basic caching patterns are implemented across different services, technologies and languages. One of the reason we look at this in the intro is because it is applicable throughout the series.

The caching strategy can optimize how effective it is for your use-case.

Locality

Local cache

Cache is stored with the app, such as in memory in the client browser, or app server.

Remote cache

Cache is stored as a remote independent service, such as CDN.

note:

Some of the info below can get a bit tricky. And even some sources use slightly different terminology!
The main thing is that you need to understand the trade-offs and the potential impact on your app.

For example, Write-Through will better ensure data consistency but will have higher latency (slightly slower). Write-Back will have lower latency (faster) but may have more issues with data inconsistency.

Cache-Aside

Among the most common caching strategies, aka "lazy loading".
Fetch data from the cache when it's available, and if it's not, fetch it from the backend.
Then the client would add it to the cache for future use.
Cache and database are independent and don't communicate with each other.
Cache hit: Read from the cache. Cache miss: read from the backend store.
Best for low write-to-read ratios. (more for heavy reads)

Cache-Aside with Read-Through

Similar to above but with a slight difference - the cache or a 3rd-party library may communicate with the backend store to fetch data when it's not available in the cache. The client does not do this.
Cache hit/miss same as above, write to cache.
Good for high read-to-write ratios.

Write-Through (SYNCHRONOUS Write)

Writes data to the cache and to the backend store SYNCHRONOUSLY.
Also, the backend store can load new data (independently of the cache) and then the cache can be updated with the new data.
The main point here is that the cache is populated only AFTER the new write data is in the backend store.
Used for better data consistency on the backend. Higher latency for writes.

Write-Back (Write Behind, ASYNCHRONOUS Write)

Write data to the cache first and ASYNCHRONOUSLY write to the backend store.
The main difference with Write-Through is that the cache is updated first, returns a response, and in the background then the backend store is updated separately. This does create a risk of data inconsistency but returns a response to the user faster.
Faster due to lower latency, but more risk of data inconsistency.

Cache-Aside with Write-Back

Write data to the cache first and then asynchronously write it to the backend.
High write-to-read ratios and requires data consistency between the cache and the backend.

Write allocate

Data at the missed-write location is put into cache, followed by a write-hit operation.

Write around (No-Write allocate)

Data at the missed-write location is not loaded to cache, and is written directly to the backing store. Data is loaded into the cache on read misses only.

Refresh Cache

The cache is periodically refreshed ("invalidated") with data from the backing store to ensure that the data in the cache is up-to-date.
Good if data in the backing store changes frequently, but it can also introduce some latency in read operations.

Cache-Aside with Refresh-Ahead

The Cache-Aside with Refresh-Ahead pattern is a caching strategy that involves pre-fetch data into the cache before it's requested.
Good for applications that have predictable access patterns.

Caching with Replicas

Implementing caching and replicating multiple nodes of the cache store for increased availability.
Used with cache managers like Redis.

Cache-pinning

Keeping frequently accessed data in the cache, even if it is not being used.
Used to reduce the frequency of cache misses and improve cache hit rates.
Good for applications that have a small number of frequently accessed data items.

Time-to-live (TTL)

Setting an expiration time for cached data, after which the data is invalidated and must be retrieved from the backend store.
Ensure that cached data does not become stale and to free up space in the cache.
Useful for applications that have data with a short lifespan, such as news or weather data.

Invalidating the Cache

Invalidating the cache whenever the data in the underlying data source changes. For example, if you're caching data from a database, you could invalidate the cache whenever a record is updated or deleted. This ensures that the cache always contains up-to-date data.

These are the primary strategies, although there are others that may be used in special cases.

Also different caching services and software may implement additional performance enhancement - we'll check that out later.

We've looked at why caching is useful, and some downsides. Also, some considerations for deciding what and how too implement.

Also, we examined some of the main caching patterns which can be applied across all types of services.

Next article we'll start examining caching from the application/client and trace it through the cloud and into large-scale distributed systems.

If you liked this article check out my previous article on:

150+ Solutions Architect Metrics

References:

150+ Solutions Architect metrics/calculations cheatsheet

CSJcode — Thu, 23 Feb 2023 01:00:46 +0000

150+ Solutions Architect metrics and calculations for systems design, technology comparisons, planning and projects. btw, If there is interest, I'll make this into tables, I made a few but haven't had time to do it all yet.

Categories: User, Network, Reliability, Compute, Storage, Database, Queues/Events, Security, Cost.

Thanks for checking it out... if you have ideas for improvements, feel free to comment or make a PR on my github repo: https://github.com/csjcode/solutions-architect-metrics-cheatsheet

⭐️ User

Daily Active Users (DAU)
- Unique active users / day
- Performance and capacity needs, daily, projections.
Monthly Active Users (MAU)
- Unique active users / month
- Performance and capacity over longer time periods, projections.
Concurrent Users, Avg/Max
- Number of users at same time, average and peaks
- Reliability, server capacity, quotas, service bottlenecks
Actions Per User (APU): Average actions per user
- Actions performed by all unique users / by the number of unique users.
- Performance, bandwidth, concurrency, cost optimization for high/low microservices.
Actions Per User delta (APU Δ)
- Change in actions per user over a given time period
- Speed of scalability, concurrency, performance.
Daily User Actions (DUA)
- Total actions performed by all users in a day.
- System load, performance, cost and capacity growth needs.
Requests Per Second (RPS)
- Service requests per second
- Reliability in high traffic, quotas, performance.
User Delta
- Change in the number of users over a given time period
- Speed of scalability, capacity planning, concurrency, performance, cost..
Session length
- Average duration of user session
- Server resources, cost, performance, concurrency planning.

⭐️ Network

CIDR/Subnet Calculation
- IP address and network mask calculation,
- Number of IPs = 2³²-2^prefix
- 10.0.0.0/24 = 2³²-2²⁴ = 2⁸ = 256
- For network sizing and planning
Bandwidth Consumed/Utilization
- (Bandwidth used / Total available bandwidth) x 100%
- Network resource usage, potential bottlenecks, cost, quotas, performance
Available Bandwidth
- Total available bandwidth - bandwidth used.
- Cost, performance, quotas, adequate resources for network traffic and avoiding slowdowns.
Data Transmission Rate
- Amount of data transferred / time taken
- Data transfer speed and network efficiency.
Link Capacity
- Maximum bandwidth capacity of a link.
- Reliability - determines maximum bandwidth available for a link to ensure it can handle traffic.
Network Throughput
- (Amount of data transferred / Total time) x 100%
- Performance, operations, network efficiency and data transfer speed.
Network Latency
- Delay between sending and receiving data. Round-trip time (RTT)
- Performance, delay in data transfer and network responsiveness.
Network I/O
- Input/output rate of network data.
- Warning of network bottlenecks, performance, cost.
Request Error rate
- Percentage of failed requests, (Number of failed requests / Total requests) x 100%
- Identifies issues in the network or application that need to be addressed.
Packet Loss Rate
- Percentage of lost packets.
- Identifies potential vulnerabilities or issues in the network or application.
HTTP response codes
- Partial list, see full list
- 1xx info, processing
- 2xx successful: 200 OK
- 3xx redirection: 301 Moved Permanently, 302 Found, 304 Not Modified
- 4xx client error: 400 Bad Request (parameters missing?), 401 Unauthorized (API token missing?), 403 Forbidden (permissions?), 404 Not Found (url incorrect?), 405 Method Not Allowed (eg. POST not accepted on resource), 429 Too Many Requests (exceeded rate limits?), 499 Client Closed Request
- 5xx server errors: 500 Internal Server Error, 501 Not Implemented, 502 Bad Gateway, 503 Service Unavailable (overload?), 504 Gateway Timeout (upstream timeout?)
HTTP Header Fields
- List of standard headers

⭐️ Reliability

Recovery Time Objective (RTO)
- Maximum time window delay within which a service must be restored after a disaster.
Recovery Point Objective (RPO)
- Maximum amount of time before unacceptable amounts of data have been lost due to a disaster, failure, or comparable event
Single Point of Failure (SPOF)
- Component that can cause system failure.
- 1 - (redundant components/total components).
Cloud Services Quotas
- Limits on usage of cloud services.
- Possible SPOF, if quota reached, service unavailable/degraded.
Availability (% of time)
- proportion of time a system is operational
- uptime / (uptime + downtime)
Availability (% of requests)
- proportion of time a system is operational
- successful requests / (valid requests)
Availability in 9s ("nines")
- Percentage of uptime in a year.
- (total time - downtime) / total time
Maximum Availability with Dependencies
- Maximum Availability estimate for multiple services in a distributed system.
- Availability of Service 1 * Availability of Service 2 * ... Availability of Service n
- MTBF / MTBF + MTTR
Maximum Availability with redundant components
- Maximum Availability estimate with duplicated components (higher reliability)
- A = 1-F ≈ 1-f(1-a)^s+1
- where s = spare components, F= failure modes, a= availability (in %)
- ex: 99.5% availability, with two spares the workload’s availability is A ≈ 1 − (1)(1−.995)3 = 99.9999875% availability
Mean Time to Failure (MTTF)
- Average time until a component fails.
- total uptime / number of any failures.
Mean Time Between Critical Failures (MTBCF)
- total uptime / number of critical failures.
Mean Time to Data Loss (MTTDL)
- Average time before data loss.
- MTTDL = (1 - Annualized Rate of Data Loss) / Annualized Rate of Data Loss
- Annualized Rate of Data Loss = (Total Data Stored) x (Data Loss Rate)
Recovery Time (RT)
- TTR + MTTD + MTTI + MTTRM, where TTR is Time to Respond.
Mean Recovery Time (MRT)
- Average time it takes to recover from a failure.
- MRT = ∑RT / Number of incidents
Mean Time to Detect (MTTD)
- Average time it takes to detect a failure.
- MTTD = ∑time taken to detect incidents / Number of incidents.
Mean Time to Identify (MTTI)
- Average time it takes to identify a failure.
- MTTI = ∑time taken to identify incidents / Number of incidents.
Mean Time to Remediate (MTTRM)
- Average time it takes to fix a failure.
- ∑time taken to remediate incidents / Number of incidents.
Mean Time to Resolve (MTTR)
- Average time it takes to resolve a failure.
- MTTR = ∑time taken to resolve incidents / Number of incidents. Mean Time to Respond (MTTR)
- Average time it takes to respond to a failure.
- MTTR = ∑time taken to respond to incidents / Number of incidents.
Change Failure Rate (CFR)
- Rate at which changes introduce failures.
- CFR = Number of failed changes / Number of changes attempted.
Defect Escape Rate
- Rate at which defects escape detection.
- DER = Number of defects found after release / Total number of defects.
Defect Density
- Number of defects per unit of code.
- Number of defects / Size of the software.
Failure Rate
- Rate at which components fail.
- Number of failures / Unit of time
Service restoration time
- Time taken to restore a failed system.
Redundancy
- (Number of redundant (backup) components / Total number of components) x 100%
Resiliency
- Ability to recover from a failure.
- Availability x Reliability x Maintainability x Recoverability
- Availability (% time), reliability (probability of working service), maintainability, and recoverability (MTTR)

⭐️ Compute

Many of the following metrics are available in analytics services of the cloud provider tools such as AWS Cloudwatch or service dashboards. Metrics are included here for awareness and a reminder when evaluating Compute resources.

CPU utilization
- CPU usage rate. Monitor performance & efficiency. Optimize performance.
- Total CPU time / Elapsed time
Disk I/O
- Disk input/output. Measure read/write speeds for the Compute device. Optimize throughput.
- Total bytes read/written / Elapsed time
Network I/O
- Network input/output. Measure bandwidth usage on the Compute device. Optimize connectivity.
- Total bytes sent/received / Elapsed time
IOPS
- Input/Output operations/second. Assess data access performance. Optimize throughput.
- Total operations / Elapsed time
Memory utilization
- RAM usage rate. Assess RAM usage for performance.
- Total RAM usage / Total RAM available
Caching
- Data storage/retrieval. Improve data performance.
- Hits / Misses
Cost
- Expense management. Estimate resource expenses.
- Actual cost/Estimated cost
Container density
- Resource utilization. Optimize resource use.
- Used resources / Total resources
Function duration vs. limits
- Execution time. Gauge execution time.
- Analytics or Start time - End time vs. quota
Function concurrency
- Simultaneous operations. Measure concurrency.
- Analytics or Number of operations per lambda / Elapsed time
Function response time
- Execution time. Evaluate speed. Gauge execution time.

⭐️ Load Balancing

Load Balancing Algorithm
- Algorithm used by the load balancer to distribute traffic
- Round Robin, Least Connections, Weighted Round Robin, Weighted Least Connections, Dynamic Least Connections, Source IP Hash, Least Time, Least Packets, Agent-Based Load Balancing, URL Hash, Server Affinity (Sticky Sessions)
Request Success Rate
- Number of successful requests/Total number of requests
Latency
- Time taken to serve a request
Error Rate
- Number of failed requests/Total number of requests
Connection Count
- Number of connections between clients and servers
Active Connections
- Number of active connections between clients and servers
Backend Server Health
- Availability and response time of backend servers
SSL Handshake Time
- Time taken to establish a secure connection
Connection Rebalancing Time
- Time taken to rebalance connections across servers

⭐️ Autoscaling

Scaling metric
- A metric that determines when autoscaling should occur, such as CPU utilization or request count
Scaling policy
- A set of rules that define how autoscaling should occur, such as increasing or decreasing the number of instances based on the scaling metric
- Target Tracking Scaling
- Adjusts capacity based on target metrics.
- Step Scaling
- Adds or removes capacity based on specific thresholds.
- Simple Scaling
- Adds or removes capacity based on logging or cloudwatch alarms.
- Scheduled Scaling
- Changes capacity at specific times or dates.
- Predictive Scaling
- Uses ML to forecast demand and adjust capacity.
- Dynamic Scaling
- Resizes based on changing demand and traffic patterns.
- Capacity Optimized Scaling
- Provisions instances for optimal cost and performance.
Scale-out threshold
- The threshold value for the scaling metric that triggers scaling out (adding instances)
Scale-in threshold
- The threshold value for the scaling metric that triggers scaling in (removing instances)
Cool-down period
- The period of time after scaling has occurred during which autoscaling is suspended to prevent rapid scaling up and down

⭐️ Elasticity

Resource utilization
- The percentage of available resources (such as CPU or memory) that are currently in use
Capacity planning
- The process of estimating future resource needs based on historical usage patterns and growth projections
Time to Scale
- The time it takes to add or remove resources to meet demand changes
Cost Optimization
- The process of minimizing costs while maintaining the necessary level of elasticity and performance.

⭐️ Database

Throughput
- The amount of data transferred per unit of time
- Data transferred / time
Latency
- The time it takes to process a request
- Time to first byte + time to last byte
Response time
- The time it takes to respond to a request
- Time to last byte - time to first byte
Concurrency
- The number of simultaneous users or connections
- Simultaneous requests / time
Read-to-Write Ratio
- The ratio of read requests to write requests
- Read requests / write requests
Cache Hit Rate
- The percentage of data that is retrieved from cache
- cache hit rate = cache hits / (cache hits + cache misses)
Database Connections
- The number of active database connections
- Measured using database monitoring tools.
Query performance
- Time to execute a database query
- Execution time = end time - start time
Index usage
- How frequently an index is used to retrieve data
- Index usage = (number of times index is used) / (total number of queries)
Lock waits
- Time spent waiting for a locked database object
- Lock wait time = total time spent waiting for a lock
Deadlocks
- Occurrences of simultaneous locking conflicts in transactions
- Deadlocks = number of occurrences of simultaneous locking conflicts
Data consistency
- Degree of uniformity and accuracy in data across systems
- Data consistency = (number of errors detected / total number of checks) * 100
Backup and Recovery
- Time taken to backup and recover data in case of failure
- Time taken to backup or recover / number of backups or recoveries
Database Size and Growth
- Total size of the database and its growth rate
- Current size of database + (growth rate * time interval)
CAP Theorum
- Pick two of the following three properties:
- Consistency: Each read request receives the most recent write or an error when consistency can’t be guaranteed.
- Availability: Each request receives a non-error response, even when nodes are down or unavailable.
- Partition tolerance: The system operates despite the loss of messages between nodes.
ACID
- Atomicity: All or nothing. Either all operations succeed or all operations fail.
- Consistency: Data is consistent before and after the transaction.
- Isolation: Transactions are isolated from each other.
- Durability: Once a transaction has been committed, it will remain so, even in the event of power loss or system crash.
BASE
- Basically Available
- Soft state (may be inconsistent for brief periods)
- Eventually consistent

⭐️ Storage

General Storage metrics

Applies to most storage mediums, including block, file, and object storage.

Data Durability
- Probability of data remaining intact over time
- (1 - Annual Failure Rate) ^ Years
Latency
- Time for data to be accessed
- Total time to read or write data
Replication Latency
- Time for replica data to be transferred or accessed
- Total time to read or write data after transfer
IOPS (Input/Output Operations Per Second)
- Number of read/write operations per second
- Total number of operations / time interval
Throughput
- Amount of data transferred per unit of time
- Total data transferred / time interval
Maximum Throughput
- Amount of data transferred per unit of time
- Total data transferred / time interval

Object storage

Object Storage Utilization
- Amount of object storage used versus total available object storage
- Used object storage / Total object storage
Object Storage Tier Data Stored
- Length of time objects are stored in a tier before being transfered/deleted
- Object transfer or deletion execution duration by tier
Object Storage API/request Calls
- API requests made to object storage service
- API requests / Time interval
- PUT, COPY, POST, LIST requests (pricing may be different)
- GET, SELECT, and all other requests
- Lifecycle Transition requests
- Data Retrieval requests
Object Storage Latency
- Time taken for object storage service to process a request
- Total time for requests / Number of requests
Data Transfer per time interval
- Total amount of data transferred
- Data Transferred (in bytes) / time interval
Object Storage Retention
- Length of time objects are stored before being deleted
- Object transfer or deletion execution duration
Geographic Put/Get requests
- Latency of Put/Get requests
- Latency (in milliseconds) / time interval
Availability metrics
- Number of requests that fail
- Requests that fail / total number of requests
Data Consistency metrics
- Number of objects that are successfully stored/retrieved
- Number of objects successfully stored/retrieved / time interval
Bandwidth used in/out total, timeframe, region, internet, inside cloud provider
- Amount of data transferred in/out of object storage
- Data transferred in/out / time interval
- There may be different policies per cloud provider.

Disk storage

Disk Utilization
- Amount of disk space used versus total available disk space
- Used disk space / Total disk space
Disk IOPS
- Number of read and write requests to a disk in a second
- Number of requests / Time interval
Disk Latency
- Time taken for a disk to process a read/write request
- Total time for read/write requests / Number of requests
Data Replication Latency
- Time taken to replicate data from one location to another
- Time for replication completion - Time of data creation
Data Replication Bandwidth
- Amount of data replicated per second
- Amount of data / Time interval
SSD Endurance
- Amount of data that can be written to an SSD before failure
- Total bytes written / (Drive size in GB * Drive endurance)
Disk Utilization
- Percentage of disk space used
- (Amount of space used / Total amount of space) x 100
RAID Reliability
- Probability that the RAID will remain operational
- (1 - Probability of failure) ^ Number of disks
Storage Capacity
- Total amount of storage space available
- Amount of space used + amount of space available
Block Storage IOPS
- Number of read and write requests to a block storage device in a second
- Number of requests / Time interval
Block Storage Latency
- Time taken for a block storage device to process a read/write request
- Total time for read/write requests / Number of requests
Types of RAIDS

RAID Level	Description
RAID 0	Data is striped across multiple disks for increased performance, but offers no redundancy.
RAID 1	Data is mirrored across two disks for fault tolerance, but offers no performance improvement.
RAID 5	Data is striped across multiple disks with parity information stored on each disk for fault tolerance.
RAID 6	Similar to RAID 5, but with two sets of parity information for even greater fault tolerance.
RAID 10	A combination of RAID 1 and RAID 0, where data is mirrored and striped for both performance and fault tolerance.
RAID 50	A combination of RAID 5 and RAID 0, where data is striped across multiple RAID 5 arrays for increased performance and fault tolerance.
RAID 60	A combination of RAID 6 and RAID 0, where data is striped across multiple RAID 6 arrays for even greater performance and fault tolerance.

⭐️ Queues/Events

Queue Depth
- Number of events in a queue waiting to be processed.
- Total events - Processed events
Queue Wait Time
- Amount of time an event spends waiting in a queue before being processed.
- Total time events spend in queue / Number of events in queue
Event Arrival Rate
- Rate at which events are arriving at a queue.
- Number of events arriving / Time interval
Event Processing Time
- Amount of time it takes to process an event.
- Total time spent processing events / Number of events processed
Event Processing Rate
- Rate at which events are being processed.
- Number of events processed / Time interval
Queue Processing Rate
- Rate at which events are being processed from a queue.
- Number of events processed from queue / Time interval
Queue Time
- Total time that events spend in a queue, including both wait time and processing time.
- Queue Wait Time + Event Processing Time
Queue Throughput
- The rate at which events are moving through a queue, including both incoming and outgoing events.
- Incoming Event Rate + Outgoing Event Rate
Event Drop Rate
- the rate at which events are being dropped or lost, typically due to queue overflow.
- Number of dropped events / Total number of events
Queue Latency
- the time it takes for an event to travel through a queue, including both wait time and pr**ocessing time.
- Queue Time / Number of events

⭐️ Security

Network Security Score: a metric that measures the security posture of a network, including factors such as the number of vulnerabilities, exposure to threats, and compliance with security standards.
Incident Response Time
- The amount of time it takes to respond to a security incident
- Detection Time + Response Time + Mitigation Time
- Time Detected - Time Reported
Risk Assessment Score
- A numerical score based on a risk assessment methodology such as the NIST Risk Management Framework
- (risk rating x probability of risk) + (residual risk x probability of residual risk)
- Number of Potential Risks / Number of Acceptable Risks
Attack Surface
- The total number of entry points or attack vectors available to attackers
- Attack surface = sum of (threats x vulnerabilities)
Vulnerability Assessment Score
- A numerical score based on a vulnerability assessment methodology such as CVSS
- Common Vulnerability Scoring System [CVSS calculator(https://www.first.org/cvss/calculator/3.1)
- Potential Vulnerabilities/Number of Acceptable Vulnerabilities
- CVSS: (Base Score + Temporal Score + Environmental Score)
Access Control Effectiveness
- The ability of the access control system to protect the system from unauthorized access
- (Authenticated Access Attempts - Unauthorized Access Attempts) / Authenticated Access Attempts
- Number of Access Control Rules/Number of Access Control Rules Enforced
Authentication Effectiveness
- The ability of the authentication system to accurately identify and authenticate users
- Authentication Effectiveness = (Authenticated Users - Unauthenticated Users) / Authenticated Users
Authorization Effectiveness
- The ability of the authorization system to accurately authorize users to access resources
- Number of Authorization Controls/Number of Authorization Controls Enforced
Security Audit Log Analysis
- The ability of the security audit system to detect, monitor, and analyze security events
- (Audited Events - Unaudited Events) / Audited Events
- Number of Security Events Detected/Number of Security Events Recorded
Security Incident Rate
- Rate of security incident per time interval
- Security incidents / time
Security Compliance Score
- Score of how well the system complies with security policies and best practices
- Compliance score = (number of compliant components / total number of components) x 100
Security Training Effectiveness
- Measurement of how well users understand and adhere to security policies
- Training effectiveness = (number of users who successfully complete security trainings / total number of users) x 100
Vulnerability Scanning Frequency
- Measurement of how often the system is tested for security vulnerabilities
- Scanning frequency = (number of scans performed in a given time period / total time period)
Identity and Access Management (IAM) roles and permissions audit
- Measurement of the accuracy and security of IAM roles and permissions
- IAM audit = (number of correct roles and permissions / total number of roles and permissions) x 100
Key Management Service (KMS) usage and audit
- Measurement of the accuracy and security of KMS usage
- KMS audit = (number of correct KMS usage / total number of KMS usage) x 100
Security Information and Event Management (SIEM) alerts and monitoring
- Measurement of the accuracy and security of SIEM alerts
- SIEM monitoring = (number of correctly triggered alerts / total number of alerts) x 100
Threat intelligence feeds integration and usage
- Measurement of how threat intelligence feeds are used to help identify and respond to security threats
- Number of threat intelligence feeds used / total number of threat intelligence feeds available
Encryption key rotation frequency
- Measurement of how often cryptographic keys are changed
- Time interval between key changes
Compliance posture
- Measurement of how well the system complies with a security standard
- Number of security standards met / total number of security standards
Network traffic monitoring and analysis
- Measurement of the ability to monitor and analyze network traffic for suspicious activity
- Amount of network traffic monitored / total network traffic
User behavior analytics (UBA) and anomaly detection
- Measurement of the ability to detect anomalous user behavior
- Number of anomalies detected / total user behavior events
Data Loss Prevention (DLP)
- The practice of preventing sensitive data from leaving the organization
- DLP = implementation of policies and technologies + monitoring of user activity
Data Encryption
- The practice of transforming sensitive data into an unreadable format
- Data encryption = implementation of encryption algorithms + encryption of data

⭐️ Cost

I am only going to give some brief metrics on Cost, because almost everything above can affect cost and it will vary a lot between providers.

This is not to minimize cost, it's one of the most important factors!!!

Just that cost should be considered on ALL the metrics above.

Total Cost of Ownership (TCO) = (cost of acquisition + cost of operation + cost of maintenance) over the useful life of the asset
Cost per transaction = total cost / number of transactions
Cost per unit of time = total cost / time period
Cost per user = total cost / number of users
Return on Investment (ROI) = (gain from investment - cost of investment) / cost of investment
Cost of Downtime (CoD) = (lost revenue + recovery costs + damage to brand reputation) / total downtime hours
Cost of Poor Quality (CoPQ) = (internal failure costs + external failure costs + cost of appraisal + cost of prevention) / total number of units produced
Cost of Delay (CoD) = (value of time saved by earlier release - cost of delay) / time saved

There are a ton of cloud cost tools but these are some of the popular ones on the biggest platforms (there are many more if you search on their sites):

AWS
- AWS Cost Explorer
- AWS Budgets
- AWS Trusted Advisor
Azure
- Azure Cost Management + Billing
- Azure Advisor
- Azure Service Health
GCP
- GCP Billing
- GCP Pricing Calculator
- GCP Cost Management
Third-party
- CloudCheckr
- CloudHealth by VMware
- Apptio Cloudability
- CloudBolt
- CloudZero

⭐️ References

Thanks for checking it out... if you have ideas for improvements, feel free to comment or make a PR on my github repo: https://github.com/csjcode/solutions-architect-metrics-cheatsheet

Git shortcuts (alias)

CSJcode — Sat, 01 Jan 2022 01:30:54 +0000

Shortcuts and aliases I was compiling as I was setting up a new laptop, and thought I'd share them.

Lets get situated with where we are starting

$ cat ~/.gitconfig

[user]
        name = Foo Bar
        email = example@example.com
[init]
        defaultBranch = main
[alias]
        co = checkout
        br = branch
        ci = commit

Git Shortcuts: (1) Git alias or (2) Git+Shell alias

Make git shortcuts in a git alias - pattern (note: --global is normally used for a dev's user account, but you could use --system for all accounts, --local for the local repo only)

$ git config --global alias.<alias> <commands>

Make git shortcuts in shell (bash/zsh etc.) alias - pattern

$ alias <alias>='<commands>'

Example: use shortcut "gl" to list git user aliases, including adding, listing and removing the alias.

$ git config --global alias.gl 'config --global -l'

$ git gl

[...]
init.defaultbranch=main
alias.co=checkout
alias.br=branch
alias.ci=commit
[...]

$ alias gconf='git gl'

$ gconf

[...]
init.defaultbranch=main
alias.co=checkout
alias.br=branch
alias.ci=commit
[...]

$ alias -p

alias gconf='git gl'

$ unalias gconf

$ gconf
bash: gconf: command not found

$ alias -p

Use could also use this to see settings:

git config --list

file:/Users/foobar/.gitconfig  alias.com=checkout main
file:/Users/foobar/.gitconfig  alias.p=push
file:.git/config        core.repositoryformatversion=0
file:.git/config        core.filemode=true
file:.git/config        core.bare=false
file:.git/config        core.logallrefupdates=tru

$ git config user.email

example@example.com

$ git config user.name

Foo bar

$ git config --global user.email "myname@gmail.com"

$ git config --global user.name "firstname lastname"

Basics

$ git config --global alias.co checkout

$ git config --global alias.com "checkout main"

$ git config --global alias.br branch

$ git config --global alias.a add

$ git config --global alias.cm 'commit -m'

$ git config --global alias.p push

$ git config --global alias.mr merge

$ git config --global alias.rb rebase

$ git config --global alias.rbc rebase --continue

$ git config --global alias.st status

$  git st

On branch main
Your branch is up to date with 'origin/main'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        git-aliases.md

nothing added to commit but untracked files present (use "git add" to track)

Git Reset

Important: do not use this config unless you are sure you know what you are doing, it could result in losing code permanently if you misuse this or make a mistake.

Use a test repo first, until you are sure about what is going on.

see: What's the difference between git reset --mixed, --soft, and --hard? https://stackoverflow.com/questions/3528245/whats-the-difference-between-git-reset-mixed-soft-and-hard

As stated in the link above:

--soft: uncommit changes, changes are left staged (index).
--mixed (default): uncommit + unstage changes, changes are left in working tree.
--hard: uncommit + unstage + delete changes, nothing left.

Undo last local commmit, to HEAD (uncommit, keeps in stage)

$ git config --global alias.rs reset --soft HEAD~1

Undo last local commmit, to HEAD (uncommit unstage)

$ git config --global alias.rmx reset --mixed HEAD~1

Undo local edits to HEAD (DANGER, permanent, caution)

$ git config --global alias.rh reset --hard HEAD~1

List of all commits - summary

$ git config --global alias.l1 'log --oneline'

61eee34 (HEAD -> main, origin/main, origin/2-first-app-counter, 2-first-app-counter) Counter app
e9a23b9 (2-first-app) Hello world
bcc8bf2 Start fresh
abf9f0a (origin/1-hello-world, 1-hello-world) Basic hello world

Last commit

$ git config --global alias.last 'log -1 HEAD --stat'

git last

Author: Foo bar <example@example.com>
Date:   Fri Dec 31 14:54:47 2021 -0800

    Counter app example

 counter.sol | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

Remote comfigured repos

$ git config --global alias.rv 'remote -v'

$ git rv

origin  https://github.com/foobar/Hello-World.git (fetch)
origin  https://github.com/foobar/Hello-World.git (push)

Search for specific strings (put string after -F)

$ git config --global alias.se '!git rev-list --all | xargs git grep -F'

Cherry-pick

more info: https://www.atlassian.com/git/tutorials/cherry-pick

$ git config --global alias.ch cherry-pick

Change the commit message:

git config --global commit.template ~/.gitmessage.txt

Howto: Rosetta terminal (MacOS) in Visual Studio Code

CSJcode — Tue, 28 Dec 2021 01:54:58 +0000

Background: "Rosetta" is the name of the Apple Mac application that can emulate x86 architecture even when on an Apple ARM (ie. Apple M1 chip). "Terminal" is the application on Mac that takes command line input (CLI), and is integrated with Visual Studio Code. Visual Studio Code is one of the most popular development IDE tools.

A Rosetta terminal (on MacOS) means you are loading and running the Terminal app using the x86 emulation.

I'll share a few tips on how to set the default terminal in Visual Studio Code.

This is useful for example when developing with Rust and Solana on an Mac with M1 chip. As of December 2021, there were some issues, so developers often use a Rosetta terminal which resolves the issues. (see links at bottom of article for more on that)

Since I am doing some Solana/Rust development currently, I needed Visual Studio Code (VSC) to open the Rosetta terminal by default.

Howto for Visual Studio Code

Open the VSC Command Palette (Ctrl/Command + Shift + P)
Type "settings.json" to find related commands

There are a couple variations of how you could do this, such as in User or Workspace settings.

I'm going to show how to do it for the Workspace settings.

(option 1) Change VSC Workspace settings

This method is useful because it's project-specific and you may not want all your projects to default to Rosetta terminal (x86). It saves a settings file in your current project.

After typing "settings.json" into Command Palette you should see some selections like this, I chose the Workspace one.

This brought up an empty file. If you already have Workspace preferences it may show some JSON. Either way, just add the JSON below.



    "terminal.integrated.profiles.osx": {
        "x86 bash": {
            "path": "/usr/bin/arch",
            "args": ["-arch", "x86_64", "/bin/bash"]
        }
    },
    "terminal.integrated.defaultProfile.osx": "x86 bash"

note: you can change this to zsh (/bin/zsh) or another shell, just change the corresponding values as above.

You can also identify if you are using Rosetta terminal (or not) with the command

$ arch

output (validating Rosetta): i386

output (validating NOT Rosetta): arm64

After I closed my VSC terminal and initiated a new one it looks like this:

(alternate option) Change VSC User settings

You can also change your Visual Studio Code global User settings to do the same.

It's slightly trickier because you have to find the correct part of the JSON, load that up, add a comma and append it.

I first went to Settings in the regular app Preferences:

I typed in "defaultProfile". That brings up this menu:

After setting my default terminal, I closed my previous terminal and started a new one. And this is the result:

As I mentioned using Rosetta terminal for Rust/Solana dev, you can find out more on that config here: https://dev.to/nickgarfield/how-to-install-solana-dev-tools-on-an-m1-mac-kfn

Once you are set up for that, you can follow Nader Dabit's Solana/Rust and Phantom tutorial: https://dev.to/dabit3/the-complete-guide-to-full-stack-solana-development-with-react-anchor-rust-and-phantom-3291

Also for citation, note that I originally found the terminal settings info at the following url, expanded on it with screenshots and different methods, and adapted for bash profile: https://stackoverflow.com/questions/70217885/configure-m1-vscode-arm-but-with-a-rosetta-terminal

I hope this was helpful, thanks for checking this article out.

Feel free to comment on any other related helpful suggestions.