http://qs321.pair.com?node_id=199895

Angel has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks, I've been trying to figure out how to ask this question for a while and the discussion of making perl monks faster brought it to my fore front of my mind. Most of the experienced people I know simply say...write it and then see how long it takes to execute and then add more servers as needed. Is there any vague rules of thumb to figure out how to calculate server power prior ro development based on a series of questions or concepts?

Replies are listed 'Best First'.
Re: Server Load
by BrowserUk (Patriarch) on Sep 22, 2002 at 16:48 UTC

    Personally, I think a better question would be to ask:

    What concepts and criteria should I put at the top of my white board before setting out to design my application, that will ensure that should I need to expand my server capacity to cope with demand, that scaling can be performed easily, seemlessly and in discrete steps as demand increases.

    My answer: In a nutshell, decoupled logic.

    The 'traditional' answer. A two, or preferably 3-layer model.

    Ie. Presentation logic; business logic; Backend (DBM) logic. In some circumstances the latter two can be combined, but personally I wouldn't.

    Architect your application from the outset as if each of these three components is going to run on a seperate machine. Even if they are actually going to run on a single machine to start with.

    Note: Everything below is simply my current thinking. I'm (slowly) preparing to resume the web commerce project that brought me to these halls in the first place. So far, I have not even attempted to implement most of this and I'm posting it mostly in the hope that it will stimulate further discussion that will help me, as well as the original poster.

    The layers (as I currently see them).

    1. The front door. A single, well-sorted, well-packed machine running the latest stable version of Apache and mod-perl who's sole purpose in life is to receive requests, pass them on to whatever business unit is appropriate whilst maintaining session state and then serve back a (pre-generated) web page.

      All the html served would, as far as this machine is concerned be static. When a request is received, a thread or a process would be forked and an appropriate token (product id, user id, library reference etc) would be fed (probably via a socket as this makes location transparency easy) to one or more BusinessLogicUnits. The spawned thread/process would then block until it received a return value in the form of a filename. This would be the html to be served. The thread would simply loop, feeding the tokens generated by the sessions requests to the (appropriate) BLU and blocking until the html was available. When the session ends, the state dies with it.

      If anyone has a feel, especially numbers, for how many concurrent sessions I might expect a well configured mod-perl/Apache server to be able to handle given this model, I'd love to hear them.

    2. One or more BLU's. I can see the need for at least two types.
      • Clearly defined, non-customer specific, near static, oft-called, 'product' or 'company' informational pages. These would have little or no dependancy upon the DBM, (prices, dates, phone numbers only) and could be cached, keyed by product-id or page-number. They would be generated from templates but cached for quick delivery. Any major changes to the DBM causes the cache to be wiped and the next call causes them to be individually re-generated anew.
      • Customer specific pages. shopping carts, invoices, purchase history, delivery status. These would be generated, delivered, (possibly cached until session end), and discarded. The generated html would be stored in a subdir named after the front-end session id. The discard effected by the front-end, deleting the subdir when the session ended.
    3. DBM. I'm still a bit sketchy on this one. As far as it goes, I see it like this.
      • One only DBM thread/process/server with write access. This would be served by a queing process listen on a socket, and would feed back success/failure status to the calling BLU directly.

        Many of the larger commercial DBM's would take care of this themselves, but I am as yet unsure about open-source DBM capabilities in this area.

      • One or more read-only threads/processes/servers. These would be spawned on demand and service individual or sequences of related queries and return the results. They would communicated with the calling BLU directly (via sockets) and die when the calling BLU dropped the link.

        The logic here is that this could be a single parent process spawning child threads/processes in a single box or a single parent process on one box handing of to child processes running on several boxes with replicated DB's and background update. Again, the better (read expensive) commercial DB's can handle this internally, but I am unsure of the progress in this area for open-source DBM's.

        Information on the latter would be appreciated.

    Any and all critiques, comments, caveats or congrats gratefully received and voraciously devoured.


    Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!
Re: Server Load
by JaWi (Hermit) on Sep 22, 2002 at 14:52 UTC
    Let's see if I understand this right: you want to determine how powerful your server(s) need to be before starting to write your program?

    If I had to make such a decision, I'd probably ask myself the following questions:

    1. What features does the program need? Heavy database applications can require lots of RAM/CPU.
    2. How many users do you expect to serve? Do you want to create a second Slashdot?
    3. What's the penalty for not serving your customers fast enough? Are they willing to wait, or is your application so mission-critical that you must acknowledge the request within a specified amount of time?
    Based upon these (and perhaps more?) questions, I could deside what amount of servers I would need. Or at least, I could take this into account when designing my application!

    Those few applications I've developed didn't require more than one server to give a reasonable response-time...

    Hope this helps! Greets,

    -- JaWi

    "A chicken is an egg's way of producing more eggs."

Re: Server Load
by jepri (Parson) on Sep 22, 2002 at 15:22 UTC
    The most important thing to consider is what part of the computer you are stressing. If you are writing scientific processing apps, then you are clearly stressing the processor. If you are doing GIS (Geographical Information Systems) work then you are stressing the IO channels. Other apps fall in between.

    If you are doing CPU work then the calculations are trivial. If it's data heavy work then a few minutes with manufacturers brochures will give you a good idea of what to expect.

    But you are probably asking about the in-between stuff, like website subscriber databases. That's pretty much black magic, since you are working with a pretty large amount of data and doing a little bit of processing on it. Looking at the data transfer specs for your machines will give you a good idea of the maximum performance you can expect. But like others have obviously told you, you just have to suck it and see.

    ____________________
    Jeremy
    I didn't believe in evil until I dated it.

Re: Server Load
by Ryszard (Priest) on Sep 22, 2002 at 16:16 UTC
    Depends completely on your application. A neat setup for a web based app is to have 2..n servers sitting behind a L4 switch for load balancing. The servers need not be amazingly gruny beasts, which is where the beauty lies.. You just add low cost machines when you start to lag at the front end.

    If then you need a database, open a nice fat channel from the web servers to a dedicated (suitably tuned) database server on a private network.

    Not specifically answering your question, but perhaps a viable alternative?