Ermm? eww. A gig of physical ram will always help, but a well coded high traffic site on IIS and win 2k with a high percentage of tra ffic opperating under ASP/CFML will run fine with 512. It won't be spectacular, but it'll run fine. A gig of ram to a static content site on apache? Somebody has not only stuffed the config, they've screwd the pooch significantly. Or you're talking about Microsoft/Yahoo's static content maybe. If you need that much ram for a static app, you need a load balancing cluster for your dynamic content.
I've got a server being reviewed atm thats handling a million hits a week across 6 site instances in almost completely CF/ASP driven content with 512 on an older hardware set. The new stats package they rolled out more or less killed it, but as a webserver? it ran fine. But more ram will allow for abuse. As far as patches go? Call me paranoid, but after dealing with Microsoft, I never install any patch, upgrade or hack on a production server untill its been through the ringer on the staging and dev boxes and load tested with the app's in question. Frankly? Macromedia's track record isn't THAT much better. CF 4.0 - 4.5 upgrades, sp's for cf 4.5? *shudder* I spent a serious ammount of time living off caffine after some upgrades were done without testing. Updater 2 for CFMX caused me quite a number of problems with its security harden, and I can speculate about a number of other problems it could cause, just because of some unexpected kickers. (Most notably, I secure our CFIDE directory by placing it on a nonstandard port, and NTFS locking it down. After the updater, the servers that had previously not had admin passwords now required them, the workaround edits of XML files no longer worked, the password was non retrievable at the time - I've since been told that there's a method to decrypt the stored admin password hash. but regardless, not knowing that at the time I had some fairly severe issues (The originally declared and recorded password had been changed by factory services - hence the main reason we were keen to get the updater into production on shared servers).). suggesting that because its MM means that your server won't hit an unforseen snag and BSOD perpetually after you hotfix, or disable/alter core behaviour functionality in your app just because MM tested it extensively largely speaks of not having been a server admin in a high end environment. just 'fixing' the code is a lovely idea, but if you're opperating under a rollout and versions model dealing with an extensive app and a few thousand, or a few tens of thousands of lines of code, and it happens to be a core element that you need to alter? its not exactly an easy process to just 'fix' it. Especially not if you have QA criteria to meet before you can deploy. After your 3 am rollout of a hotfix or service pack or updater, there's nothing quite as charming as calling your dev lead, your proj manager and your DBA and saying 'Do you chaps mind coming in to fix some code before the start of business to perform a major rewrite, approve and structure and rollout?' - Its the general reason why you always do rollouts right after backups finish, so you can roll back in a damn hurry. ----- Original Message ----- From: "Erik Yowell" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Thursday, March 20, 2003 2:45 PM Subject: RE: CFMX Giving up in high strain conditions. > Uh - first of all: Patch your servers! > > I hated that philosophy in corporate America and such. Sys Admins > telling me they were "anti-patch" because of the existing code set; and > they had to spend "time and effort" reverse engineering and testing it. > Imagine their surprise with the first CodeRed/Nimda hit. > > This always did seem kind of silly - not to jump on the bandwagon, but I > highly trust Macromedia to do this testing and release it when they see > fit. Why else would I be purchasing their products? If it breaks code, > too bad - fix the code. Most likely code that breaks after an updated > has been "hacked" in some non-conventional form, anyways. Plus, it's > much easier to fix code on a solid app server than a gimped one. > > Second - High hit and only 500mb of ram??? I HIGHLY suggest you put more > RAM in those puppies if it's getting smacked a lot; at the very least a > gig or two, maybe more. Most high traffic sites I've seen dedicate one > whole gig just for a 'dumb' Apache html/graphic server. > > Erik Yowell > [EMAIL PROTECTED] > http://www.shortfusemedia.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
