OI Max Users - your experience? (OpenInsight Specific)
At 21 JUL 1998 06:20:41AM Andrew P McAuley wrote:
Greetings!
Has anybody had experience with a LARGE amount of concurrent users on an OI or AREV platform? By large I mean 2 to 3 hundred concurrent users?
TIA
amcauley@sprezzatura.com
World Leaders in all things RevSoft
At 21 JUL 1998 10:49AM Nick Stevenson wrote:
Not quite what you are looking for, but… Our largest 'site' has roughly 175 concurrent users, BUT they are not all on the same database. This client has 7 database servers, connected around the country using a WAN. The largest LAN site on this network has a maximum of 65 concurrent users (gleaned from NLM stats). We have very few problems with these databases, with GFE's on index tables ranking number one when a server crashes (all run the NLM). Our biggest headache, tho', is the volume of network traffic that is generated. OI seems to generate a huge amount of IPX packets that are not directly data-related, (and I have my own opinion of what they really are). We have traced these packets with a Lanalyzer (network 'sniffer') and still cannot explain properly what they contain. To retain performance we have had to be really careful with all I-O requests and to implement our own cacheing routines. Indexing has proved to be totally reliable. We use dedicated indexing only - no flushes are allowed in code. As I
said earlier, the only database hassles we have is when a server crashes and nukes the bang tables.
Our app is fairly big -
850 OI forms
6400 event scripts
1080 stored procedures
450 database tables
218 indexed columns
All in all, we are really very satisfied with this 'site'. We use OI3.6.1 and the NLM1.5 on all servers, and look forward to OI3.7!
At 21 JUL 1998 01:09PM Andrew P McAuley wrote:
Cheers Nick! Appreciated
At 21 JUL 1998 01:33PM Aaron Kaplan wrote:
I used to work at a site where we had about 250 users on two servers, with mulitple ARev EXEs sharing one set of data.
Big enough for you?
akaplan@sprezzatura.com
At 21 JUL 1998 02:10PM Andrew P McAuley wrote:
Could be - my concern is that if 300 people are piling data into an indexed file, there will be massive contention for record 0 in the !file, thus slowing down saves…
any thoughts?
At 21 JUL 1998 02:53PM Aaron Kaplan wrote:
Well….this is all going from memory, I left this place in 1993 but here's how the system went.
ARev 2.11 system stored on two Novell 3.11 (latest and greatest at the time) servers. Each Novell server contained a 255 user EXE and it's own copy of 'REVBOOT' (Templates, Popups, Messages, etc.). Real data was stored on either server. Users were wired into one server and ran the ARev off that server. The data was split into two groups based on access and linkage and seperated that way. The idea being that users would rarely go to the other server for information. Didn't really work that way though.
Anyway, at first there was one dedicated indexer for the system. Eventually, it was split into two indexes, one for each server. I think it was later split even finer into multiple indexers per server, but memory is a bit shady here.
I don't recall many 0 locks, but we did encounter them infrequently. Nature of the software was order entry/inventory processing, so there were always records being created in the sales order index. However, this was the index that seemed to be the stablest.
We elimated most of the troubles when we were on 2.03 by going to the !less index update (which, sad to say for all you still on 2.03 is no longer available).
There were more troubles with group 0 locks and hanging systems than there was with indexing, but that's a story for another day.
Personal opinion is, if you are fearfull of one heavy transaction file getting dumped on, set up a dedicated indexer just for that index and it will always be up to speed. Going for the NLM will help since the station will generate oodles of traffic.
If they have so many users, they'll probably have a few extra spare machines they can settle up for the indexers. Jamming him pretty close to the server, or even right on the backbone could make a difference as well. The number of indexers should be related to the amount of trafic and bandwidth avaible. Done correctly, you should never be more than 5 - 10 seconds out of date.
akaplan@sprezzatura.com
At 21 JUL 1998 10:56PM pedro azpurua wrote:
I would think this is a sql server job.
ppa
At 22 FEB 2005 07:18PM support@sprezzatura.com wrote:
Resurrecting an old thread - since we posted this one of our clients has load tested a copy of OI on a single server with 850 users and reported no noticeable degradation over 250 users. Naturally 250 had no noticeable degradation over 10 etc…
(I was looking for another thread and came across this ;)
support@sprezzatura.com
The Sprezzatura Group Web Site
World Leaders in all things RevSoft