[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference ulysse::rdb_vms_competition

Title:	DEC Rdb against the World

Moderator:	HERON::GODFRIND

Created:	Fri Jun 12 1987
Last Modified:	Thu Feb 23 1995
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1348
Total number of notes:	5438

991.0. "RMS/Corvision to Rdb/Corvision" by PANIC::NAQVI () Wed Sep 18 1991 11:43

                   
    Hello

    We have a customer who is running an RMS/CORvision application. At 
    present the application supports 120 users, but not all at the same time.
    According to the customer, after about 50 users have logged on, the system
    becomes saturated denying access to any more users. In other words after 
    about 50 users the system cannot be used by any more users.

    The customer is in the process of deciding to use Rdb to see if this
    would help improve access to the system. Whatsmore, in future the user 
    population will increase to 250. However, the local Corvision consultant
    is advising the customer against this course of action. In their words, 
    this is all down to Rdb because it lacks a multi-threaded server agent.
    To me this sounds to be an opportunistics excuse on Corvision consultant's
    part. 

    I have been asked by the customer to provide an honest answer as
    to whether the Rdb solution would be better than the RMS solution.
    Specifically, is their a max. limit on the number of users that can 
    effectively attach to an Rdb/Corvision application. Also is the Corvision
    consultant being economical with the truth.  

    Reading through past and present Rdb notes, I can see that their is a 
    wealth of Corvision knowledge out in the field. So I am asking for your 
    help if: 
    
    1. Someone has seen this before?
    2. Does anyone know of any large sites using Rdb and Corvision and 
       whether or not if they have encountered a similar problem(s)?
    3. Their a known upper limit on the max number of users that can
       attach to an Rdb/Corvision application.
 
    Many thanks in advance

    Muhammad
    11/9    
    
 
    Ps. This note has been cross-posted from Rdb_40.

T.R	Title	User	Personal Name	Date	Lines
991.1	Introduce RALLY	4GL::KIRK	I've lost my hidden agenda!	`Thu Sep 19 1991 16:38`	9
	Muhammad, I'm afraid that I can't answer the question about Corvision, but this may be a good opportunity to introduce your customer to RALLY, and tell them how well RALLY performs with Rdb databases. If you would like more information, please do no hesitate to contact me. Best regards, Richard
991.2	Introduce them to ACMS	BROKE::THOMAS	Anne Thomas DTN 264-6094	`Mon Oct 07 1991 23:19`	10
	The problem is not in the database, it's in the application. CORvision isn't able to support the large number of users. And if CORvision says that Rdb won't improve performance, they're probably right. If you're looking for high-volume online transactions, then go with ACMS. ACMS allows many users to share the same application process -- what the CORvision people referred to as multi-threading. Unfortunately, I doubt that CORvision supports ACMS servers. Anne
991.3	And Corvision does support ACMS.	SNOC01::GADSBYCHRIS	Chris GADSBY @SNO <IPS SG>	`Fri Oct 11 1991 00:35`	3
	The local Corvision product manager tells me that in fact Corvision does support ACMS. The current version allows calls to ACMS, the next version will be able to generate ACMS applications.
991.4	'Calls to ACMS'	BROKE::HIGGS	SQL is a camel in disguise	`Fri Oct 11 1991 16:15`	14
	Speaking as one of the V1 ACMS developers, this sounds to me like the person who told you this does not understand what ACMS is. ACMS is not just a set of callable facilities; it's an environment for applications. You don't just take your regular application and add calls to ACMS into it. I think the basic question that would be interesting is 'can a Corvision application reside in an ACMS server process?' ? If Corvision people refer to ACMS server usage as multi-threading, then there may be some misunderstanding there, too. ACMS server processes are typically shared by multiple users in a serially reusable fashion. That is, any given server process is being used by one user at any given time, but when that user finishes with the server process, it can be reallocated to another user. This is not the standard meaning of multi-threading.
991.5		BIGUN::ANDERSON	The Unbearable Lightness of Being	`Wed Oct 16 1991 04:00`	6
	I think that mean that currently they can submit ACMS tasks (big deal!). Its about the same level of support that RALLY has for ACMS.... The local guy told me that the next major release of CorVision wont have the ACMS generation in it, it will be the one after that (sounds like a year away).
991.6	But I LIKE ACMS!	TPSYS::BUTCHART	TP Systems Performance	`Thu Nov 14 1991 19:07`	15
	re .5 Late answer, but being able to submit tasks to ACMS can be used (if your product/application can be configured properly) to greatly extend performance by distributing the application and controlling contention for the file system/database. If the performance bottleneck is due to display processing (as in forms), the ability to distribute that part of the application to a bunch of relatively cheap systems is very valuable. If the performance bottleneck is due to contention for the file/database resource, a controlled set of ACMS server processes can provide better performance for your users than N individually connected user application programs. /Dave