LL9.5 Java Vs Oscript Performance

Hello!I was wondering how Java modules performance compares to Oscript. Anyone with any opinion or experience, I would greatly appreciate your feedback! Thanks!

Find more posts tagged with

Comments

Developers_Comparex_Africa_(x-comparexdevelopment_

I have not tested Java Modules compared to OScript, but my logic tells me that OScript will have a performance advantage. My reasoning is that a Java Module must communicate with the base OScript Java Module (javamodule_1_0_0) via RMI (Remote Method Invocation). Therefore Java Modules is in one sense just like LAPI in that it exposes another interface to OScript functionality. I would also expect Java Modules to have a preformance advantage over LAPI...

DCX_Technical_(dcx_tech_-_(deleted))

Actually I don't think it is that simple to compare, because there are a couple of options (using Tomcat throughout):1. You could front-end Tomcat with IIS2. You could front-end Tomcat with Apache3. You could use Tomcat directlyAll of these make for slightly different scenarios.Personally, I've tried it using scenario 1 and have found no significant performance difference. What I did do is hardwire the support directory directly to IIS via a virtual folder so that Tomcat isn't bothered for static content.In each scenario, the core Livelink server would be contacted via RMI from Tomcat, and therefore you have a better separation between rendering the HTML result vs. business logic processing. (The model-view-controller model is the basis of the new Java architecture.)Therefore, if you have a multi-CPU front-end server in a cluster then I would actually think that the performance would be better, because Tomcat is doing what the Oscript engine does in weblingo. That would leave at least half the work to be done in Tomcat, and the other half in the core server. Tomcat scales better when it comes to handling multiple threads (beyond 3) and therefore will probably do better in a cluster. In the longer term, you'd probably also want to rather get 2 front-end servers with e.g. 8 CPUs, since Tomcat will scale more linearly over multiple processors and you won't have a thread hard-limit....The Livelink server itself will probably still be in the background with its three threads, but it will most likely have less "contact" time because the RMI request-response can be completed quickly. This is very different to today's scenario where a full Livelink thread will be held open for the whole session until the communication has been completed (think 30 page powerpoint rendered into images) using livelink.exe or at least until it has all been rendered and handed off to the llisapi filter.Also, Tomcat (or whichever other servlet engine) would most likely have been tuned over the past years to perform very well in terms of JSP rendering, probably more efficient and faster than any tuning that's been done to weblingo rendering.All of this leads to some interesting architecture options in the future, and my guess is that it all really depends on what exactly you need to achieve (e.g. NTLM authentication may be easier if you do not use the Java architecture at this point, although there seem to be some interesting options....)Hope this helps,Rolf.

Marcia_Gillespie-Norder_(tokeleadmin_-_(deleted))

Thanks for that information. I am glad to see there are a number of people using or starting to use Tomcat instead of IIS for Livelink.We will probably upgrade to 9.5 this summer. So far, Tomcat looks good, but we do use Directory Services (2.2.2) with NTLM. We could switch that configuration to LDAP because we are almost all on AD now. But, the Java environment could be a challenge. I think you could get the same integration by using JCIFS from Samba. I use that now when I build J2EE applications and need single sign on or as others call it "zero sign on". If anyone is working on running Livelink through Tomcat with Directory Services installed, I would love to hear about your experience. Sorry if this is off topic. Perhaps I should have created a new topic?Kevin HutsonTokyo Electron U.S. Holdings