Deployment recommendations

The level of security and testing required depends greatly on the type of environment into which the application is deployed. For example, an internal department level application will not require the same level of security and testing as a publicly available, internet facing application. However, the following recommendations are applicable to all applications, whether the application serves a small internal user population or a large, internet user population.

Remove WebTools

The zero.core.webtools package can be very helpful when developing an application. Its tools allow more advanced, developer focused error pages, a virtual directory browser, and a user registry editor.

But these tools, while useful for a developer, are usually not appropriate for users, and it is recommended that the dependency be removed from your application before deployment.

Runtime Mode

There are two basic runtime modes for an application, "development" and "production", that can be controlled through the configuration of your application. Changing this value to "production" optimizes some of the recycle parameters to be more appropriate for a production application. For example, the default values for idle timeout and max request will be 10 minutes and 100,000 requests, respectively. These values will allow a more standard usage pattern for an application with multiple users meant to be always available, than the values used for development mode. In development mode, the application is recycled much more often.

Add the following to the configuration of your application.

/config/runtime/mode = "production"

Securing Management URIs

By default, the URIs used for the management functions are accessible from any web client from any IP address. This behavior makes sense during development, where control of the application from the development tools could be coming from multiple development workstations.

But, it is suggested that when an application is deployed, that these URIs be secured, such that management commands can only be accessed by trusted clients that have a CLI token. This will prevent unauthorized clients from performing management commands, such as shutting down the application. The CLI token is a token which is created by the CLI command and included as part the HTTP request to the managed application. The security runtime will then validate whether this token is considered trusted prior to allowing the management operation from being called. The following configuration stanza protects the management URIs and restricts access to all but those that have the correct local CLI token.

managementURIs="/(ops|config)manager(/.*)?"

## enable security for this URI space
@include "security/enableSecurity.config"{
    "conditions" : "/request/path =~ ${managementURIs}"
}

## register the allow local access
@include "security/allowLocalAccess.config"{
	"conditions" : "/request/path =~ ${managementURIs}"
}

If the situation arises where these URIs need to be secured but accessible from any client then the following configuration stanzas can be used. For this set of configuration stanzas, if the runtime cannot determine this management command has a valid CLI token, the user will be prompted for security using Basic authentication.

managementURIs="/(ops|config)manager(/.*)?"

## enable security for this URI space
@include "security/enableSecurity.config"{
    "conditions" : "/request/path =~ ${managementURIs}"
}

## register the allow local access
@include "security/allowLocalAccess.config"{
	"conditions" : "/request/path =~ ${managementURIs}"
}

## security rules for case allowLocalAccess determines
## user is not local
@include "security/basicAuthentication.config"{
    "conditions" : "/request/path =~ ${managementURIs}"
}
## define auth rule for non-local case
@include "security/authorization.config"{
    "conditions" : "/request/path =~ ${managementURIs}",
     "groups" : ["ALL_AUTHENTICATED_USERS"]
}

Administration for applications in production.

The zero.admin package provides the ability to perform administrative tasks for IBM® WebSphere® sMash applications. Follow this link for more information about zero.admin.

Tuning the Java™ heap for high volume PHP deployments.

By "high volume" we mean deployments where the majority of the hosts resources are dedicated to supporting a single application which should perform optimally, at the expense of other applications if necessary.

The WebSphere® sMash PHP runtime performs best using the generational garbage collector in IBM® Java™ runtime environments. It is only an advantage to use this collector with sMash PHP when a large nursery heap can be allocated from real memory, without generally causing operating system paging. Its worth noting that the maximum allocatable heap is dependent on the architecture of the host. The following zero.config setting is a starting point for application, and host architecture specific, tuning on 32 bit hosts.

/config/zso/jvmargs/java.vendor/IBM += [
"-Xgcpolicy:gencon",
"-Xmx2000M",
"-Xms2000M",
"-Xmnx1600M",
"-Xmns1600M"
]

php.ini settings for PHP performance

The WebSphere® sMash PHP runtime caches compiled scripts internally, in the Java™ heap, for best performance you should allow the cache to expand to hold all the php files in your application. For example if there are 2500 php files in the application then the following php.ini entry would be appropriate:

; Sets a limit on the number of files that will be held in the code cache.
; When this limit is reached entries are removed on a least recently used
; basis in order to accommodate new entries.
; Default : 400
;code_cache_limit = 400
code_cache_limit = 2500

zero.config settings for PHP throughput

The WebSphere® sMash automatically starts and stops service threads and associated PHP engines according to the short term workload demand. The PHP engine has a number of caches which benefit running many requests for the same application. To take maximum advantage from this the number of threads can be fixed so they are not started and stopped dynamically. The number of threads needed depends on the application and the host. By setting the number of threads too low you may not be able to fully utilise the machine resource, too high and the memory footprint grows and efficiency of the caches is reduced. As a starting point we have found 16 threads (and hence PHP engines) a good compromise for many PHP applications on a 4 way SMP host.

/config/maxThreads=16
/config/minThreads=16