1 greendruid Feb 02, 2016 12:42
3 dm Sep 24, 2018 02:36
here is the config I came up with for 6.10.2-stable
It is not production-ready and has no support for https/letsencrypt, but runs without errors and has some basic optimisation.
server
{
listen 80;
server_name www.yoursite.com;
return 301 $scheme://yoursite.com$request_uri;
}
server
{
listen 80;
server_name yoursite.com;
root /var/www/yoursite.com/;
index index.php index.html;
# access_log /var/logs/nginx/yoursite-access.log;
error_log /var/logs/nginx/yoursite-error.log;
etag on;
client_max_body_size 128M;
location ~* /htsrv/getfile.php/(.*)$
{
try_files $uri /htsrv/getfile.php?$args;
}
location ~* \.(png|jpg|ico|cur|gif|pdf|zip|jpeg|ttf|eot|woff)$
{
aio threads;
gzip off;
gzip_static off;
add_header Cache-Control "max-age: 86640";
access_log off;
log_not_found off;
etag on;
}
location ~* \.(js|map|html|css|json|htm|xml|txt)$
{
aio threads;
add_header Cache-Control "max-age: 86640";
access_log off;
log_not_found off;
etag on;
}
location = /favicon.ico { access_log off; log_not_found off; }
location = /robots.txt { access_log off; log_not_found off; }
location /api/
{
auth_basic off;
rewrite "^/api/v(?<version>[^/]+)/(?<parameters>(.+))$" /htsrv/rest.php?api_version=$version&api_request=$parameters last;
}
location /go/
{
rewrite "^/go/(?<key>(.+))$" /htsrv/track.php?key=$key last;
}
location ~ /\.svn|/\.git { deny all; internal; }
location ~ /\. { deny all; internal; }
if ( $http_user_agent ~* (nmap|nikto|wikto|sf|sqlmap|bsqlbf|w3af|acunetix|havij|appscan) ) { return 403; }
location /
{
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php(/|$)
{
gzip off;
include fastcgi_params;
fastcgi_param HTTP_PROXY '';
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param DOCUMENT_ROOT $realpath_root;
fastcgi_buffers 8 128k;
fastcgi_buffer_size 256k;
fastcgi_read_timeout 3000;
fastcgi_keep_conn on;
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:7777;
}
}
I'll keep this topic updated and also add the rest of config (nginx server settings and php-fpm settings) after I do some load testing on a live server.
BTW, I have noticed that b2evo could be sped up by offloading a number of tasks to nginx instead of getting the job done by php.
For example, when there is a request for an image which is not cached yet, b2evo processes this image, than reads it and outputs to a client by itself, I mean this code
if( ! file_exists( $af_thumb_path ) )
{ // The thumbnail was not found...
global $Settings;
return '!Thumbnail not found in'.$Settings->get( 'evocache_foldername' ); // WARNING: exact wording match on return
}
if( ! is_readable( $af_thumb_path ) )
{
return '!Thumbnail read error! Check filesystem permissions.';
}
header('Content-Type: '.$thumb_mimetype );
header('Content-Length: '.filesize( $af_thumb_path ) );
header('Last-Modified: ' . date("r",$this->get_lastmod_ts()));
// dh> if( $mtime && $mtime == $this->get_lastmod_ts() )
// fp> I don't think mtime changes anything to the cacheability of the data
//header_noexpire(); // Static image
// attila> set expires on 30 days
header('Expires: ' . date("r", $servertimenow + 2592000/* 60*60*24*30 = 30 days */ ));
// Output the content of the file
readfile( $af_thumb_path );
return NULL;
But instead of using "readfile" which is far from optimal by many reasons (speed, scalability), with nginx we can just add one more header
header('X-Accel-Redirect: ' . $path);
and use this feature of nginx https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile/
to send the file by nginx directly.
Moreover, it is a nice security feature because we can keep all the files/images out of the webroot folder, so they will not be accessible in a direct way.
Skin fallback functionality could be offloaded to nginx too, in my own cms I use nginx to make fallback lookups not only for php files but also for images, css files, js files - everything. So if I need to customize some skin, I have only to make a diff with altered images, styles and scripts and nginx does the rest.
I also use it to generate a compressed single file of all css styles (and for the most of js as well). Nginx tries to load a compacted version, and if it is not present or outdated - it makes a request to a php file which regenerates a new copy of compressed resources and saves it for nginx.
With all those little tricks I was able to decrease a cpu load by ten after switching from apache2..
What do you mean with
which part of
.htaccess
are you having trouble with?