Preview Tool

Cisco Bug: CSCut58257 - SSP 7.0: Optimizing Apache httpd configurations in Portals

Last Modified

Jun 05, 2017

Products (1)

  • Cisco Mobility Services Engine

Known Affected Releases


Description (partial)

BHN wants to squeeze every bit of performance out of available servers so as to provide faster response to end users, without having to throw more hardware at the problem.

They wants to address the inefficiencies in the install, of which they are finding many.

BHN noticed that the way the portal is installed is a default install and you want it optimized better for a production environment.

They want it tuned so that they can get better performance out of what is installed.

I explained that incorporating all the changes that you suggested would be a very big deal, require code changes, and thorough testing.

They wants to have some of the easier stuff done, such as removing unused modules that are loading. Some of the things that could be cleaned up with a little effort.

Specifically this is what BHN wants, 303 responses, and BHN response to that:

303 General Comments:
303 —> 303 does not control the VM or Apache configuration. We have worked with Mike Cooper in the past (retooling for 7.0 release) to tweak the configuration of the portal VM. Not sure if Jon was looking at the VM for the old portal or the 7.5 dev machine. Suggest his feedback be shared with Mike Cooper to see what if any of this has already be done, and Mike may have some more suggestions. Hopefully whatever changes are made to the BHN portal VM can be applied to the base image as well.

From Bright House:
I have reviewed the Apache HTTPD configuration on our SSP v5.3 portal servers and determined the following optimization steps that would help increase performance and reduce resource utilization. These steps apply to SSP v5.3.X as well as SSP v7.

Would not require any changes to the web server stack.
1.       Disable all unused modules in HTTPD
303 —> We would need to do some research and testing to see what modules we can do without. There are most likely quite a few.
a.       I agree with 303's statement that many of the enabled modules could possibly be disabled. I'm not familiar enough with the inner workings of the SSP code to know which ones are required, however. This would require investigation and testing in a controlled environment as 303 stated.
2.       Move configuration currently in .htaccess files to httpd.conf and set AllowOverride: None
303 —> The import SSP config resides in /var/www/portal/app/webroot/.htaccess
a.       I don't quite understand this response. My suggestion was to move the configuration in .htaccess file(s) to httpd.conf and set AllowOverride to None.
b.       This would reduce file I/O as HTTPD would not need to read the .htaccess file(s) on every request (.php, .css, .js, .jpg, etc).
c.        The only advantage to using .htaccess files is that HTTPD does not need to be restarted if changes are made.
3.       EnableMMAP: off
303 —> No portal impact
a.       I'm not too sure I agree with this response.
b.       The httpd.conf file specifically states that disabling this may improve performance. I haven't done any performance testing with this, though, so I'm not sure how much, if any, improvement would it would provide.
4.       Enable KeepAlive
303 —> No portal impact
a.       I'm not sure I agree with this response.
b.       Enabling KeepAlive would allow clients to reuse the TCP connection and HTTPD process when downloading all of the assets for a page request instead of creating a new connection and process for each asset request. These startup / teardown operations can be expensive, especially when client count increases.
5.       Set KeepAliveTimeout to a reasonable interval
303 —> No portal impact
a.       This goes with #4 above. Enabling KeepAlive and setting this to a reasonable interval would provide the client time to download all assets through the same connection/process, while limiting the number of connections and processes that are left idle.
Would require a change to the current web server stack.
6.       Remove mod_php and run PHP in FastCGI mode (PHP-FPM).
303 —> Apache version will dictate the particulars here. We should test this. Related to #7.
303 —> Apache 2.2 - mod_fastcgi + php-fpm
303 —> Apache 2.4 - mod_proxy_fcgi + php-fpm
a.       These are all valid points.
b.       I believe Apache should be updated to the latest stable version unless there is a requirement to run an older version. This would allow the mod_proxy_fcgi + php-fpm option, which from my understanding, would be the better option due to recent improvements made to this interface by Apache.
7.       Configure HTTPD to use the "worker" MPM instead of the default "prefork" MPM
303 —> We should test this. Related to #2  (NOTE: #2 is now #6 above)
a.       I don't know of any issues where this would be related, but I'm not an expert on Multi Processing Modules. I agree testing would be required.
8.       The appropriate settings for the MPM utilized should be tweaked for maximum performance. The actual settings will need to be calculated based on numbers from a production server at peak time.
-           StartServers
-           MinSpareServers
-           MaxSpareServers
-           ServerLimit
-           MaxClients
-           MaxRequestsPerChild
-           MinSpareThreads
-           MaxSpareThreads
-           ThreadsPerChild
303 —> No portal impact
a.       I do not agree with this.
b.       Some of these settings are specific to the prefork MPM, some are specific to the worker MPM, and some apply to both.
c.        The optimal values for the MPM-related settings will change based on volume of traffic to the server at any given time. Ideally, performance data should be gathered from production servers during peak utilization and the settings adjusted based on that data.
Would require a major architectural change to the web server stack.
9.       Replace Apache HTTPD with Nginx
303 —> We would also prefer nginx to Apache. We have had some development versions of the portal running on nginx, but have not looked into an HA configuration for this.
a.        This would require a major architectural change to the entire web stack. I feel it would be a great move for an enterprise application such as SSP.
I would be happy to provide whatever assistance I can in profiling and testing to improve the performance of the SSP portal servers.

Bug details contain sensitive information and therefore require a account to be viewed.

Bug Details Include

  • Full Description (including symptoms, conditions and workarounds)
  • Status
  • Severity
  • Known Fixed Releases
  • Related Community Discussions
  • Number of Related Support Cases
Bug information is viewable for customers and partners who have a service contract. Registered users can view up to 200 bugs per month without a service contract.