neomantra

High Performance Redis

In response to this brief blog entry, @antirez tweeted for some documentation on high-performance techniques for Redis. What I present here are general high-performance computing (HPC) techniques. The examples are oriented to Redis. but they work well for any program designed to be single- or worker-threaded and asynchronous (e.g. uses epoll).

The motivation for using these techniques is to maximize performance of our system and services. By isolating work, controlling memory, and other tuning, you can achieve significant reduction in latency and increase in throughput.

My perspective comes from the microcosm of my own bare-metal (vs VM), on-premises deployment. It might not be suitable for all scenarios, especially cloud deployments, as I have little experience with HPC there. After some discussion, maybe this can be adapted as [redis.io documentation](https://redis.io/do

xenithorb

#-*- mode: nginx; mode: flyspell-prog; mode: autopair; ispell-local-dictionary: "american" -*-
## Define a zone for limiting the number of simultaneous
## connections nginx accepts. 1m means 32000 simultaneous
## sessions. We need to define for each server the limit_conn
## value refering to this or other zones.
## ** This syntax requires nginx version >=
## ** 1.1.8. Cf. http://nginx.org/en/CHANGES. If using an older
## ** version then use the limit_zone directive below
## ** instead. Comment out this
## ** one if not using nginx version >= 1.1.8.

tj

// grab time spent
sum := Agg("duration_sum", Sum("duration"))

// grab time spent per label
labels := Agg("labels",
	Terms("issue.labels.keyword", 100),
	Aggs(sum))

// grab time spent per day, and per label

zacharycarter

Binding to C Libraries with Nim

---

Table of Contents

• Introduction
• C2Nim
• The C Preprocessor
• Pragmas

tjvr

server {
    listen 80;
    server_name cors.tjvr.org;

    root /usr/share/nginx/html;
    index index.html;

    client_max_body_size 1m;
    client_body_buffer_size 64k;

fjeldstad

const trimmed = problematicString.replace(/[\x00-\x09\x0B-\x0C\x0E-\x1F\x7F-\x9F]/g, '');

adw0rd

# https://www.erlang-solutions.com/downloads/download-erlang-otp
# wget http://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb
# sudo dpkg -i erlang-solutions_1.0_all.deb

deb http://packages.erlang-solutions.com/ubuntu trusty contrib
deb http://packages.erlang-solutions.com/ubuntu saucy contrib
deb http://packages.erlang-solutions.com/ubuntu precise contrib

wget http://packages.erlang-solutions.com/ubuntu/erlang_solutions.asc
sudo apt-key add erlang_solutions.asc

xjamundx

This is the follow up to a post I wrote recently called From Require.js to Webpack - Party 1 (the why) which was published in my personal blog.

In that post I talked about 3 main reasons for moving from require.js to webpack:

1. Common JS support
2. NPM support
3. a healthy loader/plugin ecosystem.

Here I'll instead talk about some of the technical challenges that we faced during the migration. Despite the clear benefits in developer experience (DX) the setup was fairly difficult and I'd like to cover some of the challanges we faced to make the transition a bit easier.

morhekil

http {
  log_format bodylog '$remote_addr - $remote_user [$time_local] '
      '"$request" $status $body_bytes_sent '
      '"$http_referer" "$http_user_agent" $request_time '
      '<"$request_body" >"$resp_body"';

  lua_need_request_body on;

  set $resp_body "";
  body_filter_by_lua '

ashrithr

Installing Graphite:

Graphite does two things:

1. Store numeric time-series data
2. Render graphs of this data on demand

What Graphite does not do is collect data for you, however there are some tools out there that know