I hear stories like this, and I have to wonder what your definition of
"scale" is. Obviously, we don't have the full story, but this snippet
makes it sound like you define "scale" to mean "can sustain unlimited
amounts of traffic without slowing down". I'm sure you don't mean that,
but it sounds like it.
What you are probably saying, is that as load increases, page response
time does not grow linearly. It instead grows asymptotically, rising
faster then the increase in load, to an infinite page response time.
In my experience, this is true. We also have this problem with
Netgravity (ad serving software). Our experience shows that CF scales
linearly with load, up to a point, then falls apart. CF Solaris seems
to do a better job at this, perhaps suggesting that the problem is
partly associated with the OS, or at least Allaire's interaction with
the OS.
We've observed that examiniation of this linear->asymptotic can lead to
a correct setting for the number of threads, more or less preventing
this problem. It helps if you are running a single or a few
applications on a box, not in a shared server environment. By setting
the number of threads to the proper level, the machine won't go all
wonky, and requests will sit in a queue all nice and happy until they
can get processed.
We've also observed that CF scales pretty much linearly by processor
speed.
We've observed that CF does not scale very well (vertically?) with
additional processors. This could be an NT problem, but CF doesn't even
scale evenly with the graphs and stats I've seen of NT's scalability.
CF scales (assuming you've written your application well) very well
(horizontally) by adding machines. Course, this isn't that hard, and
depends on your database server or other shared resources don't become
bottlenecks.
Of course, all this depends on having coded the application well, and
locked everything properly, etc.
This also all depends on realizing that if your application takes 200ms
per page (on average), the best you EVER will get out of that box is 5
requests per second. If you expect to serve more, there's nothing you
can do - you have to add new boxes or faster boxes, or make the code
faster somehow.
This isn't scalability, this is just performance. Dynamic page serving
will always be and order of magnitude or two slower then static. Even
serving HTML file thru CF server (no CFML at all) is an order of
magnitude slower then just serving them up from the webserver - this is
due to all the application overhead.
So, Matthew, if you divided your expected/actual peak traffic for an
hour by 3600 second/hour, how may ms per page did you have to have the
pages serve in?
You are doing 500K per day, lets say 50K peak in one hour. This is 13.9
(lets say 14) pages per second, or about 71ms per page - under load.
Yikes.
I would have spread this between about 4-6 servers (600+ PII x2, 512MB
RAM, Mirrored 9GB drives - say Dell 2450's).
Matthew Taylor wrote:
>
> On the contrary we all have been writing code, not just CF, but ASP, C,
> Perl, and Java for quite a few years. We even had a consultant from Allaire
> come out and do a code review. We passed with flying colors, under heavy
> load, CF bogs down big time. I'm not sure what you consider "heavy" but we
> get over 500,000 page views per day, between ucomics, doonesbury and
> garfield. The problem became so bad that we wrote our own scripts that
> generate static htm's nightly. Our site is now 75% static and runs about
> 75% faster. I'm not knocking CF at all it's great for what it does do, but
> it does not scale. I'm sure there are some others out there that agree.
>
> -Matt
>
> Matthew-
>
> I don't agree with your statement that CF doesn't scale. It will scale as
> well as the code which is run on it. Possibly these people working for busy
> CF sites are not experienced in writing scalable code?
>
> -
> jason.
>
> ----- Original Message -----
> From: "Matthew Taylor" <[EMAIL PROTECTED]>
> To: "CF-Server" <[EMAIL PROTECTED]>
> Sent: Wednesday, January 24, 2001 3:48 PM
> Subject: RE: Page execution time too long?
>
> >
> > 150 millisecs under no load would cause some alarm for me personally.
> We
> > tested our pages under no load and they ran in under 100 millisecs, under
> > simulated load (silk performer), they jumped to well over 1,000. As I'm
> > sure anyone working for a busy CF site will tell you, Cold Fusion does NOT
> > scale well at all. If you're concerned about page times under ideal
> > conditions...it's all down hill from there.
> >
> > Matthew Taylor
> > Web Developer
> > 617.868.0009 ext.216
> > [EMAIL PROTECTED]
> > http://www.uClick.com
> > http://www.uComics.com
> >
> >
> >
> > -----Original Message-----
> > From: Allan Pichler [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, January 24, 2001 1:38 PM
> > To: CF-Server
> > Subject: RE: Page execution time too long?
> >
> >
> > IMHO 150 millisecs is not too much. As far as a general guideline on the
> > maximum execution of pages i would have to say that depends on application
> > you're building. I have had routines that took several seconds to process
> > but that was still acceptable since it was performing some relatively big
> > calculations.
> >
> > Allan Pichler
> >
> > -----Original Message-----
> > From: Kola Oyedeji [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, January 24, 2001 7:29 AM
> > To: CF-Server
> > Subject: Page execution time too long?
> >
> >
> > I wondered if there are any guidelines for a maximum amount of miliseconds
> a
> > page should take to process. I have a page which takes 150milliseconds to
> > execute is this acceptable?
> >
> > What do others recommend should be the maximum execution time of a page??
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
