Eric, Your last paragraph is as bang on as it gets. The batch system was deployed for just that reason and as such is the reason why we are reluctant to devise any type of AUP or SLA for it. It's a live sandbox, so its not meant to be the bomb proof environment that the LIVE system is. But there are API rate limits and performance is monitored very closely by our Operations team.
Historically, things that have gotten people knocked off this system are scripts that scrape the batch RWI, this can be extremely heavy and expensive depending on how many sessions a particular script invokes. On the other hand I've seen some clever scripts (really macros) that are light and effective and really useful to some resellers. The batch server *should* be used for development of live scripts, special projects or anything that requires batch processing of a high volume nature. It should not be used (due to its *unsupported* nature) for any customer facing processes (i.e. your main domain registration website etc.) Hope this helps. Cheers, James -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of WebWiz Sent: Tuesday, January 06, 2004 4:23 PM To: [EMAIL PROTECTED] Subject: Re: batch system access limits Roger B.A. Klorese wrote: > Tucows is creating problems for their customers by underconfiguring > and dumping the blame on a user who is trying to use resources within > their allowance. That's quite a leap to say that because they don't invoke any restrictions until you cause problems, they must be "underconfiguring and dumping the blame on a user". Admittedly, I'm not a big user of the batch system. But I'm not sure I get how a rate limiter that only comes into play when you are beating the ever-loving spit out of a system is necessarily a bad thing. I understand that you feel better with explicitly defined limitations. Some people would prefer that the police only come around when there's a problem. As I understood it, the batch system was designed as a sandbox where folks could run automated scripts to do things without concern that it was going to impact the systems devoted to the main line of business systems. As such, it was always pretty clear to me that there were no guarantees on availability, but that you had pretty much free reign to try out things that you would never consider trying on the primary system. I don't think that Tucows has published anything contrary to this understanding, but I'm certainly willing to be proven wrong. Regards, Eric Longman Atl-Connect Internet Services +----------------------------------------------------------+ | Atl-Connect Internet Services http://www.atlcon.net | | 3600 Dallas Hwy Ste 230 PMB288 770 590-0888 | | Marietta, GA 30064-1685 [EMAIL PROTECTED] | +----------------------------------------------------------+
