Lucee Performance/caching

On a recent upgrade from ACF to Lucee we have noticed a situation where
performance becomes an issue that we did not have on ACF.
We notice that under normal operations, our sites run very fast, faster
than they did on an equivalent machine running ACF 9.01.

Our application architecture consists of two parts, and application builder
and the applications built by the builder.
The application builder reads our standard templates (about 160 or so) into
memory and replaces various mnemonics with client-customized snippets of
codes and writes the .cfm pages to the webroot for each of our 55 sites
running on our Lucee 4.5 installation. (win 2012)
The builder can loop over all 55 clients and rewrite all the pages of those
sites in about 4 or 5 minutes.

Over the years, we have always done this throughout regular business hours
without any issue…sometimes several times a day.

In Lucee, we have found that while the application builder is running,
access to the sites comes to almost a screeching halt …taking sometimes
20, 30 or 40 seconds for pages to complete. and on some occasions the
pages timeout … with (sometimes) the following errors appearing the log
files.

java.lang.ThreadDeath
at java.lang.Thread.stop(Unknown Source)
at lucee.commons.io.StopThread.run(SystemUtil.java:1091)
Exception in thread “Thread-53889” java.lang.NullPointerException
at lucee.commons.io.StopThread.run(SystemUtil.java:1068)

Exception in thread “ajp-nio-8009-exec-14”
java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(Unknown
Source)
at java.util.concurrent.locks.ReentrantLock.unlock(Unknown Source)
at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:85)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:31)
at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)

It does recover eventually… maybe 3 or 4 minutes after the application
builder completes, but not before someone complains of performance issues
by our clients.

I have tried all 3 settings for *Inspect Templates (CFM/CFC) *setting
(always, once, never)
The problem occurs exactly the same for always and once.
Obviously, when set to never it the issue goes away but as soon as I
click “Clear page cache Pool” to make the latest rebuild changes
persistent, the issue shows itself . This leads me to speculate that it
must have something to do with the algorithms used to populate/refresh the
cache or the comparison routine for large-scale wholesale changes in the
file timestamps?

Hate to bring up the fact that it the behavior was different in ACF but
this is something we need to be able to do a regular basis without
interference to our clients
ability to work.

Has anyone else ever had such an experience?
Any thoughts on why this happens? and what we can do about it?

anyone?On Monday, May 9, 2016 at 5:30:38 PM UTC-5, Scott Conklin wrote:

On a recent upgrade from ACF to Lucee we have noticed a situation where
performance becomes an issue that we did not have on ACF.
We notice that under normal operations, our sites run very fast, faster
than they did on an equivalent machine running ACF 9.01.

Our application architecture consists of two parts, and application
builder and the applications built by the builder.
The application builder reads our standard templates (about 160 or so)
into memory and replaces various mnemonics with client-customized snippets
of codes and writes the .cfm pages to the webroot for each of our 55 sites
running on our Lucee 4.5 installation. (win 2012)
The builder can loop over all 55 clients and rewrite all the pages of
those sites in about 4 or 5 minutes.

Over the years, we have always done this throughout regular business hours
without any issue…sometimes several times a day.

In Lucee, we have found that while the application builder is running,
access to the sites comes to almost a screeching halt …taking sometimes
20, 30 or 40 seconds for pages to complete. and on some occasions the
pages timeout … with (sometimes) the following errors appearing the
log files.

java.lang.ThreadDeath
at java.lang.Thread.stop(Unknown Source)
at lucee.commons.io.StopThread.run(SystemUtil.java:1091)
Exception in thread “Thread-53889” java.lang.NullPointerException
at lucee.commons.io.StopThread.run(SystemUtil.java:1068)

Exception in thread “ajp-nio-8009-exec-14”
java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(Unknown
Source)
at java.util.concurrent.locks.ReentrantLock.unlock(Unknown Source)
at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:85)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:31)
at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)

It does recover eventually… maybe 3 or 4 minutes after the application
builder completes, but not before someone complains of performance issues
by our clients.

I have tried all 3 settings for *Inspect Templates (CFM/CFC) *setting
(always, once, never)
The problem occurs exactly the same for always and once.
Obviously, when set to never it the issue goes away but as soon as I
click “Clear page cache Pool” to make the latest rebuild changes
persistent, the issue shows itself . This leads me to speculate that it
must have something to do with the algorithms used to populate/refresh the
cache or the comparison routine for large-scale wholesale changes in the
file timestamps?

Hate to bring up the fact that it the behavior was different in ACF but
this is something we need to be able to do a regular basis without
interference to our clients
ability to work.

Has anyone else ever had such an experience?
Any thoughts on why this happens? and what we can do about it?

@mark-

If you are doing LOADS of sites (you say 55?) are they also each a
context (with it’s own WEB-INF)

Yes, each is its own context. (all have their own WEB-INF)

I think you are saying to alter the builder to write the files to one of
two possible webroot paths and when the building is done, just toggle the
mapping programatically
to the other mapped webroot? is that correct?
I would need to have something like webroot_clientX_A and
webroot_ClientX_B for all 55 clients?

If I understand correctly, are the timestamps being updated for every
single file? We had the same issue when our Jenkins deploy did this as
every template needed to be recompiled on the next request. We had to
modify our process to not update timestamps on file which did not change.

Maybe Micha can comment on the compilation performance in Lucee.

Thanks!

~BradOn Wednesday, May 11, 2016 at 11:12:11 AM UTC-5, Scott Conklin wrote:

anyone?

On Monday, May 9, 2016 at 5:30:38 PM UTC-5, Scott Conklin wrote:

On a recent upgrade from ACF to Lucee we have noticed a situation where
performance becomes an issue that we did not have on ACF.
We notice that under normal operations, our sites run very fast, faster
than they did on an equivalent machine running ACF 9.01.

Our application architecture consists of two parts, and application
builder and the applications built by the builder.
The application builder reads our standard templates (about 160 or so)
into memory and replaces various mnemonics with client-customized snippets
of codes and writes the .cfm pages to the webroot for each of our 55 sites
running on our Lucee 4.5 installation. (win 2012)
The builder can loop over all 55 clients and rewrite all the pages of
those sites in about 4 or 5 minutes.

Over the years, we have always done this throughout regular business
hours without any issue…sometimes several times a day.

In Lucee, we have found that while the application builder is running,
access to the sites comes to almost a screeching halt …taking sometimes
20, 30 or 40 seconds for pages to complete. and on some occasions the
pages timeout … with (sometimes) the following errors appearing the
log files.

java.lang.ThreadDeath
at java.lang.Thread.stop(Unknown Source)
at lucee.commons.io.StopThread.run(SystemUtil.java:1091)
Exception in thread “Thread-53889” java.lang.NullPointerException
at lucee.commons.io.StopThread.run(SystemUtil.java:1068)

Exception in thread “ajp-nio-8009-exec-14”
java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(Unknown
Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(Unknown
Source)
at java.util.concurrent.locks.ReentrantLock.unlock(Unknown Source)
at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:85)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:31)
at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)

It does recover eventually… maybe 3 or 4 minutes after the application
builder completes, but not before someone complains of performance issues
by our clients.

I have tried all 3 settings for *Inspect Templates (CFM/CFC) *setting
(always, once, never)
The problem occurs exactly the same for always and once.
Obviously, when set to never it the issue goes away but as soon as I
click “Clear page cache Pool” to make the latest rebuild changes
persistent, the issue shows itself . This leads me to speculate that it
must have something to do with the algorithms used to populate/refresh the
cache or the comparison routine for large-scale wholesale changes in the
file timestamps?

Hate to bring up the fact that it the behavior was different in ACF but
this is something we need to be able to do a regular basis without
interference to our clients
ability to work.

Has anyone else ever had such an experience?
Any thoughts on why this happens? and what we can do about it?

Hi Scott,

Can you give some more details of your set up, e.g.:

  • JVM Settings
  • JVM Version
  • Servlet container being used
  • Web server being used

Thanks.

Kind regards,

Andrew
about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.orgOn 11 May 2016 at 17:12, Scott Conklin <@Scott_Conklin> wrote:

anyone?

On Monday, May 9, 2016 at 5:30:38 PM UTC-5, Scott Conklin wrote:

On a recent upgrade from ACF to Lucee we have noticed a situation where
performance becomes an issue that we did not have on ACF.
We notice that under normal operations, our sites run very fast, faster
than they did on an equivalent machine running ACF 9.01.

Our application architecture consists of two parts, and application
builder and the applications built by the builder.
The application builder reads our standard templates (about 160 or so)
into memory and replaces various mnemonics with client-customized snippets
of codes and writes the .cfm pages to the webroot for each of our 55 sites
running on our Lucee 4.5 installation. (win 2012)
The builder can loop over all 55 clients and rewrite all the pages of
those sites in about 4 or 5 minutes.

Over the years, we have always done this throughout regular business
hours without any issue…sometimes several times a day.

In Lucee, we have found that while the application builder is running,
access to the sites comes to almost a screeching halt …taking sometimes
20, 30 or 40 seconds for pages to complete. and on some occasions the
pages timeout … with (sometimes) the following errors appearing the
log files.

java.lang.ThreadDeath
at java.lang.Thread.stop(Unknown Source)
at lucee.commons.io.StopThread.run(SystemUtil.java:1091)
Exception in thread “Thread-53889” java.lang.NullPointerException
at lucee.commons.io.StopThread.run(SystemUtil.java:1068)

Exception in thread “ajp-nio-8009-exec-14”
java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(Unknown
Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(Unknown
Source)
at java.util.concurrent.locks.ReentrantLock.unlock(Unknown Source)
at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:85)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:31)
at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)

It does recover eventually… maybe 3 or 4 minutes after the application
builder completes, but not before someone complains of performance issues
by our clients.

I have tried all 3 settings for *Inspect Templates (CFM/CFC) *setting
(always, once, never)
The problem occurs exactly the same for always and once.
Obviously, when set to never it the issue goes away but as soon as I
click “Clear page cache Pool” to make the latest rebuild changes
persistent, the issue shows itself . This leads me to speculate that it
must have something to do with the algorithms used to populate/refresh the
cache or the comparison routine for large-scale wholesale changes in the
file timestamps?

Hate to bring up the fact that it the behavior was different in ACF but
this is something we need to be able to do a regular basis without
interference to our clients
ability to work.

Has anyone else ever had such an experience?
Any thoughts on why this happens? and what we can do about it?


Love Lucee? Become a supporter and be part of the Lucee project today! -
http://lucee.org/supporters/become-a-supporter.html


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/37ba3e71-562e-4c81-83a3-3474b789c643%40googlegroups.com
https://groups.google.com/d/msgid/lucee/37ba3e71-562e-4c81-83a3-3474b789c643%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

I’ve been omitting the java agent on some of my 4.5 servers now that I’m on
java 8. The biggest thing it does is it allows the class files to be
rewritten in place on recompilation so perm gen doesn’t fill up. On Java
8, perm gen doesn’t exist and classes can be GC’d. I’ve also run into some
really weird compilation bugs in Lucee which were caused by the java agent.
I’m curious to know what difference it makes for you to remove your java
agent.

Thanks!

~Brad

ColdBox Platform Evangelist
*Ortus Solutions, Corp *

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.comOn Wed, May 11, 2016 at 11:56 AM, Mark Drew <@Mark_Drew> wrote:

in the setenv.sh file under /tomcat/bin there will be a -javaagent: entry
that maps to a lib. You could copy the line, comment out the duplicate and
remove the javaagent entry

MD

On 11 May 2016, at 17:53, Scott Conklin <@Scott_Conklin> wrote:

if you disable the java agent, then the slow down is not massive, it
becomes normal.

What does this mean

On Monday, May 9, 2016 at 5:30:38 PM UTC-5, Scott Conklin wrote:

On a recent upgrade from ACF to Lucee we have noticed a situation where
performance becomes an issue that we did not have on ACF.
We notice that under normal operations, our sites run very fast, faster
than they did on an equivalent machine running ACF 9.01.

Our application architecture consists of two parts, and application
builder and the applications built by the builder.
The application builder reads our standard templates (about 160 or so)
into memory and replaces various mnemonics with client-customized snippets
of codes and writes the .cfm pages to the webroot for each of our 55 sites
running on our Lucee 4.5 installation. (win 2012)
The builder can loop over all 55 clients and rewrite all the pages of
those sites in about 4 or 5 minutes.

Over the years, we have always done this throughout regular business
hours without any issue…sometimes several times a day.

In Lucee, we have found that while the application builder is running,
access to the sites comes to almost a screeching halt …taking sometimes
20, 30 or 40 seconds for pages to complete. and on some occasions the
pages timeout … with (sometimes) the following errors appearing the
log files.

java.lang.ThreadDeath
at java.lang.Thread.stop(Unknown Source)
at lucee.commons.io.StopThread.run(SystemUtil.java:1091)
Exception in thread “Thread-53889” java.lang.NullPointerException
at lucee.commons.io.StopThread.run(SystemUtil.java:1068)

Exception in thread “ajp-nio-8009-exec-14”
java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(Unknown
Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(Unknown
Source)
at java.util.concurrent.locks.ReentrantLock.unlock(Unknown Source)
at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:85)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:31)
at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)

It does recover eventually… maybe 3 or 4 minutes after the application
builder completes, but not before someone complains of performance issues
by our clients.

I have tried all 3 settings for *Inspect Templates (CFM/CFC) *setting
(always, once, never)
The problem occurs exactly the same for always and once.
Obviously, when set to never it the issue goes away but as soon as I
click “Clear page cache Pool” to make the latest rebuild changes
persistent, the issue shows itself . This leads me to speculate that it
must have something to do with the algorithms used to populate/refresh the
cache or the comparison routine for large-scale wholesale changes in the
file timestamps?

Hate to bring up the fact that it the behavior was different in ACF but
this is something we need to be able to do a regular basis without
interference to our clients
ability to work.

Has anyone else ever had such an experience?
Any thoughts on why this happens? and what we can do about it?


Love Lucee? Become a supporter and be part of the Lucee project today! -
http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/3caeae94-4650-4843-9fb9-96d20c22df96%40googlegroups.com
https://groups.google.com/d/msgid/lucee/3caeae94-4650-4843-9fb9-96d20c22df96%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.


Love Lucee? Become a supporter and be part of the Lucee project today! -
http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to a topic in the
Google Groups “Lucee” group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/lucee/56WHZlWc9rI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/30A92C53-F98D-4D22-8799-DA8C1B20355B%40gmail.com
https://groups.google.com/d/msgid/lucee/30A92C53-F98D-4D22-8799-DA8C1B20355B%40gmail.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

Hey Scott,

What is important to know:

· Why is the process taking 4-5 minutes? Writing around 10000 files shouldn’t be that much of work

· Where are the requests hanging? There is a way to find that out (dm or email me for details)

· What is the exact configuration of the server doing the build?

I would have more questions once the above are off the table J

Normally Lucee should really perform a lot faster than that. IMHO it could be a configuration or locking issue. Nonetheless I will help you as good as I can.

Sincerely
Gert Franz

RASIA GmbH

Spittelgasse 7

5103 Moeriken-Wildegg

Switzerland

Email: mailto:Gert_Franz @Gert_Franz
Skype: gert.franz

Phone Switzerland: +41 76 5680 231Von: lucee@googlegroups.com [mailto:lucee@googlegroups.com] Im Auftrag von Scott Conklin
Gesendet: Mittwoch, 11. Mai 2016 18:12
An: Lucee
Betreff: [Lucee] Re: Lucee Performance/caching

anyone?

On Monday, May 9, 2016 at 5:30:38 PM UTC-5, Scott Conklin wrote:

On a recent upgrade from ACF to Lucee we have noticed a situation where performance becomes an issue that we did not have on ACF.

We notice that under normal operations, our sites run very fast, faster than they did on an equivalent machine running ACF 9.01.

Our application architecture consists of two parts, and application builder and the applications built by the builder.

The application builder reads our standard templates (about 160 or so) into memory and replaces various mnemonics with client-customized snippets of codes and writes the .cfm pages to the webroot for each of our 55 sites running on our Lucee 4.5 installation. (win 2012)

The builder can loop over all 55 clients and rewrite all the pages of those sites in about 4 or 5 minutes.

Over the years, we have always done this throughout regular business hours without any issue…sometimes several times a day.

In Lucee, we have found that while the application builder is running, access to the sites comes to almost a screeching halt …taking sometimes 20, 30 or 40 seconds for pages to complete. and on some occasions the pages timeout … with (sometimes) the following errors appearing the log files.

java.lang.ThreadDeath

            at java.lang.Thread.stop(Unknown Source)

            at lucee.commons.io.StopThread.run(SystemUtil.java:1091)

Exception in thread “Thread-53889” java.lang.NullPointerException

            at lucee.commons.io.StopThread.run(SystemUtil.java:1068)

Exception in thread “ajp-nio-8009-exec-14” java.lang.IllegalMonitorStateException

            at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(Unknown Source)

            at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(Unknown Source)

            at java.util.concurrent.locks.ReentrantLock.unlock(Unknown Source)

            at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)

            at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:85)

            at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:31)

            at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)

            at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

            at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

            at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

            at java.lang.Thread.run(Unknown Source)

It does recover eventually… maybe 3 or 4 minutes after the application builder completes, but not before someone complains of performance issues by our clients.

I have tried all 3 settings for Inspect Templates (CFM/CFC) setting (always, once, never)

The problem occurs exactly the same for always and once.

Obviously, when set to never it the issue goes away but as soon as I click “Clear page cache Pool” to make the latest rebuild changes persistent, the issue shows itself . This leads me to speculate that it must have something to do with the algorithms used to populate/refresh the cache or the comparison routine for large-scale wholesale changes in the file timestamps?

Hate to bring up the fact that it the behavior was different in ACF but this is something we need to be able to do a regular basis without interference to our clients

ability to work.

Has anyone else ever had such an experience?

Any thoughts on why this happens? and what we can do about it?


Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/37ba3e71-562e-4c81-83a3-3474b789c643%40googlegroups.com https://groups.google.com/d/msgid/lucee/37ba3e71-562e-4c81-83a3-3474b789c643%40googlegroups.com?utm_medium=email&utm_source=footer .
For more options, visit https://groups.google.com/d/optout.

@andrew
sure…

OS
*Windows Server 2012 R2 (6.3) 64bit *
8 GB RAM

Servlet Container
*Apache Tomcat/8.0.28 *

Java
*1.8.0_77 (Oracle Corporation) 64bit *

Architecture
*64bit *

Database
MS SQL Server 2014

Db Driver
jTDS Type 4 JDBC Driver for MS SQL Server

Java args:

-Xms4096m -Xmx4096mOn Monday, May 9, 2016 at 5:30:38 PM UTC-5, Scott Conklin wrote:

On a recent upgrade from ACF to Lucee we have noticed a situation where
performance becomes an issue that we did not have on ACF.
We notice that under normal operations, our sites run very fast, faster
than they did on an equivalent machine running ACF 9.01.

Our application architecture consists of two parts, and application
builder and the applications built by the builder.
The application builder reads our standard templates (about 160 or so)
into memory and replaces various mnemonics with client-customized snippets
of codes and writes the .cfm pages to the webroot for each of our 55 sites
running on our Lucee 4.5 installation. (win 2012)
The builder can loop over all 55 clients and rewrite all the pages of
those sites in about 4 or 5 minutes.

Over the years, we have always done this throughout regular business hours
without any issue…sometimes several times a day.

In Lucee, we have found that while the application builder is running,
access to the sites comes to almost a screeching halt …taking sometimes
20, 30 or 40 seconds for pages to complete. and on some occasions the
pages timeout … with (sometimes) the following errors appearing the
log files.

java.lang.ThreadDeath
at java.lang.Thread.stop(Unknown Source)
at lucee.commons.io.StopThread.run(SystemUtil.java:1091)
Exception in thread “Thread-53889” java.lang.NullPointerException
at lucee.commons.io.StopThread.run(SystemUtil.java:1068)

Exception in thread “ajp-nio-8009-exec-14”
java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(Unknown
Source)
at java.util.concurrent.locks.ReentrantLock.unlock(Unknown Source)
at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:85)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:31)
at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)

It does recover eventually… maybe 3 or 4 minutes after the application
builder completes, but not before someone complains of performance issues
by our clients.

I have tried all 3 settings for *Inspect Templates (CFM/CFC) *setting
(always, once, never)
The problem occurs exactly the same for always and once.
Obviously, when set to never it the issue goes away but as soon as I
click “Clear page cache Pool” to make the latest rebuild changes
persistent, the issue shows itself . This leads me to speculate that it
must have something to do with the algorithms used to populate/refresh the
cache or the comparison routine for large-scale wholesale changes in the
file timestamps?

Hate to bring up the fact that it the behavior was different in ACF but
this is something we need to be able to do a regular basis without
interference to our clients
ability to work.

Has anyone else ever had such an experience?
Any thoughts on why this happens? and what we can do about it?

on further inspection, i now see that the java options in the Tomcat
Service Control Manager also has the javaagent flag in it
Should i be removing it here or in setenv.sh?
is the setenv.sh the way one would do if on a non-windows machine? or does
one have a precedence over the other?

http://www.evernote.com/shard/s349/sh/e938c0b5-5ad8-49ff-b311-6e75655ea6f9/cf2fc4670d7872602ad32bde46f8fa23

Not sure which way round it goes (not a windows guy myself) but these are default Max and Min memory settings. The file looks correct BTW.

MD> On 11 May 2016, at 18:22, Scott Conklin <@Scott_Conklin> wrote:

@mark-
Another quick question…

When I follow your instructions for modifying the Setenv.sh

I end up with this

CATALINA_OPTS="-Xms256m -Xmx512m";

CATALINA_OPTS="-Xms256m -Xmx512m -javaagent:lib/lucee-inst.jar";

  1. this is what you meant? correct?
  2. curious what these xms and xmx setting here are when i have
    these in my java args for Lucee
    -Xms4096m -Xmx4096m
  3. I am assuming that i will need to cycle Lucee to make this change persist?
    (is so, I may have to wait until after business hours to try this out)


Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/6e8a8568-2136-4c76-ade2-93aed4ac9276%40googlegroups.com https://groups.google.com/d/msgid/lucee/6e8a8568-2136-4c76-ade2-93aed4ac9276%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

if you disable the java agent, then the slow down is not massive, it
becomes normal.

What does this meanOn Monday, May 9, 2016 at 5:30:38 PM UTC-5, Scott Conklin wrote:

On a recent upgrade from ACF to Lucee we have noticed a situation where
performance becomes an issue that we did not have on ACF.
We notice that under normal operations, our sites run very fast, faster
than they did on an equivalent machine running ACF 9.01.

Our application architecture consists of two parts, and application
builder and the applications built by the builder.
The application builder reads our standard templates (about 160 or so)
into memory and replaces various mnemonics with client-customized snippets
of codes and writes the .cfm pages to the webroot for each of our 55 sites
running on our Lucee 4.5 installation. (win 2012)
The builder can loop over all 55 clients and rewrite all the pages of
those sites in about 4 or 5 minutes.

Over the years, we have always done this throughout regular business hours
without any issue…sometimes several times a day.

In Lucee, we have found that while the application builder is running,
access to the sites comes to almost a screeching halt …taking sometimes
20, 30 or 40 seconds for pages to complete. and on some occasions the
pages timeout … with (sometimes) the following errors appearing the
log files.

java.lang.ThreadDeath
at java.lang.Thread.stop(Unknown Source)
at lucee.commons.io.StopThread.run(SystemUtil.java:1091)
Exception in thread “Thread-53889” java.lang.NullPointerException
at lucee.commons.io.StopThread.run(SystemUtil.java:1068)

Exception in thread “ajp-nio-8009-exec-14”
java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(Unknown
Source)
at java.util.concurrent.locks.ReentrantLock.unlock(Unknown Source)
at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:85)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:31)
at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)

It does recover eventually… maybe 3 or 4 minutes after the application
builder completes, but not before someone complains of performance issues
by our clients.

I have tried all 3 settings for *Inspect Templates (CFM/CFC) *setting
(always, once, never)
The problem occurs exactly the same for always and once.
Obviously, when set to never it the issue goes away but as soon as I
click “Clear page cache Pool” to make the latest rebuild changes
persistent, the issue shows itself . This leads me to speculate that it
must have something to do with the algorithms used to populate/refresh the
cache or the comparison routine for large-scale wholesale changes in the
file timestamps?

Hate to bring up the fact that it the behavior was different in ACF but
this is something we need to be able to do a regular basis without
interference to our clients
ability to work.

Has anyone else ever had such an experience?
Any thoughts on why this happens? and what we can do about it?

Thank you all!

I will try removing the -javaagent:E:\lucee\tomcat\lib\lucee-inst.jar
setting from the control panel and the run the application builder again to
see if it stops the slow down symptoms
I will have to wait until after business hours to do so to avoid service
interruptions to our corporate clients…
Will let you know how the test goes…

Thanks again!

Sorry, I gave you bad info at the time, setenv.sh is just for ‘nix type systems. Stick to your service control thing.

MD> On 11 May 2016, at 18:56, Igal @ Lucee.org <@Igal> wrote:

On Windows you set it through the Service Applet, not through setenv, and definitely NOT through setenv.sh which is a *nix shell script.

And stick to your 4GB of RAM rather than the default 256MB – 512MB settings.

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/
On 5/11/2016 10:22 AM, Scott Conklin wrote:

@mark-
Another quick question…

When I follow your instructions for modifying the Setenv.sh

I end up with this

CATALINA_OPTS="-Xms256m -Xmx512m";

CATALINA_OPTS="-Xms256m -Xmx512m -javaagent:lib/lucee-inst.jar";

  1. this is what you meant? correct?
  2. curious what these xms and xmx setting here are when i have
    these in my java args for Lucee
    -Xms4096m -Xmx4096m
  3. I am assuming that i will need to cycle Lucee to make this change persist?
    (is so, I may have to wait until after business hours to try this out)

    Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/6e8a8568-2136-4c76-ade2-93aed4ac9276%40googlegroups.com?utm_medium=email&utm_source=footerhttps://groups.google.com/d/msgid/lucee/6e8a8568-2136-4c76-ade2-93aed4ac9276%40googlegroups.com https://groups.google.com/d/msgid/lucee/6e8a8568-2136-4c76-ade2-93aed4ac9276%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.


Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/6a7d4e4a-1135-6c12-8225-f33131c425ae%40lucee.org https://groups.google.com/d/msgid/lucee/6a7d4e4a-1135-6c12-8225-f33131c425ae%40lucee.org?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

@mark @brad
Thanks, I am going to give that a try…On Monday, May 9, 2016 at 5:30:38 PM UTC-5, Scott Conklin wrote:

On a recent upgrade from ACF to Lucee we have noticed a situation where
performance becomes an issue that we did not have on ACF.
We notice that under normal operations, our sites run very fast, faster
than they did on an equivalent machine running ACF 9.01.

Our application architecture consists of two parts, and application
builder and the applications built by the builder.
The application builder reads our standard templates (about 160 or so)
into memory and replaces various mnemonics with client-customized snippets
of codes and writes the .cfm pages to the webroot for each of our 55 sites
running on our Lucee 4.5 installation. (win 2012)
The builder can loop over all 55 clients and rewrite all the pages of
those sites in about 4 or 5 minutes.

Over the years, we have always done this throughout regular business hours
without any issue…sometimes several times a day.

In Lucee, we have found that while the application builder is running,
access to the sites comes to almost a screeching halt …taking sometimes
20, 30 or 40 seconds for pages to complete. and on some occasions the
pages timeout … with (sometimes) the following errors appearing the
log files.

java.lang.ThreadDeath
at java.lang.Thread.stop(Unknown Source)
at lucee.commons.io.StopThread.run(SystemUtil.java:1091)
Exception in thread “Thread-53889” java.lang.NullPointerException
at lucee.commons.io.StopThread.run(SystemUtil.java:1068)

Exception in thread “ajp-nio-8009-exec-14”
java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(Unknown
Source)
at java.util.concurrent.locks.ReentrantLock.unlock(Unknown Source)
at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:85)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:31)
at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)

It does recover eventually… maybe 3 or 4 minutes after the application
builder completes, but not before someone complains of performance issues
by our clients.

I have tried all 3 settings for *Inspect Templates (CFM/CFC) *setting
(always, once, never)
The problem occurs exactly the same for always and once.
Obviously, when set to never it the issue goes away but as soon as I
click “Clear page cache Pool” to make the latest rebuild changes
persistent, the issue shows itself . This leads me to speculate that it
must have something to do with the algorithms used to populate/refresh the
cache or the comparison routine for large-scale wholesale changes in the
file timestamps?

Hate to bring up the fact that it the behavior was different in ACF but
this is something we need to be able to do a regular basis without
interference to our clients
ability to work.

Has anyone else ever had such an experience?
Any thoughts on why this happens? and what we can do about it?

On Windows you set it through the Service Applet, not through setenv,
and definitely NOT through setenv.sh which is a *nix shell script.

And stick to your 4GB of RAM rather than the default 256MB – 512MB
settings.

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/On 5/11/2016 10:22 AM, Scott Conklin wrote:

@mark-
Another quick question…

When I follow your instructions for modifying the Setenv.sh

I end up with this

CATALINA_OPTS="-Xms256m -Xmx512m";

CATALINA_OPTS="-Xms256m -Xmx512m -javaagent:lib/lucee-inst.jar";

  1. this is what you meant? correct?
  2. curious what these xms and xmx setting here are when i have
    these in my java args for Lucee
    |-Xms4096m -Xmx4096m |
  3. I am assuming that i will need to cycle Lucee to make this change
    persist?
    (is so, I may have to wait until after business hours to try this out)

    Love Lucee? Become a supporter and be part of the Lucee project today!

You received this message because you are subscribed to the Google
Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to lucee+unsubscribe@googlegroups.com
mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com
mailto:lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/6e8a8568-2136-4c76-ade2-93aed4ac9276%40googlegroups.com
https://groups.google.com/d/msgid/lucee/6e8a8568-2136-4c76-ade2-93aed4ac9276%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout.

Well hopefully with higher xmx and xms values J

Sincerely
Gert Franz

RASIA GmbH

Spittelgasse 7

5103 Moeriken-Wildegg

Switzerland

Email: mailto:Gert_Franz @Gert_Franz
Skype: gert.franz

Phone Switzerland: +41 76 5680 231Von: lucee@googlegroups.com [mailto:lucee@googlegroups.com] Im Auftrag von Scott Conklin
Gesendet: Mittwoch, 11. Mai 2016 19:23
An: Lucee
Betreff: [Lucee] Re: Lucee Performance/caching

@mark-

Another quick question…

When I follow your instructions for modifying the Setenv.sh

I end up with this

CATALINA_OPTS="-Xms256m -Xmx512m";

CATALINA_OPTS="-Xms256m -Xmx512m -javaagent:lib/lucee-inst.jar";

  1. this is what you meant? correct?

  2. curious what these xms and xmx setting here are when i have

these in my java args for Lucee

-Xms4096m -Xmx4096m

  1. I am assuming that i will need to cycle Lucee to make this change persist?
    (is so, I may have to wait until after business hours to try this out)


Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/6e8a8568-2136-4c76-ade2-93aed4ac9276%40googlegroups.com https://groups.google.com/d/msgid/lucee/6e8a8568-2136-4c76-ade2-93aed4ac9276%40googlegroups.com?utm_medium=email&utm_source=footer .
For more options, visit https://groups.google.com/d/optout.

@Brad-

I believe that would correct. because the application builder that i talk
about reads the standard templates and then re-writes to disk all the .cfm
files into the webroot.
There are about 58 webroots (one for each of our clients) and the number of
files in each webroot is about 166 files.
see an example of a webroot datetime stamp of the files after the
application builder as rewritten them all…

http://www.evernote.com/shard/s349/sh/28c91a6e-1eea-4284-9581-862a8e832c6c/9f1ba6d2fdfa4abebc28021500d18001On Monday, May 9, 2016 at 5:30:38 PM UTC-5, Scott Conklin wrote:

On a recent upgrade from ACF to Lucee we have noticed a situation where
performance becomes an issue that we did not have on ACF.
We notice that under normal operations, our sites run very fast, faster
than they did on an equivalent machine running ACF 9.01.

Our application architecture consists of two parts, and application
builder and the applications built by the builder.
The application builder reads our standard templates (about 160 or so)
into memory and replaces various mnemonics with client-customized snippets
of codes and writes the .cfm pages to the webroot for each of our 55 sites
running on our Lucee 4.5 installation. (win 2012)
The builder can loop over all 55 clients and rewrite all the pages of
those sites in about 4 or 5 minutes.

Over the years, we have always done this throughout regular business hours
without any issue…sometimes several times a day.

In Lucee, we have found that while the application builder is running,
access to the sites comes to almost a screeching halt …taking sometimes
20, 30 or 40 seconds for pages to complete. and on some occasions the
pages timeout … with (sometimes) the following errors appearing the
log files.

java.lang.ThreadDeath
at java.lang.Thread.stop(Unknown Source)
at lucee.commons.io.StopThread.run(SystemUtil.java:1091)
Exception in thread “Thread-53889” java.lang.NullPointerException
at lucee.commons.io.StopThread.run(SystemUtil.java:1068)

Exception in thread “ajp-nio-8009-exec-14”
java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(Unknown
Source)
at java.util.concurrent.locks.ReentrantLock.unlock(Unknown Source)
at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:85)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:31)
at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)

It does recover eventually… maybe 3 or 4 minutes after the application
builder completes, but not before someone complains of performance issues
by our clients.

I have tried all 3 settings for *Inspect Templates (CFM/CFC) *setting
(always, once, never)
The problem occurs exactly the same for always and once.
Obviously, when set to never it the issue goes away but as soon as I
click “Clear page cache Pool” to make the latest rebuild changes
persistent, the issue shows itself . This leads me to speculate that it
must have something to do with the algorithms used to populate/refresh the
cache or the comparison routine for large-scale wholesale changes in the
file timestamps?

Hate to bring up the fact that it the behavior was different in ACF but
this is something we need to be able to do a regular basis without
interference to our clients
ability to work.

Has anyone else ever had such an experience?
Any thoughts on why this happens? and what we can do about it?

@gert

Well hopefully with higher xmx and xms values
What do you actually mean?

My min max values are set for Lucee in the Tomcat Service Control Manager
See the screenshot
http://www.evernote.com/shard/s349/sh/e93a7ee2-f6eb-4184-8bb6-dd3e7d0f7ea2/5abb05e56ca54a3bdbf53a9a618391bd

correct?

My previous question is what do these values mean in the setenv.sh?

CATALINA_OPTS="-Xms256m -Xmx512m;

CATALINA_OPTS="-Xms256m -Xmx512m -javaagent:lib/lucee-inst.jar";

Should i be making these values consistent with the ones in the Tomcat
Service Control Manager?
I have never even heard the setenv.sh file until @mark pointed it out to
me in this thread

If you’re on Windows, I don’t think setenv.sh is used. On Linux, setenv.sh
is used for any java process that’s spawned-- including the process that
stops the server. There is a catalina.sh file that controls the specific
args when starting up the web server. On Windows, it all uses that lame
little GUI box. You should be fine to just remove it there.

-Xms is “memory start” size for the heap
-Xmx is “memory max” size for the heap

Conventional wisdom is to keep those values the same on a server so the JVM
doesn’t need to bother asking the OS for more RAM. On a dev machine, I make
the start size smaller so it doesn’t waste RAM it doesn’t need.

Thanks!

~Brad

ColdBox Platform Evangelist
*Ortus Solutions, Corp *

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.comOn Wed, May 11, 2016 at 12:42 PM, Scott Conklin <@Scott_Conklin> wrote:

on further inspection, i now see that the java options in the Tomcat
Service Control Manager also has the javaagent flag in it
Should i be removing it here or in setenv.sh?
is the setenv.sh the way one would do if on a non-windows machine? or does
one have a precedence over the other?

http://www.evernote.com/shard/s349/sh/e938c0b5-5ad8-49ff-b311-6e75655ea6f9/cf2fc4670d7872602ad32bde46f8fa23


Love Lucee? Become a supporter and be part of the Lucee project today! -
http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to a topic in the
Google Groups “Lucee” group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/lucee/56WHZlWc9rI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/e06d57cb-5a40-49e1-8cf7-72dcf2a689ed%40googlegroups.com
https://groups.google.com/d/msgid/lucee/e06d57cb-5a40-49e1-8cf7-72dcf2a689ed%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

in the setenv.sh file under /tomcat/bin there will be a -javaagent: entry that maps to a lib. You could copy the line, comment out the duplicate and remove the javaagent entry

MD> On 11 May 2016, at 17:53, Scott Conklin <@Scott_Conklin> wrote:

if you disable the java agent, then the slow down is not massive, it becomes normal.

What does this mean

On Monday, May 9, 2016 at 5:30:38 PM UTC-5, Scott Conklin wrote:
On a recent upgrade from ACF to Lucee we have noticed a situation where performance becomes an issue that we did not have on ACF.
We notice that under normal operations, our sites run very fast, faster than they did on an equivalent machine running ACF 9.01.

Our application architecture consists of two parts, and application builder and the applications built by the builder.
The application builder reads our standard templates (about 160 or so) into memory and replaces various mnemonics with client-customized snippets of codes and writes the .cfm pages to the webroot for each of our 55 sites running on our Lucee 4.5 installation. (win 2012)
The builder can loop over all 55 clients and rewrite all the pages of those sites in about 4 or 5 minutes.

Over the years, we have always done this throughout regular business hours without any issue…sometimes several times a day.

In Lucee, we have found that while the application builder is running, access to the sites comes to almost a screeching halt …taking sometimes 20, 30 or 40 seconds for pages to complete. and on some occasions the pages timeout … with (sometimes) the following errors appearing the log files.

java.lang.ThreadDeath
at java.lang.Thread.stop(Unknown Source)
at lucee.commons.io.StopThread.run(SystemUtil.java:1091)
Exception in thread “Thread-53889” java.lang.NullPointerException
at lucee.commons.io.StopThread.run(SystemUtil.java:1068)

Exception in thread “ajp-nio-8009-exec-14” java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(Unknown Source)
at java.util.concurrent.locks.ReentrantLock.unlock(Unknown Source)
at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:85)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:31)
at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)

It does recover eventually… maybe 3 or 4 minutes after the application builder completes, but not before someone complains of performance issues by our clients.

I have tried all 3 settings for Inspect Templates (CFM/CFC) setting (always, once, never)
The problem occurs exactly the same for always and once.
Obviously, when set to never it the issue goes away but as soon as I click “Clear page cache Pool” to make the latest rebuild changes persistent, the issue shows itself . This leads me to speculate that it must have something to do with the algorithms used to populate/refresh the cache or the comparison routine for large-scale wholesale changes in the file timestamps?

Hate to bring up the fact that it the behavior was different in ACF but this is something we need to be able to do a regular basis without interference to our clients
ability to work.

Has anyone else ever had such an experience?
Any thoughts on why this happens? and what we can do about it?


Love Lucee? Become a supporter and be part of the Lucee project today! - http://lucee.org/supporters/become-a-supporter.html http://lucee.org/supporters/become-a-supporter.html

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/3caeae94-4650-4843-9fb9-96d20c22df96%40googlegroups.com https://groups.google.com/d/msgid/lucee/3caeae94-4650-4843-9fb9-96d20c22df96%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.