Skip to main content
cherdt
cherdt
Inspiring
July 2, 2015
Answered

CF11 on IIS 8.5 frequently slow

  • July 2, 2015
  • 3 replies
  • 3215 views

Recently installed CF11 on a Windows 2012R2 server running IIS 8.5. There are currently 9 sites configured in IIS, all under separate application pools.

Several times a day, for reasons I have not yet determined, requests for CF pages under any one of the sites are returned very slowly (>10 seconds). Typically, they are returned in <500 ms. Recycling the application pool (or pools) appears to address this issue, which made me think the issue was with IIS. However, requests for static resources from the same IIS sites load fine, so I suspect it is not strictly an IIS issue.

I applied the changes to worker.properties and server.xml recommended by Anit Kumar Panda in ColdFusion 11 IIS Connector Tuning — Adobe ColdFusion Blog:

  • worker.cfusion.max_reuse_connections=250
  • worker.cfusion.connection_pool_size=2250 (9*250)
  • worker.cfusion.connection_pool_timeout=60
  • maxThreads="2250" connectionTimeout="60000" attributes in Server/Service/Connector

I'm still seeing slow responsiveness several times a day. I'll continue troubleshooting but thought I'd reach out to the community for ideas/troubleshooting tips.

This topic has been closed for replies.
Correct answer cherdt

After additional analysis of the times the slowdowns occurred, it became apparent that the majority of occurrences were between 7 P.M. and midnight, and that response times increased immediately at 7 P.M. A backup process running on another machine that started at 7 P.M. daily was copying data from the CIFS share containing the document roots of each site. The network interface was the bottleneck: due to the high volume of data transferred the server was slower to respond to requests. One of my colleagues added an additional network interface to the file server and the backup process uses the new network interface exclusively. We have since noticed no increases in response times at 7 P.M.

I think that the spontaneous recovery, and recovery due to IIS app pool recycling, was likely due to regression towards the mean--I received Nagios alerts only when response times exceeded 10 seconds, after which response times likely dropped below 10 seconds. One thing that led me to believe this was a ColdFusion issue is that IIS was able to deliver static assets (e.g. image files) during the same slowdowns without any noticeable delay. I am not sure why that would be the case--perhaps it was actually slower, as I did not benchmark response times for static assets (i.e. maybe static assets loaded in 300 ms during slowdowns rather than 100 ms during normal operation).

I can't say that it had nothing to do with IIS 8.5 and CF 11, as the adjustments made based on carl type3‌'s suggestions certainly seemed to improve performance and reduce the number of warnings and alerts! Thanks for all your help. The additional insight into the JVM will definitely be useful.

3 replies

cherdt
cherdtAuthorCorrect answer
Inspiring
August 5, 2015

After additional analysis of the times the slowdowns occurred, it became apparent that the majority of occurrences were between 7 P.M. and midnight, and that response times increased immediately at 7 P.M. A backup process running on another machine that started at 7 P.M. daily was copying data from the CIFS share containing the document roots of each site. The network interface was the bottleneck: due to the high volume of data transferred the server was slower to respond to requests. One of my colleagues added an additional network interface to the file server and the backup process uses the new network interface exclusively. We have since noticed no increases in response times at 7 P.M.

I think that the spontaneous recovery, and recovery due to IIS app pool recycling, was likely due to regression towards the mean--I received Nagios alerts only when response times exceeded 10 seconds, after which response times likely dropped below 10 seconds. One thing that led me to believe this was a ColdFusion issue is that IIS was able to deliver static assets (e.g. image files) during the same slowdowns without any noticeable delay. I am not sure why that would be the case--perhaps it was actually slower, as I did not benchmark response times for static assets (i.e. maybe static assets loaded in 300 ms during slowdowns rather than 100 ms during normal operation).

I can't say that it had nothing to do with IIS 8.5 and CF 11, as the adjustments made based on carl type3‌'s suggestions certainly seemed to improve performance and reduce the number of warnings and alerts! Thanks for all your help. The additional insight into the JVM will definitely be useful.

H
haxtbh
Inspiring
July 8, 2015

Before things get too complicated. Which update to CF 11 are you running? They are currently on HF5 and a number of fixes have been made to previous hotfixes that resolve issues similar to those you experience.

cherdt
cherdtAuthor
Inspiring
July 8, 2015

Thanks, I should have mentioned that: ColdFusion 11 Update 5.

It's also using the JVM from jdk1.8.0_45, rather than the JVM that is packaged with CF.

C
carl type3
Legend
July 2, 2015

Hi,

The CF tomcat components run on Java. You many need to tune some of the Java heap or non heap values. Could be a full garbage collection taking 10 or so seconds.

Java reminders. When a full garbage collection occurs that is a Java stop all process. Everything running on Java ie CF tomcat will appear paused or not responding for the GC duration.

HTH, Carl.

    cherdt
    cherdtAuthor
    Inspiring
    July 2, 2015

    Thanks. I am currently using the defaults for JVM heap size:

    I can definitely try increasing those values.

    I added -Xloggc:{application.home}/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps to the JVM arguments, I'll see how long the GC is taking and if those times correspond to the slowdowns.

    Thanks for the suggestions! I'll update this post when I have more info.

    C
    carl type3
    Legend
    July 2, 2015

    Be mindful of the GC types.

    Full GC (Metadata GC Threshold) - because non heap needs collecting

    Full GC (Ergonomics) - because heap needs collecting

    Full GC (Last ditch collection) - not good. Could be it takes half second but if 20 are occurring one after the other that's 10 seconds of Full GC

    Regards, Carl.

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices