vasanthk

System Design Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

Basic Steps

1. Clarify and agree on the scope of the system

• User cases (description of sequences of events that, taken together, lead to a system doing something useful)
  • Who is going to use it?
  • How are they going to use it?

jboner

Latency Comparison Numbers (~2012)
----------------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy             3,000   ns        3 us
Send 1K bytes over 1 Gbps network       10,000   ns       10 us
Read 4K randomly from SSD*             150,000   ns      150 us          ~1GB/sec SSD

denji

Moved to git repository: https://github.com/denji/nginx-tuning

NGINX Tuning For Best Performance

For this configuration you can use web server you like, i decided, because i work mostly with it to use nginx.

Generally, properly configured nginx can handle up to 400K to 500K requests per second (clustered), most what i saw is 50K to 80K (non-clustered) requests per second and 30% CPU load, course, this was 2 x Intel Xeon with HyperThreading enabled, but it can work without problem on slower machines.

You must understand that this config is used in testing environment and not in production so you will need to find a way to implement most of those features best possible for your servers.

hellerbarde

Latency numbers every programmer should know

L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns             
Compress 1K bytes with Zippy ............. 3,000 ns  =   3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns  =  20 µs
SSD random read ........................ 150,000 ns  = 150 µs

Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs

masak

Ok, I geeked out, and this is probably more information than you need. But it completely answers the question. Sorry. ☺

Locally, I'm at this commit:

$ git show
commit d6cd1e2bd19e03a81132a23b2025920577f84e37
Author: jnthn <jnthn@jnthn.net>
Date:   Sun Apr 15 16:35:03 2012 +0200

When I added FIRST/NEXT/LAST, it was idiomatic but not quite so fast. This makes it faster. Another little bit of masak++'s program.

plentz

# to generate your dhparam.pem file, run in the terminal
openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048

zhengjia

=Navigating=
    visit('/projects')
    visit(post_comments_path(post))

=Clicking links and buttons=
    click_link('id-of-link')
    click_link('Link Text')
    click_button('Save')
    click('Link Text') # Click either a link or a button
    click('Button Value')

abtrout

Password-store keeps your passwords (or any other sensitive information) saved in GnuPG encrypted files organized in ~/.password-store. For more information about GPG, consult the GNU Privacy Handbook.

Getting started

To get started, install pass and generate a keypair.

$ brew install pass
$ gpg --gen-key
$ gpg --list-keys

cpq

Why stack grows down

Any running process has several memory regions: code, read-only data, read-write data, et cetera. Some regions, such as code and read-only data, are static and do not change over time. Other regions are dynamic: they can expand and shrink. Usually there are two such regions: dynamic read-write data region, called heap, and a region called stack. Heap holds dynamic memory allocations, and stack is mostly used for keeping function frames.

Both stack and heap can grow. An OS doesn't know in advance whether stack or heap will be used predominantly. Therefore, an OS must layout these two memory regions in a way to guarantee maximum space for both. And here is the solution:

1. Layout static memory regions at the edges of process's virtual memory
2. Put heap and stack on edges too, and let them grow towards each other: one grows up, one grows down

sivel

Better SSH Authorized Keys Management

A seemingly common problem that people encounter is how to handle all of your users authorized_keys file.

People struggle over management, ensuring that users only have specific keys in the authorized_keys file or even a method for expiring keys. A centralized key management system could help provide all of this functionality with a little scripting.

One piece of functionality overlooked in OpenSSH is the AuthorizedKeysCommand configuration keyword. This configuration allows you to specify a command that will run during login to retrieve a users public key file from a remote source and perform validation just as if the authorized_keys file was local.

Here is an example directory structure for a set of users with SSH public keys that can be shared out via a web server: