1 Reply Latest reply on Apr 25, 2016 9:15 PM by bdeg7

    AJP Connector (jakarta) IIS help!!

    bdeg7 Level 1

      We can't seem to get this running right, and need someone with experience.

       

      We have 100 IIS websites, 65 of them are coldfusion. So we "tuned" AJP for that number of connection pools. Under the "ALL" configuration, we have an allotment of 9000 and a reuse size of 138. The server.xml matches thread count and timeout.

       

      Originally this was at the default of 250, and sites began to hang and never load. Took us forever to figure out this was the reason...

       

       

      So now we have the sites running, but they use extreme amounts of memory. The worker processes (w3wp.exe) appear to allocate large amounts of ram as soon as they start, and having jakarta in the ISAPI FIlters list reliably causes this. Remove jakarta, and site returns to normal fair memory usage. So naturally we removed jakarta from all PHP sites, and only have it on the CF11 sites. We also began grouping coldfusion sites based on priority into application pools, to try and reduce ram usage.

       

      Do we need to tune jakarta for every single site? Is there not a way to dynamically allocate connection pool "slots" without shutting down the whole server just to manipulate a "guesswork" value in connector.properties?

       

      Has anyone had a similar experience and have any expert advice on this?

      We came from CF9 and had zero problems with the old isapi filter.

      Jakarta is running rampant on our memory usage, and we are constantly battling pool recycles to keep our server healthy...

      It seems ridiculous that a simple CF11 site with only an index.cfm page in it, can use over 100mb of memory. That is NOT right, when only one person is viewing it.

        • 1. Re: AJP Connector (jakarta) IIS help!!
          bdeg7 Level 1

          I've found that 40mb of the memory was due to having .Net libraries (ISAPI Filters) running - thank you microsoft DebugDiag. So with those removed, it has helped.

          As far as I can see, it is indeed truthful that jakarta allocates memory based on the pool size. So grouping coldfusion sites by priority within app pools, makes a big difference. It allows me to recycle them in a way that makes sense for the business.

          However the truth, as it would seem, is that I need to reconfigure each site individually based on it's needs, using wsconfig.

           

          If it were up to me, I would recompile the jakarta source code to dynamically generate new connection availabilities based on need, and recycle when it reaches a cap. It is very , VERY, likely that I'll be doing just that.

          Hardcoding connection limits is ridiculous. Who knows what a given day will require.

          I wonder what the new CF 2016 does to handle this, or if it is the same ridiculousness. CF9 had a much better IIS integration, period. CF11, I'm either unintentionally blocking connections, or I'm wasting memory. What a drag.