nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Performance of web scripts

Hi -

I have a question on the overall performance of web scripts. It seems that there is quite a bit of overhead "outside" the web script itself. Our scenario is as follows:

We have a .net program doing uploading a file by doing an http post to an alfresco web script . The total time for the transaction (from when we call the http post 'til we get a response back) is on average 3 seconds - sometimes it was even longer. From logging we are doing in side the web script the actual start-finish of the web script is taking less than 1 second (this sub-second time period was spent receiving the http data, doing a lucence search, creating a space, and adding a content node)

To determine if the other 2 seconds was being spent in Alfresco or in the .net implementation of http we replaced the posting to Alfresco with a posting to a .net service that saves the file to a network share. The results of this test had the transaction being in the order of milliseconds which led us to the issue being in the web script framework.

I understand that there will be overhead in the scripting engine so my question is - if we want to stay within the scripting environment are there any configuration type optimizations or general web script guidelines that we can follow that can reduce the overall transaction time.

Thanks

Find more posts tagged with

Comments

jbarmash

I actually don't have enough experience performance tuning Web Scripts specifically, but here are some ideas:

1. Consider switching the web script controller code to Java. I understand that you lose ability to easily change it, but perhaps you can develop in JavaScript and then port over to Java.
2. For web scripts that are read-only and easily parametrizable, consider using caching technology on top of your webserver.
3. Separate your content store and lucene index stores on different physical disks - this should is generally a good idea for deploying since it separates content reads and index reads / writes from each other.

Which version of Alfresco are you currently using?

dinger

Is this something that Alfresco is looking into?

Presumably both the Javascript and Freemarker could be "compiled" into Java before deployment? This would speed things up no end. So, perhaps, you could have a flag in the web script description file that let you chose between dynamic or compiled script behaviour?

The Javascript API is quite a lot easier to use than the Java API; surely it would be easier to stick with this?

Rob

pmonks

Keep in mind that the bulk of the heavy lifting performed by a Web Script is typically done by the various Alfresco APIs that the Web Script calls, and those are native Java no matter what language the Web Script is implemented in. In other words, the performance difference between Javascript/FTL and native Java is likely not as great as you might think - for example, one Alfresco project I worked on where we rewrote JS based Web Scripts in Java (for performance reasons), the improvement ended up being less than 10%.

I'd be trying to further isolate where the time is being spent - for example instrumenting your JS controller to capture detailed timing metrics (both for the entire script as well as individual pieces of logic within it), comparing the total execution of the script against the total execution time reported by the client, removing the FTL template to see what difference that makes, etc. etc.

Cheers,
Peter

davidc

If you switch on log4j DEBUG for the Web Scripts engine, you'll get timings for script, template & overall execution.

log4j.logger.org.alfresco.web.scripts=debug

Templates are already pre-compiled.

You need to determine where the time is being spent, before optimising otherwise it's all guess work.