[
https://issues.apache.org/jira/browse/SLING-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-913:
-------------------------------
Attachment: SLING-913_eventcache.patch
I've attached a patch that uses some of Chetan's work but implements the cache
as an event based cache, which essentially eliminates additional repository
read operations.
The cache is size bound, eliminating the oldest n-th element when a new element
is added, where n is the size of the cache.
I've written the cache as a service so that Script Engines can also add
elements to it by default in the event a script is not necessarily run as part
of the Sling servlet resolution mechanism.
[~chetanm], [~fmeschbe], [~bdelacretaz], [~cziegeler] would you like to review
the patch before I apply it?
The performance improvements are similar to what Chetan got, however I've run
the same test on a late 2011 MacBook Pro with 8 GB @ 1333 MHz RAM and an
after-market SanDisk SDSSDXPS480G solid state drive:
{noformat}
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software: Jetty(9.2.9.v20150224)
Server Hostname: localhost
Server Port: 8080
Document Path: /content/espblog/*.html
Document Length: 1317 bytes
Concurrency Level: 20
Time taken for tests: 0.346 seconds
Complete requests: 100
Failed requests: 0
Keep-Alive requests: 100
Total transferred: 156200 bytes
HTML transferred: 131700 bytes
Requests per second: 289.20 [#/sec] (mean)
Time per request: 69.157 [ms] (mean)
Time per request: 3.458 [ms] (mean, across all concurrent requests)
Transfer rate: 441.14 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.3 0 1
Processing: 38 67 18.4 60 110
Waiting: 38 67 18.4 60 110
Total: 38 67 18.4 60 110
Percentage of the requests served within a certain time (ms)
50% 60
66% 65
75% 68
80% 90
90% 101
95% 107
98% 109
99% 110
100% 110 (longest request)
{noformat}
> Add a cache for pre-compiled scripts
> ------------------------------------
>
> Key: SLING-913
> URL: https://issues.apache.org/jira/browse/SLING-913
> Project: Sling
> Issue Type: New Feature
> Components: Scripting
> Affects Versions: Scripting Core 2.0.2
> Reporter: Felix Meschberger
> Assignee: Radu Cotescu
> Attachments: SLING-913.patch, SLING-913_eventcache.patch
>
>
> The Java Scripting API provides support for scripting langugages which may
> precompile script source and reuse the precompiled scripts:
> javax.script.Compilable: May be implemented by a ScriptEngine if
> precompilation is
> supported
> javax.script.CompiledScript: Result of calling the Compilable.compile
> method.
> The CompiledScript can be called to repeatedly execute the script without the
> need for recompilation and thus for improved performance.
> The Sling Core Scripting support should make use of this functionality by
> maintaining a cache compiled scripts with the following properties
> * indexed by script path
> * size limited (using LinkedHashMap overwriting the removeEldestEntry
> method)
> * entries are weak or soft references ot cache entries
> A cache entry consists of the following information:
> * The CompiledScript instance
> * The time of last compilation. this is compared to the last modification
> time of the script to decide on whether to recompile
> We might probaly also try to add a reference to the script engine
> implementation bundle to only use the cache entry if the bundle has not been
> stopped since adding the cache entry
> Executing the script would then consist of the following steps:
> 1 Check the cache of precompiled scripts. if an entry exists and can be
> used, use it
> 2. if the ScriptEngine is Compilable:
> 2a. Compile the script and add it to the cache and use it
> 2b. Otherwise have the script engine execute the script
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
