-Mn and -Ma

[Cringer]

[2011/12/30@13:30:41.421+1300] P-2108 T-2112 I BROKER 0: (4257) Maximum Number of Clients Per Server (-Ma): 12.
[2011/12/30@13:30:41.421+1300] P-2108 T-2112 I BROKER 0: (4258) Maximum Number of Servers (-Mn): 5.
[2011/12/30@13:30:41.421+1300] P-2108 T-2112 I BROKER 0: (4259) Minimum Clients Per Server (-Mi): 1.
[2011/12/30@13:30:41.421+1300] P-2108 T-2112 I BROKER 0: (4260) Maximum Number of Users (-n): 51.

How many users do you really have? (This is set up for 60 although -n says 51.)

You are running client/server connections with a default configuration. That's probably a bad idea.

I prefer to have no more than 2 users sharing a server - 4 or 5 at the very most. And I've been known to go with a 1 to 1 mapping. For 60 users and 2:1 use -Mn 30 -Ma 2

-Mi 1 is fine -- that means "round robin".

The above is a quote from another thread by Tom, but I was wondering what the justification is for 2 users sharing?

Our settings (from consultation with Progress) are:

[2012/01/09@07:15:47.625+0000] P-792 T-5768 I BROKER 0: (4257) Maximum Number of Clients Per Server (-Ma): 6.
[2012/01/09@07:15:47.625+0000] P-792 T-5768 I BROKER 0: (4258) Maximum Number of Servers (-Mn): 162.
[2012/01/09@07:15:47.625+0000] P-792 T-5768 I BROKER 0: (4259) Minimum Clients Per Server (-Mi): 3.
[2012/01/09@07:15:47.625+0000] P-792 T-5768 I BROKER 0: (4260) Maximum Number of Users (-n): 1001.

Cheers for any input.

 

[RealHeavyDude]

IMHO it is a compromise. The more users you serve with a single remote server the less performance the individual users get. On the other hand, the more remote server processes you have on the OS the less resource a single remote server process gets. There will be a break even where the performance drops when you either have more remote server processes or more users per remote server process. The 2 justification comes from experience depending on how many remote users you connect to the database and what they do. My rule of thumb is a few users are served best with dedicated remote server processes whereas many users need to share them. If you have power users vs. users that are mostly idle then you could direct them to different login brokers. The power user login broker would have less users per remote sever whereas the idle user login broker would have more ... Heavy Regards, RealHeavyDude.

 

[Cringer]

Thanks RHD - I'm guessing it might be a case of leaving well alone for now then.

We have a lot of AppServer processes that do a huge chunk of processing of data.These are either fired off by the user (such as building query results), or by batch processes to process invoices and so on. Is it possible maybe to set the AppServer login broker to have different settings to the users such as you describe above? And how would you go about setting this up?

 

[RealHeavyDude]

From what you ask I'll take it that the AppServers are running on the same machine as the database. In that case you should always connect the AppServer agents via shared memory (self-service clients). IIRC self-service clients are equal to a remote server when it comes to resources. Anyway, self-service clients don't use the network subsystem (which is the slowest subsystem possibly involved) at all and thus -Mn, -Mi or -Ma are not relevant. Therefore connecting the AppServer ia shared memory will give the agent the highest possible performance compared to what any user will get that is connected via the network subsystem to a remote server. I strongly recommend you to connect the AppServer via shared memory whenever possible. Heavy Regards, RealHeavyDude.

 

[Cringer]

Ah merci! That makes sense - Most of them are self-service clients so that's ok. The ones that aren't aren't for a reason.

In which case our -Ma/-Mn settings are probably ok for what people are generally doing.

 

[TomBascom]

The "more resources" argument is not, IMHO, very persuasive -- the basic resource in question is RAM and RAM is readily available on almost all systems. CPU ticks are even more available.

I would disagree about your current settings being "ok". They may not be "broken" (after all they seem to work and nobody is complaining...) but IMHO -Ma 6 is hardly ever a good choice and -Mi 3 is silly.

-Mi 1 means that as sessions connect they are attached (more or less) "round robin" -- that is the first connection goes to server #1, the next to #2 and so forth until all 162 of your servers are used. The 163rd connection is then added to server #1 as the process repeats itself.

-Mi 3 means that the first 3 connections go to server #1, connections 4-6 go to server #2 and so forth. Ever server always has at least 3 connections.

You should also think about SQL-92 connections. Are there any? If there are are you using a shared broker or do you have dedicated 4GL and SQL brokers (hint: a shared broker is the wrong answer...) If you are using a shared broker then the -Mi > 1 hack makes a certain amount of sense since any particular server can only connect a homogenous client type (4GL or SQL). But that is enabling a bad practice. Best practice is to use dedicated brokers (lookup -ServerType and -Mpb).

You can also use dedicated server groups to isolate power users from ordinary users or create other arbitrary groupings. This can be quite handy for administrative and monitoring purposes.

 

[Cringer]

Thanks Tom. We do have SQL-92 connections. Probably quite a lot of them. We have some set for Architect. But those use dedicated brokers. As for the others I'll have a look later when the server's free. I suspect we may well be getting a consultant in in the near future as we really don't have the expertise.

 

[Rob Fitzpatrick]

You mentioned that you consulted with Progress on settings. Were they aware of your SQL-92 connections? If so, what did they recommend for -Mpb? Has it been specified?

 

[Cringer]

I've no idea I'm afraid - that was before my time at the company.

 

[Cringer]

In that case you should always connect the AppServer agents via shared memory (self-service clients).

Sorry for another n00b question, but how do I check if they are connecting as self-service clients?

 

[RealHeavyDude]

For one you can see it in PROMON in the user list. There is a type ABL or APSV that is prefixed with SELF or REMC. I am not too familiar with the VSTs, but I guess you will get the same information from them.

Heavy Regards, RealHeavyDude.

 

[Cringer]

Ah yes of course - yeah you can get it from the VSTs.

 

[Cringer]

So all the connections on the server are of type SELF apart from prowin32.exe connections (these are scheduled tasks). I'm guessing there's no way of making these self service is there without making them appserver calls?

 

[RealHeavyDude]

Any client can connect to the database as a self-service client as long as the database resides on the same machine and the Progress/OpenEdge version they are running matches to the patch level.

In order to connect as self-service client you just specify -db full path to your database (.db file) as your connect parameters. As soon as you specify -H and -S you would connect as remote client - so omit them. And here you go ...

Heavy Regards, RealHeavyDude.

 

[Cringer]

Now that's interesting. I shall have to give that a bit of a test. We currently use pfs to connect to the databases, hence using -H -S etc. But if it's as easy as that...

 

[Cringer]

Just changed my connections in OEA for my working copy of the database to connect via self-service and the improvement in performance is pretty staggering.

 

[Cringer]

What does the "Employ Direct I/O" option on the DB Configuration do?

 

[Rob Fitzpatrick]

The -directio param determines whether the database uses OS caching. It could help or hurt, depending on several factors like OE version, OS type and version, virtualization, etc. You need to do testing on your system with your application to determine its effect. I would say if in doubt, leave it off.

It sounds like most of your clients now are (or soon will be) self-service, meaning that you only need remote servers for SQL clients, and are now probably over-provisioned on remote servers (values for -Mn, -Mpb, -Ma, etc.). Once you have finished reconfiguring your clients and verifying in promon that they are indeed self-service, I think you will want to revisit your DB startup params and adjust accordingly. That RAM you're currently spending on up to 162 servers would be better used in your DB buffers (-B, -B2, -bibufs, -aibufs, etc.).

 

[Cringer]

Thanks Rob - the vast majority of the clients are still remote connections. We have 250+ users in this office alone, along with a number who connect via terminal servers. The changes I made yesterday probably affect about 20 connections.

I agree we need to revisit the remote servers settings - we need to do that anyway as I'm convinced they're wrong. The trouble is more finding the time and justifying it. And also my lack of knowledge of these things. Plus I'm not the DBA - just trying to help out!!