breaking out of serial execution
scaling web apps with message queues
who i am / dotCom bubble europe / 10k -> 1m domains in 5 years / NZ IWMN / springtimesoft (open for business) / other projects like OP, Startup Weekend
norbu09
serial execution is bad - next up code sample
serial execution
it is bad and well we know it
get '/signup' => sub {
parse_request($req);
ask_db($stuff);
scale_avatar($img);
call_ext_api($info_needed);
render_page($results);
}page rendering time
"> fast"
(could also call it suboptimal)
interpreted languages
- single threaded
- normally no parallel execution
- no background tasks
- one execution path
methods for speeding up
- client sides (Ajax request)
- server sides (Message queue, gearman, ...)
client sides
- many Ajax requests
- ⇒ many HTTP connections
- DDOS yourself on a busy day
server sides
(or the only true way)
a step back
corporates talk about:
- middleware
- message bus
- processing pipeline
all they are talking about
is in fact a glorified message queue
next up: code sample
what is a message queue
- takes some information
- routes it to a stack
- stack is read by clients
producer
sub producer{
$information => {
route => 'stack.x',
data => 'helo world'
};
send($information);
}consumer
sub consumer{
while( read('stack.x'))
{
process();
}
}next up: code sample
parallel execution
all calls send non blocking requests
get '/signup' => sub {
parse_request($req);
ask_db_async($stuff);
scale_avatar_async($img);
call_ext_api_async($info_needed);
$results = collect_answers();
render_page($results);
}asynchronous handling
- send a request
- wait for an answer
- do something else while waiting
many different protocols / currently hot and widely used in startups
actual implementations
- AMQP (RabbitMQ)
- ∅mq (zeromq)
- Redis based (resque, RestMQ)
real world example
or how do i go from monolythic to modular and asynchronous
analyse your code base
look for:
- external calls
- long running functions
- things that can happen in parallel
write small daemons
- move functionality in small daemons
- talk to them via AMQP
- write a collector function
- collect answers at the latest point
more advanced
- cache your answers
- respond to Redis
- poll Redis for answers
iWantMyName architecture
how we do it and why
call flow
- check Redis for cached answer
- ask via AMQP
- kick off workflow in backend
- respond to Redis
- frontend reads from redis
Backend workflows
- talk to a workflow daemon
- kicks off series of tasks
- may wait for external callback
- replies (or not)
DON'T TRY TO BE TOO SMART
millions have been wasted on sophisticated workflow engines
and you are going too far corporate if you try
KISS ( :-* )
keep it stupid simple
nice side effects
- scale frontend/backend independent
- group CPU/memory greedy processes
- scale a single backend function
workflow side effects
- modify business logic
- or add functionality
- ... on the fly