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 <an...@andregarzia.com> wrote: From: Andre Garzia <an...@andregarzia.com> Subject: [RevServer tips] Spreading the load or why wise developers use asynchronous workflows To: "How to use Revolution" <use-revolution@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution