I agree. See comments in context. "Denver Braughler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Ed Ryan wrote: > > Some departments would also like to accept online payments from the > > public using a shopping cart or similiar mechanism.
<some cut> > My opinion is that shopping carts are not a priority for ISC to support with Cache'. > Their licensing model is geared toward workstations or deployed intranet applications. > The model is a nightmare for developing and for public www commerce or trying to compete against MySQL and free carts. I have had this discussion/argument going with ISC for 6 years. While I am very fond of CSP, it is not suitable for high-volume, public websites. WebLinkDeveloper, PHP and .NET with a Cache back end are very viable. All of these methods use their own gateway and session mechanism which makes more efficient use of Cache licenses. We have several production websites running WebLink and receive millions of hits per month with a modest license. The key is not needing full control of a Cache process. If you need to use $JOB, you are forced into the one-license, one-user model. This is reasonable, since you are using the full power of a Cache license. The methods above use a pool of licenses which is in keeping with the transient nature of the web. Imagine this: A company wants to implement Cache but has a very small budget. They have 1000 users but can only afford 4 workstations. So, people line up to use the stations, do their work and then go away. They are using a "pool" of licenses. In this case, the pool is physical because of the limited number of access points. This is a poor solution, but might work if only a few people needed to access the system for short periods of time. Now, if some of the users run jobs that tie up the process/workstation for many minutes, problems begin to develop. Users complain and managment either has to create more access points or move the apps to a different platform. So you buy more licenses. This continues until the demand for access and the number of access points reaches a decent equilibrium point. A few users will complain that they need 24/7 access to the system and NEVER want to wait for a machine, so the company purchases a license for their sole use. Now move this model to the web. The same pool concept is a work. But, since using the pooled licences no longer requires physical access to a machine. The software automatically allocates licenses to users on a round-robin basis. If all the licenses are in use (as above), the user experiences a delay. If sufficient licenses are deployed, these waits are a few milliseconds so all is well. If insufficient licenses are available users wait...or experience a failure. Our PulsePoll.com poll app serves millions of lines of javascript per day. However, the average connect time for individual users is virtually unmeasureable. On an NT box, there is not sufficient resolution of the internal clock to time the connection. For most of these users, this is the ONLY relationship they have with our server. The real issue is the failure mechanism. (I know this is a rehash, but Denver is new to the group.) ALL other web technologies simply queue the requests and return the user's data when a license is free. Unless all channels are locked up for a long period of time (which, typically, triggers an error message), people get their data eventually. Under heavy loading, we never have server unavailble (no license slots available) error on our public apps unless (as Denver said above) we have a bug that locks up all our channels. Of course with WebLinks/PHP/.NET, etc all you have to do is terminate the evil process and fix the bug. CSP turns this standard methodoloy on its head. Because of the 15 minute timeout, the system will constantly issue failure messages to users, even when none of the other licenses are using Cache for anything! The user gets a message something like: (to paraphrase) "These guys were too cheap to buy enough database licenses to take your order. Please go away and buy from a competitor. Thank you." The moral of the story is not to use CSP for public web sites if you ever expect any serious volume. A 10 ten year old with a few minutes can launch a denial of service attack that will bring your CSP site to a quick halt, even without runniing a script.. Until ISC decides they want a piece of this market, you must used a pooled solution. One caveat: In terms of scaleability, the CSP with a (real) unlimited license probably has a significant edge over most pooled solutions. Because the middleware tier is actually in the database, the architecture is very efficient and is easy to deploy over multiple machines. If you have the bucks, this is probably the best way to go, even for a high volume, public site. -- John Bertoglio Senior Consultant co-laboratory office: 503-538-8691 mobile: 503.330.6713 fax: 503.538.8691 www.co-laboratory.com
