BLOX site content is served off of 3 server clusters represented in the below table. The BLOX servers run everything that has to do with the CMS. The /app directory is where customers can place custom code or files they want to create. Files within the /app directory will be served from either the APP server or the Image server depending on the file type. The APP server only serves PHPfiles. The Image server will serve any other file extension type other than PHP that is loaded to the /app directory.
| BLOX | APP | Images |
PHP: NOT allowed. This ensures that no one site can take out other sites.
Cache: 5 min (300 sec) Rate Limit: Enforced | PHP: PHP 7.3 Database: MySQL 5.7 Htaccess: files will not work SSI: .shtml files will be served but server side includes will not be rendered. Performance greatly hampered by SSI. CGI/Perl: will not work. Poses too many security risks to allow. Cache: nothing caches by default. MUST add cache control headers. Recommend 5 min (300 sec) Rate Limit: Enforced | Basic http server 10,000 times faster than APP server
Serves: static content not within BLOX system. jpgs, gifs, html files etc. Cache: 30 min (1800 secs) Rate Limit: None |
Cache Control in /app
By default the APP servers do not have any caching. Customers using PHP should apply cache control headers to their code or they run a very high risk of hitting rate limits which will throw 429 errors (specifically, "429 rate limit exceeded for engine pages"). TownNews recommends a 5 min (300 sec) caching time. In order to have your pages cache add the following code to each of your pages:
- <?php
- header(“Cache-Control: public, max-age=300”);
- ?>
Note that you must specify public in the above code, without it your files will NOT cache. Do NOT specify private as it’s like having no caching at all. Also note that 43200 is the absolute highest value you can speficy for max-age.
Do not add cache control headers to pages over 2MB in size. The TownNews front end servers ignore this code.
Do not add cache control headers to pages that POST data. If you do, the page will retain the data (since it is cached) from the original poster.
Other than the two items above, you should try to cache everything you can.
Other Caching Recommendations
It takes about 10,000 to 1 server resources to serve a PHP file as apposed to HTML. Even if that PHP file does not have any executable PHP in it. So in general, don’t call something .php unless it actually has PHP in it.
Rate Limiting
The rate limit on our APP servers is 60. This means that there can be up to 60 calls to the server per minute. Even our largest sites have no problem with this limit if they program their files appropriately with cache-control headers. 429 is the HTTP response code for rate limit exceeded.
View the two examples below to see why setting cache-control headers is so important. In this example let's assume that a site has 5 PHP pages being included on their sites front page via an iframe.
Example 1: No Cache-Control Headers
5 users visit the front page in the first second. Each has to download 5 PHP files that are on your front page of the APP server. This means 25 total server calls. You only have 35 server calls left before you hit your limit and there are 59 seconds left.
Example 2: 5 Minute Cache-Control
The first user visits the site and pulls the 5 PHP files off the APP server. Those 5 files are now cached for subsequent users for the next 5 minutes. Thus in 5 minutes time you only have 5 server calls where as in the first example there were 25 calls in 1 second. This makes a dramatic difference in load time.
PHP Extensions/Executable
The APP servers uses PHP 7.3.
You can not run executables within your /app directory.
Other Resources
This site gives a great tutorial/overview on caching.
This site allows you to put in a url and give specific cache-related data about it.
