Jadrap

[ConvertFromOldNGs]

by Stephen >> Sun, 4 Jul 2004 23:05:46 GMT

Hi,
I need straightening out.... Why am I bothering using Jadrap?
Everything runs soooo much quicker, both applications and the development environment, when Jade is running in singleUser mode rather then multiUser mode using Jadrap.
I have been playing around with our test system, and rather than having Jadrap, 6 web monitors, background app and jadapp (~15 users) I tried making it singleUser only running Jadapp. (The WebMonitors, and background app were all started as thin clients, rather than as fat clients.) Not only did it free up more licenses (cache coherency thing which we use, uses an extra license for each node), but the performanace increase was extremely obvious. Everything ran much quicker than it did in multiUser mode. So it begs the question... why am I bothering with Jadrap? I could understand the necessity if WebMonitors or Jadapp were running on different servers, but with everything running on the one server why would you NOT want to go singleUser? I realise serverExeceution methods run on the Jadrap node, (but a search using a serverExecution method, is still slower than a search in singleUser mode...) so what else that I'm missing here?

Thanks
Stephen Persson

[ConvertFromOldNGs]

by cnwrwm1 >> Mon, 5 Jul 2004 0:24:45 GMT

If you are using TCP/IP as the RPC transport (in multiUser mode) then you'll get a significant boost in performance by changing to the shared memory (JadeLocal) transport for this, and the performance difference between single user and multiuser won't be so marked. Otherwise your statements are valid. Note that if the application is managed using the JADECare tool set, we currently don't support management of singleUser applications. Also in JADE 6, the AutomaticCacheCohenerncy feature removes the need for CacheSyncer applications, saving you licences.

Cheers

Richard

[ConvertFromOldNGs]

by allistar >> Mon, 5 Jul 2004 1:46:25 GMT

As Richard has mentioned in JADE 6 you can turn on cache coherency to remove the need for a caching application on the server.

In your situation it seems that running a single user app server has more benefits than drawbacks. There are a few limitations to running a single user app server though (which may or may not impact your situation):

- you can't run any fat clients. This includes ODBC connections and any applications that use the JOMAPI (like COM components that access the database).
- the application server is doing the processing for all clients connected to it. There becomes a point where having too many clients connected to one app server will start to noticably degrade performance (for one of my clients applications that was around the 25 user mark). Above this number it is recommended you run two app servers (which you can only do if you are running jadrap/jadserv).
- you can't distribute processing over multiple servers.

From what I understand when running a single user system all of the object locking systems are not used, which improves performance considerably (although that's probably not the only reason for the extra boost).

Regards,
Allistar.
--
------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------

[ConvertFromOldNGs]

by Stephen >> Mon, 5 Jul 2004 2:10:00 GMT

The only fat clients we need to run are the web monitors and background processor. Which are at the moment happily running as a thin client.

Our system does use the Jade AutomaticCacheCoherency option.
However I thought it was this was the "clientBackground" application, cthat takes up an extra license on each node. Is it not? Unless I am mistaken (and therefore very unobservant) I thought this clientBackground only appeared after I upgraded to Jade6, of which the whole time I have had CacheCoherency turned on, hence the assumption it was this that used the extra license on each node.

However it unfortunately looks like I may have to go back to using Jadrap, damn it! I use a serverExecution method to copy files from the client back to the server, and if the serverExecution HAS to run on Jadrap then that forces my hand. As I am aware there is no way to force execution to the JadApp rather than JadRap is there?

[ConvertFromOldNGs]

by cnwjhp1 >> Mon, 5 Jul 2004 2:35:08 GMT

Stephen,

The clientBackground task runs whether you use AutomaticCacheCoherency or not. Whether this was newly added for Jade 6 or only newly visible, I don't know.

All methods run in the app server - that is not the issue. In a thin client app, files are deliberately transported to the presentation client unless you specify File.usePresentationFileSystem=false. Doesn't this work with a singleUser appserver?

Cheers,
John P

[ConvertFromOldNGs]

by Stephen >> Mon, 5 Jul 2004 2:58:28 GMT

Thanks for that - I didn't even think to use the usePresentationFileSystem setting. The method to copy my file to the server is a global method I wrote literally years ago, and just used a serverExecution method (before the usePresentationFileSystem option was available).
I have rewritten this method to use the usePresentationFileSystem option and it does work correctly with a singleUser AppServer. Thanks!

[ConvertFromOldNGs]

by Stephen >> Mon, 5 Jul 2004 3:28:35 GMT

Excuse the stupid questions, but this is stuff I have never really fully grasped how it works, and I'm on a role...

If all thin client code is executed on the appServer, why do we get such large performance benefits using serverExecution methods for users that are connecting via a thin client? Fat client I can understand, but why thin client? As a matter of habit, I have always written code to do anything database intensive, such as a searching, data filtering, etc... using a serverExecution method, then returning the results back to the client, rather than having the client do it, for obvious performance reasons.
If I take the serverExecution off the end of the method, so it runs on the client, it is always considerably slower. So if the data is not being sent to the thin client, and code execution happens on the server anyway (JadRap and JadApp are running on the same server) I wouldn't have expected to see such a large difference in the times between a serverExecution method over a clientExecution method.
Is this difference in time purely the time it takes to copy the data from the JadRap node to the JadApp node?

[ConvertFromOldNGs]

by cnwjhp1 >> Mon, 5 Jul 2004 6:39:34 GMT

The rap, appserver and fat client nodes are all "Jade nodes", ie they run the Jade Object Manager (jom) and the Jade Interpreter. Thus they all have object caches, method caches, etc and they can execute Jade methods.

The presentation client node does not have these, so Jade objects and Jade methods are not stored there. A great deal of "smoke and mirrors" goes on to make external entities seamlessly (to the Jade programmer) relative to the presentation client, eg printers, files, locales etc. Even external functions can be executed from the presentation client, requiring the .dll to be present on the client workstation. In all these cases, communication is required with the appserver, where the Jade methods and Jade objects are. So when your Jade code examines the contents of a textbox and sets the foreColor of a label accordingly, the Jade method execution happens only in the appserver, and the gui controls are only on the client. This requires a number of messages between the presentation server (appserver) and the presentation client. These are buffered where possible, and proxy objects are maintained in the appserver to minimise network traffic. Hence Jade "Smart" Thin Client. You could visualise a fat client split in half, resulting in an appserver handling the objects and methods on the server machine, and the thin client handling the gui on the client workstation.

With this in mind, consider the .ini file settings in a rap / appserver / thin client environment. The JadeClient section applies to the appserver (since it opens the database as a client), so JadeClient.ObjectCacheSizeLimit specifies how much memory to allocate to Jade objects held in the appserver. JadeServer.ObjectCacheSizeLimit specifies how much memory to allocate to Jade objects held in the server node, ie the rap, but this is only used by serverExecution methods. PersistentDb.ObjectCacheSizeLimit is also allocated in the rap, but is not used directly by methods. There is no ObjectCacheSizeLimit in the JadeThinClient section. So, if you didn't realise all this and set JadeClient.ObjectCacheSizeLimit small but set JadeServer.ObjectCacheSizeLimit large, you could get poor performance of database-intensive activity unless you use serverExecution.

Another possibility, as Richard pointed out, is that you were using tcp prior to Jade 6. The appserver has to fetch all objects from the rap via the tcp stack. And activities like locks and global.isValidObject can involve multiple round trips to the rap. This tcp activity (between rap and appserver on the same copy of Windows) shows up as cpu time. So using NetworkSpecification2=JadeLocal,Enabled,MyDb could speed up database-intensive activity from an appserver, especially if your cpu is relatively slow. One test I did recently (cloning a tree of 958 objects) took 2.0 seconds using tcp, 1.4 seconds using JadeLocal.

Cheers,
John P