Mobil Mewah

Salah satu sumber Inspirasi.

Mobil Sport terbaik

Anda pasti bisa memilikinya.

Bermain dengan pesawat

Salah satu ide yang gila, Balapan di udara.

Bermain di angkasa

Apakah ini salah satu Goals dalam hidup anda? anda pasti bisa mencapainya

Saturday, 12 November 2016

CouchDB test performance using httperf

After test an erlang framework to serve JSON API from a postgreSQL database, i remember that had installed CouchDB in my laptop, and why not use it with same data and try the performance load using the same httperf command.

The result of json from couchdb :

{
  "total_rows": 2,
  "offset": 0,
  "rows": [
    {
      "id": "2f9bc9fb62f3e8fa19ace932b9000d9f",
      "key": "2f9bc9fb62f3e8fa19ace932b9000d9f",
      "value": {
        "_id": "2f9bc9fb62f3e8fa19ace932b9000d9f",
        "_rev": "1-0a77ba71f874dc7ca2b7d22893cf4882",
        "task": "learn",
        "status": "not done"
      }
    },
    {
      "id": "2f9bc9fb62f3e8fa19ace932b90013d9",
      "key": "2f9bc9fb62f3e8fa19ace932b90013d9",
      "value": {
        "_id": "2f9bc9fb62f3e8fa19ace932b90013d9",
        "_rev": "1-6127c1359f9d34d2733943876931e7d4",
        "task": "erlang",
        "status": "not done"
      }
    }
  ]
}

And the design document to retreive the data save with path /todo/_design/todo/_view/list

function(doc) {
  emit(doc._id, doc);
}


so here are the result with same data.


httperf --client=0/1 --server=127.0.0.1 --port=5984 --uri=/todo/_design/todo/_view/list --rate=150 --send-buffer=4096 --recv-buffer=16384 --num-conns=27000 --num-calls=1
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE
Maximum connect burst length: 1

Total: connections 27000 requests 27000 replies 27000 test-duration 179.995 s

Connection rate: 150.0 conn/s (6.7 ms/conn, <=13 concurrent connections)
Connection time [ms]: min 0.6 avg 1.1 max 92.4 median 0.5 stddev 2.5
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 150.0 req/s (6.7 ms/req)
Request size [B]: 90.0

Reply rate [replies/s]: min 149.8 avg 150.0 max 150.0 stddev 0.0 (36 samples)
Reply time [ms]: response 1.1 transfer 0.1
Reply size [B]: header 231.0 content 470.0 footer 2.0 (total 703.0)
Reply status: 1xx=0 2xx=27000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 62.39 system 117.63 (user 34.7% system 65.4% total 100.0%)
Net I/O: 115.9 KB/s (0.9*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

As we can see the result is almost the same. no error happening, all request processed with 6.7ms / request.
Test done in 179 s or 3 minutes. I don't know if all erlang use same processing to dump json.

Anyhow, great result and positif about this.

Erlang Chicago Boss JSON API test performance

I am documenting my test on erlang web framework, Chicago Boss and use it for backend API.
My setting for the database using Postgresql 9.2 using 1 table with 2 rows and 4 fields only and return the request using JSON.

I test the performance load using httperf on my debian 8 laptop.

# httperf --server 127.0.0.1 --port 8001 --uri /todo/list --rate 150 --num-conn 27000 --num-call 1

In this simple test, the same page is retrieved repeatedly. The rate at which requests are issued is 150 per second. The test involves initiating a total of 27,000 TCP connections and on each connection one HTTP call is performed (a call consists of sending a request and receiving a reply)

 The result should be like this if access from browser :

{
  "todos": [
    {
      "id": "todo-1",
      "task": "learning",
      "status": "not done",
      "owner": "Voldomore"
    },
    {
      "id": "todo-2",
      "task": "erlang",
      "status": "not done",
      "owner": "Potter"
    }
  ]
}

and the result of httperf : 

httperf --client=0/1 --server=127.0.0.1 --port=8001 --uri=/todo/list --rate=150 --send-buffer=4096 --recv-buffer=16384 --num-conns=27000 --num-calls=1
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE
Maximum connect burst length: 1

Total: connections 27000 requests 27000 replies 27000 test-duration 179.999 s

Connection rate: 150.0 conn/s (6.7 ms/conn, <=13 concurrent connections)
Connection time [ms]: min 3.9 avg 6.6 max 85.4 median 5.5 stddev 4.5
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 150.0 req/s (6.7 ms/req)
Request size [B]: 71.0

Reply rate [replies/s]: min 149.8 avg 150.0 max 150.2 stddev 0.1 (36 samples)
Reply time [ms]: response 6.6 transfer 0.0
Reply size [B]: header 125.0 content 673.0 footer 0.0 (total 798.0)
Reply status: 1xx=0 2xx=27000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 55.66 system 124.11 (user 30.9% system 68.9% total 99.9%)
Net I/O: 127.3 KB/s (1.0*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0


What i see are 179 seconds (3 minutes) to complete all the request, and with basic setup. only have a model and controller to list. I want to try it using Django Rest Framework also later on to see how django rest framework performance. But surely Erlang faster. Just want to know how many can be handled by DRF.


Twitter Delicious Facebook Digg Stumbleupon Favorites More