PHP Nginx Redirection – Point few URI to old domain and redirect rest to new Domain

Lately, we had our entire website revamped and as a part of sanity, we redirected a 301 from our old url to new url, which was apparently in a new domain. But here came a challenge, there were a few URI’s we had provided to the the third party and the url they used pointed to the old domain. So we had to write exception rule in our nginx configuration file. After a lot of trial and errors, we figured a working solution for the same. I would like to share the generic version of the configuration file.

We wrote a rewrite rule for the 2 old URIs and redirected the rest of them to new domain successfully.

server {
listen 80 ;
server_name old.domain.com ;
root /var/www/old.domain.com_root;
index index.php index.html index.htm;
#try_files $uri $uri/ /index.php?$query_string;
location ~ \.php$ {
    expires off;  ## Do not cache dynamic content
    add_header Cache-Control "max-age=120, must-revalidate";
    gzip on;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}


location /olduri-1 {
   #   rewrite ^/.* https://old.domain.com$request_uri permanent;
    try_files $uri $uri/ /index.php?$query_string;
}
location /olduri-2 {
   #   rewrite ^/.* https://old.domain.com$request_uri permanent;
    try_files $uri $uri/ /index.php?$query_string;
}
location / {
            return 301 https://new.domain.com$request_uri;
    }
}

Advertisement

BROTLI ON APACHE / NGINX & Its advantages over gzip & BROTLI ON AKAMAI

When your client sends a request to the server it will include a header saying which compression formats it will accept,  As you can see it says it will accept gzip, deflate or br compression formats. The server will respond and if available will compress the result in a supported format.  Here it supports gzip. Brotli is a new open-source compression format from google that improves on the performance of gzip in many cases. We only care about the HTTP compression.

Warning

Brotli only works on an https connection. Which is a good thing because we all want to encrypt the web, right? Installing Brotli

apt-get install brotli

Setting up on Apache

Apache has supported brotli since version 2.4.26 by way of the mod_brotli module. However, I can’t find any information on this so we are installing this module by kjdev

Install the Module

git clone --depth=1 --recursive https://github.com/kjdev/apache-mod-brotli.git
cd apache-mod-brotli
./autogen.sh
./configure
make
install -D .libs/mod_brotli.so /usr/lib/apache2/modules/mod_brotli.so -m 644
cd /etc/apache2/mods-available
echo "LoadModule brotli_module /usr/lib/apache2/modules/mod_brotli.so" > brotli.load

This has added the .load file to the mods available. We need to create an accompanying config file called brotli.conf, adding:

  BrotliCompressionLevel 10
  BrotliWindowSize 22
  AddOutputFilterByType BROTLI text/html text/plain text/css application/x-javascript

Enable the module

a2enmod brotli
service apache2 restart

You should now see in the response header that the page is compressed with brotli (br): 

Setting up on Nginx

Google has kindly released an Nginx Brotli module

Download the module

cd /usr/local/src
git clone https://github.com/google/ngx_brotli.git
cd ngx_brotli
git submodule update --init --recursive

Rebuild Nginx with our new module

You should run nginx -V to get your config string and add:

cd /opt/nginx-1.13.1/  (or your own path)
./configure YOUR CONFIG STRING --add-module=/usr/local/src/ngx_brotli
make
make install

Finally, add to your nginx.conf file

http {
    brotli on;
    brotli_static on;
}

In conclusion, the setup for both Apache and Nginx is pretty painless. If the browser does not support brotli it can always fallback to the ever faithful gzip.

What the heck is Brotli?

Just like gzip, Brotli is also a compression algorithm. It is developed by Google and serves best for text compression. The reason being, it uses a dictionary of common keywords and phrases on both client and server side and thus gives a better compression ratio. It is supported by all major browsers :

Image Credit: caniuse.com

Does your browser support Brotli?
Browsers which support Brotli send ‘br’ along with ‘gzip’ in accept-encoding request header. If Brotli is enabled on your web server, you will get response in Brotli compressed format.

We can check the encoding in response header (Image Credit: Certsimple)

Gzip vs Brotli:

The advantage for Brotli over gzip is that it makes use of a dictionary and thus it only needs to send keys instead of full keywords. According to certsimple,

• Javascript files compressed with Brotli are 14% smaller than gzip.
• HTML files are 21% smaller than gzip.
• CSS files are 17% smaller than gzip.

Note: Images should not be compressed either by gzip or Brotli as they are already compressed and compressing them again will make their sizes larger.

Fewer bytes transferred not only leads to faster page load but also helps in reducing costs of Content Delivery Network (CDN). Now that we know all these benefits, let’s see how to enable Brotli…

Embracing the Brotli side:

There were two ways by which we can deliver Brotli compressed assets:

• Enabling Brotli on our web-server
• Enabling Brotli on CDNs

We chose to go ahead with serving Brotli from our web servers and installed it on nginx. Google has provided a module for it which needs nginx to be installed from source. Once installed, the following settings need to be put in nginx conf file:

brotli on;brotli_static on;        # for static compression, explained laterbrotli_comp_level 11;    # this setting can vary from 1-11brotli_types text/plain text/css application/javascript application/json image/svg+xml application/xml+rss;

After this, all content types which are mentioned in brotli_types setting will be brotli compressed. Easy, wasn’t it!

Note: We have to keep gzip settings on nginx intact as clients who doesn’t support br should get gzip compressed files. Although nginx gives precedence to br if both are supported.

Here, our web server will send br compressed assets, then CDN will just cache it and pass on to the browser.

Another way to enable Brotli is via CDN. By this way you don’t have to write any code or install anything in your infra, but this will be a paid service. We went for the ‘Brotli from Origin’ approach (former), as it is more cost efficient and engineering is what we like to do.

Dynamic vs Static Compression:

Dynamic compression means compressing files on the fly whereas static means to compress files once and then serve every time from cache. We used static compression for our Javascript and CSS files, as those will not change (until a new build is deployed). All these files are then cached on CDN and get served from there itself.

We talked about a setting ‘brotli_comp_level’ above and promised to explain it later, so here it is. It indicates the compression ratio and ranges between 1 to 11. Higher the ratio, higher the time it will take to compress it. So we used the value 11 for our static assets. For Dynamic assets like API responses , we should use smaller values – a high compression time can backfire, and put all our efforts to improve latency to turmoil.

Results :

26% Reduction in CSS file-sizes

17% Reduction in Javascript file-sizes

Overall Results

Brotli from Origin Now Available for Akamai

What is Brotli from Origin?
Brotli from Origin specifically configures Akamai delivery to work well for customers that are providing Brotli-compressed resources at origin. The Brotli from Origin behavior allows for Akamai to deliver the Brotli-compressed resource when supported by the requesting user agent; otherwise, when not supported, non-Brotli resources are automatically used.

What are the benefits of Brotli from Origin?
With Brotli from Origin, Akamai now has a comprehensive Brotli solution that can be applied for resources already compressed at the origin. By applying Brotli compression to resources, you can reduce bandwidth consumption and improve web performance above and beyond what gzip can do.

How do I enable Brotli from Origin?

• To enable it, simply add the behavior through Property Manager (On/Off setting). It can also be enabled through the Property Manager API.

How is Brotli from Origin different from Akamai Resource Optimizer?
Resource Optimizer takes resources from origin and applies Brotli compression to them as they come into the Akamai platform. They are then cached and delivered with Brotli compression. Brotli from Origin basically extends this approach to support resources already compressed at origin and enables them to be served through the Akamai cloud delivery platform and back to the browser. In other words, Akamai now supports both origins that provide Brotli compression as well as origins that do not. For origins that do not, Akamai now automatically provides Brotli compression.

We think it’s a great solution.

[My-Version] – NGINX Performance Tuning.

Good evening bloggers,

Lately have been facing an issue with websites getting loaded, so with all my experience, I tried to deploy my Super Saiyan on the Nginx webserver

This is what I did,

#############################################################

sysctl -w net.core.rmem_max=8388608
sysctl -w net.core.rmem_default=65536
sysctl -w net.core.wmem_max=8388608
sysctl -w net.core.wmem_default=65536
sysctl net.ipv4.tcp_window_scaling
sysctl -w net.ipv4.tcp_mem=’8388608 8388608 8388608′
sysctl -w net.ipv4.tcp_rmem=’4096 87380 8388608′
sysctl -w net.ipv4.tcp_wmem=’4096 65536 8388608′
sysctl -w net.ipv4.route.flush=1
sysctl -w net.ipv4.tcp_retries2=7
sysctl -w vm.overcommit_memory=2
sysctl -w vm.overcommit_ratio=25
sysctl -w vm.swappiness=25

#############################################################

dd if=/dev/zero of=/swapfile count=8192 bs=1MiB (use this)
#fallocate -l 8G /swapfile (or this)
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo “/swapfile none swap sw 0 0” | sudo tee -a /etc/fstab

#############################################################

vim /etc/nginx/nginx.conf

(Edit the following Sections)

worker_processes auto;

events {
worker_connections 4000;
use epoll;
}

worker_rlimit_nofile 10000;

http {

fastcgi_read_timeout 300;
proxy_read_timeout 300;

}

service nginx reload

############################################################

vim /etc/security/limits.conf

<os user> soft nofile 350000
<os user> hard nofile 350000
<os user> soft nproc 65536
<os user> hard nproc 65536
<os user> soft stack 10240
<os user> hard stack 10240
<os user> soft nofile 350000
<os user> hard nofile 350000

############################################################

vim /etc/security/limits.d/90-nproc.conf

* soft nproc unlimited

############################################################

After this, we tested 2000 users on JMeter and we hardly got 0.45 % of errors from 47% before tuning.

Please do try this and still if it doesn’t work, then please do a post on the comment section.

 

HTTP Status Codes:- 1xx (Informational)

• 100 Continue :- The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed.
• 102 Processing (WebDAV) :- The 102 (Processing) status code is an interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 (Processing) response. The server MUST send a final response after the request has been completed.Methods can potentially take a long period of time to process, especially methods that support the Depth header. In such cases the client may time-out the connection while waiting for a response. To prevent this the server may return a 102 (Processing) status code to indicate to the client that the server is still processing the method.

• 101 Switching Protocols :-The server understands and is willing to comply with the client’s request, via the Upgrade message header field, for a change in the application protocol being used on this connection.The server will switch protocols to those defined by the response’s Upgrade header field immediately after the empty line which terminates the 101 response. The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.