| =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') |
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 <[email protected]>
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.
| 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 |
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
| #! /bin/bash | |
| # | |
| # chkconfig: - 55 45 | |
| # description: The memcached daemon is a network memory cache service. | |
| # processname: memcached | |
| ### END INIT INFO | |
| # Usage: | |
| # cp /etc/memcached.conf /etc/memcached_server1.conf | |
| # cp /etc/memcached.conf /etc/memcached_server2.conf |
This article has been given a more permanent home on my blog. Also, since it was first written, the development of the Promises/A+ specification has made the original emphasis on Promises/A seem somewhat outdated.
Promises are a software abstraction that makes working with asynchronous operations much more pleasant. In the most basic definition, your code will move from continuation-passing style:
getTweetsFor("domenic", function (err, results) {
// the rest of your code goes here.
| #!/bin/sh | |
| version="1.4.15" | |
| priority="10415" | |
| libevent="/usr/local/libevent/2.0.20-stable/" | |
| supervisordir="/etc/supervisord.d" | |
| # create user | |
| sudo groupadd memcached | |
| sudo useradd -r -g memcached -s /sbin/nologin -M -d /var/run/memcached memcached |
| <?php | |
| Schema::create('users' , function($table) | |
| { | |
| $table->increments('id'); Incrementing ID to the table (primary key). | |
| $table->string('email'); VARCHAR equivalent column | |
| $table->string('name', 100); VARCHAR equivalent with a length | |
| $table->integer('votes'); INTEGER equivalent to the table |
| # to generate your dhparam.pem file, run in the terminal | |
| openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048 |
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.