[RevServer tips] Spreading the load or why wise developers use asynchronous workflows

[Michael Kann]

Andre wrote:

If there's interest in this community I can craft some real RevServer
scripts showing this approach. This is the key to being able to serve
lots of request while doing intensive work and being a good shared
server citizen.

---------------------------------------------------------
I'm sure that everybody who has read your explanation would appreciate some scripts. Thanks again,

Mike

--- On Wed, 8/4/10, Andre Garzia <andre at andregarzia.com> wrote:

From: Andre Garzia <andre at andregarzia.com>
Subject: [RevServer tips] Spreading the load or why wise developers use  asynchronous workflows
To: "How to use Revolution" <use-revolution at lists.runrev.com>
Date: Wednesday, August 4, 2010, 10:36 AM

Hello Folks,

Spreading the load or why wise developers use asynchronous workflows

Introduction

Continuing the trend of posting tips for RevServer here, today I decided to
talk about how to spread the load of your web application. During the last
days we've seen many talks about memory limitations and execution time
limitations regarding RevServer (actually regarding On-Rev). The fact is
that all web hosts that use shared servers need some kind of virtualization
police to prevent rogue processes from taking all RAM and/or CPU and thus
rendering the whole system unresponsive. This kind of policy can be
implemented on different OS levels and how each web hosting service does it
is beyond the scope of this email.

On-Rev service has a policy of allowing a process to run for about 30
seconds and to take up to 64MB, while this seems small to all the desktop
developers in here, all of which are used to swallowing big chunks of memory
and CPU (seen people trying to insert 1 GB of data into Text fields), these
are actually very sensible values and should accomodate most users. Those 30
secs are like forever in terms of web serving, usually a page takes
milliseconds to be served. 64MB of RAM is also a big sum. Here where I work
we use the biggest database I've ever seen, it is spread among different
machines but the one I am working now has 83 million records totaling 9GB of
data and this is our small database, the big one holds more than 7 thousand
tables and millions and millions of records. We're on the business of being
evil, I mean, we're on the business of sending email marketing and just one
of our machines pushes 26 thousand emails per minute. Right now our system
is built with PHP (it was built before me) and we do all this stuff with a
memory allocation of 120MB (which we use about 70MB), so the 64MB allowed by
On-Rev appears quite good. Remember this limits applies only to On-Rev
service, I am running RevServer on my own VPS and I am yet to face such
limits (see my previous email). Other web hosts have different limits and
one should not assume that his own hosting company has no limit.

Many web developers here are just beginning on their path to total web
server domination, most are coming from the safe lands of Desktop
application design where you are free to do basically anything. You have as
much memory as you can swap pages to disk. You can display a progress bar
and have a handler execute for minutes without a problem. Those developers
sometimes are unprepared to deal with the constraints forced on them by
server side programming. They are no unprepared because they are lazy or
anything but because they are not used to the "design patterns" of server
side programming, you can't think in terms of something when you never ever
saw that thing, without some knowledge base the only way up on the steep
hill of server side programming is quite a hard track. So today's topic is
on load distribution and asynchronous workflow, let us first detail the
problem.

Well, this message is to big for the list server, it blocked me, so if you
want to carry on reading:

move to: http://andregarzia.com/async.irev

-- 
http://www.andregarzia.com All We Do Is Code.
_______________________________________________
use-revolution mailing list
use-revolution at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution