>But 10 Million a day is the exception - its a supa duppa enterprise. Most of us are working with web apps that hit counts will measure at 10,000/day with no need to scale much beyond 100,000 hits/day in the fore seeable future.
Absolutely. Most people will not build those kind of apps. But it does matter - most people build applications that don't work well on the Web <g>... They do things like run long reports, and do heavy duty data processing in the Web tier where it doesn't belong. In those scenarios, it'll take a lot less than 10 million hits to 'break' an application. In fact with Visual FoxPro in general (and I don't care if you use ASP+COM, Web Connection or whatever) it won't take more than a few badly timed requests to kill a Web application and the entire server. Try running SQL statements that run for 30 + plus seconds at the same time for a while with more than a couple of people trying to hit them and see what happens. It will lock your machine solid at 100% and eventually kill the server if enough requests back up.
That's really what scalability is about. Most applications have at least one long request that has the potential to kill the app. Let me give you even a very simple example - my message board. The app is completely transactional, with small, short requests. But there are two or three requests in there that can take a while depending on how complex of a query users throw dynamically at it. That single request is a potential killer of the app. The reliable way to get around this is to use Aysnc processing and put this sort of thing onto another machine, but if you odn't have a second machine you're stuck with this behavior. VFP will use whatever CPU is available and doesn't care one bit what else is running on the server.
All of this is also true in other environments - long requests are killers. But it's especially bad with VFP because VFP's data engine is so CPU intensive and doesn't play nice in a multi-threaded environment. It basically assumes it's running as a desktop app that's in the foreground.
>I understand the importance of scalability in those cases where its needed. But in most cases it not an issue. Sometimes - capacity requirements can be set for years even decades - and by that time - when scalability may be an issue - then what ever the market offers would probably be purchased. Will NET or Win OS be the platform then? Who knows.
This is true. Sometimes people worry too much about the wrong things. You have to know what you're getting yourself into. I've seen many applications fail because of bad design and that 'unanticipated' problem with one or two requests that's killing the entire app. These things are fixable with externalizing the process, but often there's not enough thinking outside of the box to realize the possibilities.
>The fact is - if you examine capacity - it has remained pretty much the same.Very few at the highend of the demand curve - almost everybody else at the low end. Sure the big guys - like Amazon or Ebay may want to migrate from ASP or JSP to NET. But for most internet business and services - CGI will be enough for quite sometime. When you look out an office window on the mainland - you see a lot more Toyota Carollas than you do Hummers. When the Carolla gets old - usually the owner will simply replace it with a newer Carolla. Excess capacity can be a liabilty. A Carolla tire only costs 30 bucks - a Hummer tire will cost you three hundred. A lot cheaper to maintain the Carolla!
Not sure I get the analogy. First price is hardly an issue in any of these since the solutions are either free or negliable in cost compared to the overall project costs. It always cracks me up that someone won't pay $399 (in teh case of Web Connection for example) due to price, when they are taking on a $50,000-$100,000 project. Compared to time anything under $1000 is a negliable expense. The real expense is your time...
