Hi All,

I'm currently working on a customer doing some performance tuning. They expect a few hundred more users to start using the system in the next few months. We're trying to come up with a list of recommendations regarding how to best utilize their existing web servers hardware (IIS6, 12Gb RAM, 8 processors).

Is there any rule of thumb that vinculates the number of users and the number of worker processes? Something like "every x number of web users concurrently connected to the system a worker process is recommended".

Thanks.

There are a few things to consider about multiple Processes:

a) Each Process uses a different pool of Memory, so you could better utilize the Available RAM (probably about 1.5 Gig per SLX Instance).

b) In case your system crashes (not the OS, but the application), only the users logged into a given instance would be affected.

c) Since you have Multiple Processes, you can assign them to run on Specific Processors

d) There may be issues with Caching and data updates (e.g. a Record update on one instance may not show the updates on another one if the record was loaded and cached prior to the update).

e) You should use a Load Balancer to distribute the users across your available Instances. (Hopefully one smart enough to tell the load on each instance, and/or whether or not it is available).

We recommend that the SLX database be loaded into SQL Server Memory with room for temp tables.

Put the SLX OLE DB Provider on the C Drive of the SQL Server if possible.

Don't use Raid 5. (RAID 5+0 or 1+0 much faster)

Those solid state drives are fast......

Remember....if you take a Rocket Oldsmobile 455 cubic inch V8 engine and split it into 8 VMWares you are geschrooot.

1 Web Server for every 75 users and we use a load balancer in front.

The traditional SLX App server we use for Speedsearch, Library, Documents, et al. Still putting Web Reporting on a 32 bit box of its own.

Alternatively, stick it all on an IO:Fusion drive - even faster than SSD

Hi guys, I really appreciate your kind input - there's a bunch of information for me to process there.

But i'd really like to focus on sizing number of worker processes per number of users, which is what i'm trying to come up with now. 75 users per worker process sounds close to what i have heard before. Any other experiences or rules of thumb with regards to that?

Raul, thanks for the detailed recommendations. They are running a load balancer already, and they have pretty big servers (8 CPUs, 12Gig RAM), so I think their environment is the perfect candidate to add more logical websites before adding more hardware.

RJ, thanks for the detailed info. I'm not entirely sure what you mean by "Put the SLX OLE DB Provider on the C Drive of the SQL Server if possible.". I thought the OLE-DB Provider had to be installed locally on the website, otherwise how could SLXClient access it???

That doesn't make sense....if you have 10 webservers you only install the SLX OLE DB Provider once.....right?

So I mean INSTALL THE SLX OLE DB PROVIDER ON THE SQL SERVER IF AT ALL POSSIBLE. It's MUCH faster. This is the Connection Manager stuff, not the data link stuff.

By SLX Ole DB Provider you mean APP Server?

I guess.....the install folder clearly states OLE DB Provider.

SalesLogix OLE DB Provider.msi

As far as I understand, the ole db provider is installed on every computer that needs access to the saleslogix database, or am I wrong? Otherwise, how can you reference SLXOLEDB.1 provider to make a connection if its not locally installed? You got me puzzled...

I'm talking about the CONNECTION Manager......not the datalink.

Take a look at the Services on a client machine.....then take a look on the 'App' Server.

SalesLogix Server

SalesLogix System Service

ok, so i guess we are talking about the same but from a different perspective - I come from a developer background, so that may explain why I use terminology different to you.

For me the ole-db provider is the "driver" that allows a certain computer to "see" a saleslogix server and hence make a connection to it using the SLXOLEDB.1 provider.

So, if i understand you correctly, you're basically recommending to install the app server on the same box as the sql server, right? I thought that Sage specifically recommended the other way around - having a separate box for that. Any inputs?

Thanks for your kind help.

They used to - but there is no longer any need. It used to be n-tier but they went away from that due to speed issues. Nowadays, the connmanager deals with physical access to SQL Server. It then deals with licensing and a few other tasks but has no real overhead and, by virtue, no real need to have its own server.

In 7.5.4, you can use memcache rather than caching the nHibernate data in the session state.  This saves memory from the worker process and also allows all of the processes to see the same data.  In PSG, we reccomend setting up the cache server on a different machine than the web and DB servers.  In your case, I would allow for as many worker processes as will fit in memory minus O/S requirements, etc....  With 12gb, this points to around 6 - 8.