Archive for Programming

A Handy Strace Option

I didn’t notice the ‘-ff’ option of strace until I came across it today. By turning it on, not only fork(2)s can be followed, but also each process’s trace will be written to, where pid is the process id of each process. Typical usage might look like this:

# strace -o tracelog.txt -ff -T command

This option can be quite handy, when debugging programs that spawn child processes.

Comments (27)

Creating a Hello World! Nginx Module

Some of my friends think nginx modules are very difficult to write. Sure it’s not so easy but it’s not that hard either. The only problem is that the documentation is not enough. But don’t let this scare yourself away, the situation is improving.

So I write a hello world nginx module here. It’s pretty short and with enough comments. If you’re a new nginx module developer, feel free to take it as an example and replace hello with whatever your module name is, then start your happy nginx module hacking journey. And I’ll write more topics on nginx soon. Look for it!  :D


 * Copyright (C) Joshua Zhu,
#include <ngx_config.h>
#include <ngx_core.h>
#include <ngx_http.h>
static char *ngx_http_hello(ngx_conf_t *cf, ngx_command_t *cmd,
    void *conf);
static ngx_command_t ngx_http_hello_commands[] = {
    { ngx_string("hello"),
      NULL },
static u_char ngx_hello_string[] = "Hello, world!";
static ngx_http_module_t ngx_http_hello_module_ctx = {
    NULL,                          /* preconfiguration */
    NULL,                          /* postconfiguration */
    NULL,                          /* create main configuration */
    NULL,                          /* init main configuration */
    NULL,                          /* create server configuration */
    NULL,                          /* merge server configuration */
    NULL,                          /* create location configuration */
    NULL                           /* merge location configuration */
ngx_module_t ngx_http_hello_module = {
    &ngx_http_hello_module_ctx,    /* module context */
    ngx_http_hello_commands,       /* module directives */
    NGX_HTTP_MODULE,               /* module type */
    NULL,                          /* init master */
    NULL,                          /* init module */
    NULL,                          /* init process */
    NULL,                          /* init thread */
    NULL,                          /* exit thread */
    NULL,                          /* exit process */
    NULL,                          /* exit master */
static ngx_int_t
ngx_http_hello_handler(ngx_http_request_t *r)
    ngx_int_t    rc;
    ngx_buf_t   *b;
    ngx_chain_t  out;
    /* we response to 'GET' and 'HEAD' requests only */
    if (!(r->method & (NGX_HTTP_GET|NGX_HTTP_HEAD))) {
        return NGX_HTTP_NOT_ALLOWED;
    /* discard request body, since we don't need it here */
    rc = ngx_http_discard_request_body(r);
    if (rc != NGX_OK) {
        return rc;
    /* set the 'Content-type' header */
    r->headers_out.content_type_len = sizeof("text/html") - 1;
    r->headers_out.content_type.len = sizeof("text/html") - 1;
    r-> = (u_char *) "text/html";
    /* send the header only, if the request type is http 'HEAD' */
    if (r->method == NGX_HTTP_HEAD) {
        r->headers_out.status = NGX_HTTP_OK;
        r->headers_out.content_length_n = sizeof(ngx_hello_string) - 1;
        return ngx_http_send_header(r);
    /* allocate a buffer for your response body */
    b = ngx_pcalloc(r->pool, sizeof(ngx_buf_t));
    if (b == NULL) {
    /* attach this buffer to the buffer chain */
    out.buf = b; = NULL;
    /* adjust the pointers of the buffer */
    b->pos = ngx_hello_string;
    b->last = ngx_hello_string + sizeof(ngx_hello_string) - 1;
    b->memory = 1;    /* this buffer is in memory */
    b->last_buf = 1;  /* this is the last buffer in the buffer chain */
    /* set the status line */
    r->headers_out.status = NGX_HTTP_OK;
    r->headers_out.content_length_n = sizeof(ngx_hello_string) - 1;
    /* send the headers of your response */
    rc = ngx_http_send_header(r);
    if (rc == NGX_ERROR || rc > NGX_OK || r->header_only) {
        return rc;
    /* send the buffer chain of your response */
    return ngx_http_output_filter(r, &out);
static char *
ngx_http_hello(ngx_conf_t *cf, ngx_command_t *cmd, void *conf)
    ngx_http_core_loc_conf_t *clcf;
    clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module);
    clcf->handler = ngx_http_hello_handler; /* handler to process the 'hello' directive */
    return NGX_CONF_OK;


HTTP_MODULES="$HTTP_MODULES ngx_http_hello_module"
NGX_ADDON_SRCS="$NGX_ADDON_SRCS $ngx_addon_dir/ngx_http_hello_module.c"


# hello
worker_processes 1;
events {
       worker_connections 1024;
http {
     server {
     	    listen 8080;
	    server_name localhost;
	    location / {

If you want more detailed information, please consult Evan Miller’s Guide To Nginx Module Development.

Comments (80)

Learn from Memcached’s Success

Memcached becomes more and more popular nowadays. It is widely used by many heavy loaded sites. Why does it succeed?

Well, of course the first and the most important reason is that it meets the need for speed of the web 2.0 sites, by caching data and objects in memory. However, from the point of view of a server developer, what I want to emphasize is that it is the simplicity of memcached’s protocol design makes it more successful. Take a look at memcached’s protocol:

  • storage: ("set", "add", "replace", "append", "prepend", "cas")
             <command name> <key> <flags> <exptime> <bytes> [noreply]rn
             cas <key> <flags> <exptime> <bytes> <cas unique> [noreply]rn
         reply: ("ERRORrn", "CLIENT_ERROR <error>rn", "SERVER_ERROR <error>rn",
             "STOREDrn", "NOT_FOUNDrn", "EXISTSrn", "NOT_FOUNDrn")
  • retrieval: ("get", "gets")
             get <key>rn
             gets <key>rn
         reply: ("ENDrn",
             "VALUE <key> <flags> <bytes> [<cas unique>]rn<data block>rn")
  • deletion:
             delete <key> [<time>] [noreply]rn
         reply: ("DELETEDrn", "NOT_FOUNDrn")
  • increment/decrement: ("incr", "decr")
             incr <key> <value> [noreply]rn
             decr <key> <value> [noreply]rn
         reply: ("NOT_FOUNDrn",
  • statistics: ("stat")
             stats <args>rn
         reply: ("STAT <name> <value>rn",
             "STAT items:<slabclass>:<stat> <value>rn"
  • other:
         reply: ("OKrn")
         reply: ("VERSION <version>rn")
         reply: ("OKrn")
  • With the textual protocol as shown above, memcache can be easily supported and implemented in various programming languages. No wonder dozens of different memcache clients appear. And then it consequently boosts memcached’s use. Simple thing usually will withstand the test of time. The old simple textual protocols, e.g., HTTP, FTP, SMTP and POP3 are still in use on the modern Internet. Not only because textual protocols can be easily parsed and extended, but also they are convenient for human being to read and debug. This is where the UNIX philosophy shines.

    In conclusion, always prefer textual protocol when designing your own application. It would turn out to be really a wise decision.

    Comments (21)

    Tips on High Performance Server Programming

    Yesterday, I gave a talk entitled “Tips on High Performance Server Programming” to some computer science graduate students at Jinan University. Below are the slides I used for the talk.

    Comments (37)