speed up | LinuxHostSupport

How To Speed Up a Website on Debian 9

admin — Thu, 15 Jul 2021 17:30:26 +0000

Speeding up a website is a very important process because most of the visitors will leave a slow website and visit a competitor’s website instead of suffering a delay. Also, they would not return to a website with poor loading speed. A faster page load speed gives visitors a better user experience. The impact of website speed is huge on search engine rankings too. If you strive to achieve good rankings on search engines, make sure to optimize your website for speed. Before we start working on improving the website speed, it is a good idea to know what is an acceptable web page speed. In general, the best practice is around three seconds.

There are many different steps we can take to increase website speed and improve user experience. In this guide, we will show you how to speed up a website on a Debian 9 VPS.

Listed below are the most efficient ways to increase the website speed:

Enable GZIP compression

Enabling website compression allows the web page to load faster, so if you have Apache2 installed and running on your Debian VPS, enable Gzip module (mod_deflate) using the following command:

sudo a2enmod deflate

Restart the Apache service for the changes to take effect:

service apache2 restart

Create a .htaccess file in the document root directory of your website (or modify it if it exists) and add the following code in it:

AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent

Enable Expires Header to static resources

When visiting a website, the website will cache in the visitor’s web browser. Adding Expires headers to static resources is useful because it reduces the web page loading speed for subsequent page views/return visits from returning visitors. In order to enable Expires headers to static resources, we need to add the following code in the .htaccess file:

ExpiresActive On
ExpiresDefault A0
ExpiresByType image/gif A2592000
ExpiresByType image/png A2592000
ExpiresByType image/jpg A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType image/ico A2592000
ExpiresByType text/css A2592000
ExpiresByType text/javascript A2592000

Where A2592000 means 1 month.

Use a Content Delivery Network (CDN)

Using a CDN is a great way to achieve a better user experience and reduce the load speed of a website. When using a CDN, the website files are cached on many servers in different locations of the world and whenever a visitor accesses your website, the requests to your website are served from a nearby server.

Use advanced caching mechanisms

Use a caching mechanism that works efficiently to optimize your website for speed. By enabling a caching mechanism, we can reduce the time it takes for repeat visitors to load the website. Depending on the website content (static, dynamic, and/or database-driven), we can install and use Varnish, Redis, Memcached, etc. All caching mechanisms allow web applications to store data and recall it from memory very fast. Also, if you use a CMS on your website, try to install a caching plugin/extension.

Minify JavaScript and CSS files

Minify all JavaScript files over 4 KB of size.

Remove all unused CSS code. Minify the CSS code by stripping out unnecessary characters and spaces thus reduce its file size.

Load the CSS code inside the element, and JavaScript code inside the , usually to the bottom of your web pages.

Optimize Images

Larger images take longer to download than smaller ones. Try to use smaller images, and keep the number of images to an absolute minimum. Use images in an appropriate format. such as JPG, SVG, PNG, and GIF format.

Optimize the database

To optimize the website loading time, it is important to optimize the MySQL database used by your website too.

If you use a MySQL database on your website, use the following command to optimize it:

mysqlcheck -u -p -o

Replace with the actual MySQL username and with your MySQL database name respectively.

Remove Unnecessary Plugins and Add-ons

If you use a CMS on your website, try to delete all unused themes, extensions, plugins, add-ons, etc. Of course, you don’t have to speed up your website on Debian 9, if you use one of our Linux server management services, in which case you can simply ask our expert Linux admins to help you speed up and optimize your website for you. They are available 24×7 and will take care of your request immediately.

If you liked this post, on how to speed up your website on Debian 9, please share it with your friends on the social networks using the buttons below or simply leave a reply in the comments section.

The post How To Speed Up a Website on Debian 9 appeared first on LinuxHostSupport.

How to Speed Up a Website on CentOS 7

admin — Wed, 24 Oct 2018 07:41:12 +0000

Accelerating the website can often be a demanding job requiring detailed planning, knowledge of different areas, with a focus on testing and evaluation. Often, there are several teams working on this segment: web developers, system administrators, network experts, and other professionals. In this article, we will show you how to speed up a website on a CentOS 7 server.

Why is the website speed so important?

The answer is simple – the download speed affects the ranking of your website on search engines. The website’s download speed is included in the search engine ranking factors, and therefore this is an important SEO factor. Slow websites negatively affect the conversion rates that are crucial to the success of every online business.

Use fast and reliable hosting

It’s obvious that you need to use reliable web hosting if you want your website to be loaded fast.

Enable gzip compression

Images are mostly compressed, but textual content leaves plenty of room for “zipping”. The web server can be configured to send compressed content to all web browsers that can accept it. This makes sense to do with all the textual content, such as HTML, JavaScript, CSS, text, and XML files.

Compressed files are much smaller and are downloaded much faster, which in the end greatly reduces the time needed to load those content from the end user. The process of compression (on the server side) and decompression (on the client side) burdens the processor, but modern processors are fast and easy to cope with, while the speed of the Internet connection is still often a bottleneck. So compression contributes to the overall speed of the website, in the vast majority of cases.

All new web browsers allow you to read HTML, CSS and Javascript files in compressed form.

In order to enable GZIP compression, it is necessary to configure the web server so that it compresses all files before sending it compressed in GZIP format. Specific configuration commands depend on the type of the server. On CentOS servers with Apache, the simplest solution is to modify the .htaccess file located in the root directory of your website.

vi .htaccess

If you do not have this file, you need to create it yourself and enter the following code into it:


# Enable HTML, CSS, JavaScript, Text, XML and font compression
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml

#Remove browser bugs (only needed for really old browsers)
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent

Configure web browser caching

An important setting is “expiration date”, that determines the “shelf life” of a file on the server. If the “expiration date” is not set for the files, they will be loaded directly from the server at each request by the visitor. Otherwise, the web browser will load the same file on the user’s computer, not the server, if it has to load the file on the user’s computer again. The result is clear, saving in loading time and resources is enormous. This setting is recommended mostly for static content on the site, which is rarely being changed. These can be images, Javascript, and even CSS files.

In order to allow caching of such files, it is necessary to re-edit the .htaccess file in the root directory of the website, i.e. add the following code to it:



Header set Cache-Control "max-age=2592000, public"


Header set Cache-Control "max-age=2592000, public"


Header set Cache-Control "max-age=216000, private"


Header set Cache-Control "max-age=216000, public, must-revalidate"


Header set Cache-Control "max-age=1, private, must-revalidate"




ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access plus 1 year"
ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
ExpiresByType application/x-font-ttf "access plus 1 month"
ExpiresByType application/x-font-woff "access plus 1 month"
ExpiresByType font/opentype "access plus 1 month"
ExpiresByType image/svg+xml "access plus 1 month"

By using these simple .htaccess rules for caching, you can dramatically improve the speed of the website.

Use a CDN

Content Delivery Network (CDN) is a collection of web servers distributed across multiple locations in order to provide more efficient content delivery to users. Using this solution can help your website get faster by 20% or more.

Reduce HTTP requests

In order to reduce page loading time, you also need to reduce HTTP requests. This means that you need to:

reduce the number of JavaScript files or try combining many JavaScript files into one bigger file,
reduce the number of CSS files or try combining many CSS files into one bigger file,
reduce the number of images.

That’s it, your website should be faster now. If your website based on WordPress, you can use plugins to do some of the steps mentioned above.

If you use one of our premium server management services our expert system engineers can speed up and optimize your website for blazing fast speeds. They are available 24×7 and will take care of your request immediately.

PS. If you liked this post on how to speed up your website on CentOS 7, please share it with your friends on the social networks using the buttons below or simply leave a reply in the comments sections. Thanks.

The post How to Speed Up a Website on CentOS 7 appeared first on LinuxHostSupport.

How to Speed Up Drupal Using Varnish on Debian 9

admin — Wed, 14 Mar 2018 07:59:44 +0000

We’ll show you how to speed up Drupal using Varnish on a Debian 9 VPS. Drupal is a popular open source web content management software written in PHP. Drupal is compatible with Varnish 3 and Varnish 4. It is a cross-platform application and supports all popular operating systems, but this tutorial was written for Debian 9 OS. At the time of writing this tutorial, the latest stable version of Drupal is 8.4.4, and it requires:

PHP 5.5.9 or higher (preferably PHP 7.0), with GD library, JSON, cURL, mysqli , Mbstring, DOM, OpenSSL and XML PHP extensions enabled. PHP 7.2 is not supported on the current release.
MySQL – 5.5.3 (MariaDB 5.5.20, Percona 5.5.8) or higher with an InnoDB-compatible primary storage engine, PostgreSQL – 9.1.2 or higher, or QLite – 3.6.8 or higher
Apache web server 2.2 or higher compiled with mod_rewrite module and AllowOverride set to ‘All’ (please note, the default setting for AllowOverride in Apache 2.3.9 and higher is ‘None’).

This install guide assumes that Apache and MySQL/MariaDB are already installed and configured on your virtual server.
Let’s start with the installation procedure.

1. Update the System Packages

Make sure your server Debian 9 OS packages are fully up-to-date:

apt-get update 
apt-get upgrade

2. Install the Required Packages

Install the required PHP packages for Drupal 8:

apt-get install php7.0 php7.0-cli php7.0-common php7.0-mbstring php7.0-curl php7.0-gd php7.0-json php7.0-mcrypt php7.0-mysql php7.0-xml

3. Enable Apache Rewrite Module

Enable Apache rewrite module if it is not already done so:

a2enmod rewrite

4. Restart Apache

Restart the Apache service for the changes to take effect:

service apache2 restart

5. Download and Extract Drupal 8 Files

Download Drupal 8 and install if from source, or install Drupal 8 using Composer.

5.1 Download Drupal 8 from source

Download the latest version of Drupal available at https://www.drupal.org/download in the /opt/ directory on the server:

cd /opt/
mkdir -p /var/www/html/yourdomain.com/
wget -O drupal8.tar.gz https://ftp.drupal.org/files/projects/drupal-8.4.4.tar.gz
tar -xvzf drupal*
mv drupal-*/* /var/www/html/yourdomain.com/

5.2 Download and Install Drupal 8 using Composer – a PHP dependency manager

If you downloaded and extracted Drupal from source, you can skip this step and go to step 6.
Install Composer:

apt-get install composer

mkdir -p /var/www/html/yourdomain.com/
cd /var/www/html/yourdomain.com/

To install the Drupal 8 website on a development server, run:

composer create-project drupal-composer/drupal-project:8.x-dev /var/www/html/yourdomain.com/ --stability dev --no-interaction

Optionally, install Twig C extension:

composer require twig/twig:~1.0

To install the Drupal 8 website on a production server, you also need to run:

composer install --no-dev

This will run the composer install process again remove everyhing from the “require-dev” section from the composer.lock file.

6. Set Proper Ownership of Drupal Files

All files have to be readable by the web server, so set a proper ownership:

chown www-data:www-data -R /var/www/html/yourdomain.com/

7. Create MySQL Database and User

Create a new MySQL database and user:

mysql -u root -p
mysql> SET GLOBAL sql_mode='';
mysql> CREATE DATABASE drupaldb;
mysql> CREATE USER 'drupaluser'@'localhost' IDENTIFIED BY 'y0uR-pa5sW0rd';
mysql> GRANT ALL PRIVILEGES ON drupaldb.* TO 'drupaluser'@'localhost';
mysql> FLUSH PRIVILEGES;
mysql> quit

Do not forget to replace ‘y0uR-pa5sW0rd’ with a strong password.

8. Install and Configure Varnish

apt-get install varnish

Configure Varnish to listen on port 80. Edit the ‘/etc/default/varnish’ Varnish configuration file:

nano etc/default/varnish

Add these lines at the end:

DAEMON _OPTS="-a :80\
  -T localhost:6082
  -f /etc/varnish/default.vcl
  -s malloc,512m"
  -S /etc/varnish/secret

Create a new varnish startup script for systemd:

nano /etc/systemd/system/varnish.service

[Unit]
Description=Varnish HTTP accelerator
Documentation=https://www.varnish-cache.org/docs/4.1/ man:varnishd

[Service]
Type=simple
LimitNOFILE=131072
LimitMEMLOCK=82000
ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,512m
ProtectSystem=full
ProtectHome=true
PrivateTmp=true
PrivateDevices=true

[Install]
WantedBy=multi-user.target

Run the following command to reload systemd manager configuration:

systemctl daemon-reload

Back up default.vcl:

mv /etc/varnish/default.vcl /etc/varnish/default.vcl.bak

Create a new default.vcl file (do not forget to change yourdomain.com with the actual domain name):

nano /etc/varnish/default.vcl

Add these lines

backend default {

.host = “yourdomain.com“;

.port = “8080”;

}

# Access control list for PURGE requests.
# Here you need to put the IP address of your web server
acl purge {
“127.0.0.1”;
}

# Respond to incoming requests.
sub vcl_recv {
# Add an X-Forwarded-For header with the client IP address.
if (req.restarts == 0) {
if (req.http.X-Forwarded-For) {
set req.http.X-Forwarded-For = req.http.X-Forwarded-For + “, ” + client.ip;
}
else {
set req.http.X-Forwarded-For = client.ip;
}
}

# Only allow PURGE requests from IP addresses in the ‘purge’ ACL.
if (req.method == “PURGE”) {
if (!client.ip ~ purge) {
return (synth(405, “Not allowed.”));
}
return (hash);
}

# Only allow BAN requests from IP addresses in the ‘purge’ ACL.
if (req.method == “BAN”) {
# Same ACL check as above:
if (!client.ip ~ purge) {
return (synth(403, “Not allowed.”));
}

# Logic for the ban, using the Cache-Tags header. For more info
# see https://github.com/geerlingguy/drupal-vm/issues/397.
if (req.http.Cache-Tags) {
ban(“obj.http.Cache-Tags ~ ” + req.http.Cache-Tags);
}
else {
return (synth(403, “Cache-Tags header missing.”));
}

# Throw a synthetic page so the request won’t go to the backend.
return (synth(200, “Ban added.”));
}

# Only cache GET and HEAD requests (pass through POST requests).
if (req.method != “GET” && req.method != “HEAD”) {
return (pass);
}

# Pass through any administrative or AJAX-related paths.
if (req.url ~ “^/status\.php$” ||
req.url ~ “^/update\.php$” ||
req.url ~ “^/admin$” ||
req.url ~ “^/admin/.*$” ||
req.url ~ “^/flag/.*$” ||
req.url ~ “^.*/ajax/.*$” ||
req.url ~ “^.*/ahah/.*$”) {
return (pass);
}

# Removing cookies for static content so Varnish caches these files.
if (req.url ~ “(?i)\.(pdf|asc|dat|txt|doc|xls|ppt|tgz|csv|png|gif|jpeg|jpg|ico|swf|css|js)(\?.*)?$”) {
unset req.http.Cookie;
}

# Remove all cookies that Drupal doesn’t need to know about. We explicitly
# list the ones that Drupal does need, the SESS and NO_CACHE. If, after
# running this code we find that either of these two cookies remains, we
# will pass as the page cannot be cached.
if (req.http.Cookie) {
# 1. Append a semi-colon to the front of the cookie string.
# 2. Remove all spaces that appear after semi-colons.
# 3. Match the cookies we want to keep, adding the space we removed
# previously back. (\1) is first matching group in the regsuball.
# 4. Remove all other cookies, identifying them by the fact that they have
# no space after the preceding semi-colon.
# 5. Remove all spaces and semi-colons from the beginning and end of the
# cookie string.
set req.http.Cookie = “;” + req.http.Cookie;
set req.http.Cookie = regsuball(req.http.Cookie, “; +”, “;”);
set req.http.Cookie = regsuball(req.http.Cookie, “;(SESS[a-z0-9]+|SSESS[a-z0-9]+|NO_CACHE)=”, “; \1=”);
set req.http.Cookie = regsuball(req.http.Cookie, “;[^ ][^;]*”, “”);
set req.http.Cookie = regsuball(req.http.Cookie, “^[; ]+|[; ]+$”, “”);

if (req.http.Cookie == “”) {
# If there are no remaining cookies, remove the cookie header. If there
# aren’t any cookie headers, Varnish’s default behavior will be to cache
# the page.
unset req.http.Cookie;
}
else {
# If there is any cookies left (a session or NO_CACHE cookie), do not
# cache the page. Pass it on to Apache directly.
return (pass);
}
}
}

# Set a header to track a cache HITs and MISSes.
sub vcl_deliver {
# Remove ban-lurker friendly custom headers when delivering to client.
unset resp.http.X-Url;
unset resp.http.X-Host;
# Comment these for easier Drupal cache tag debugging in development.
unset resp.http.Cache-Tags;
unset resp.http.X-Drupal-Cache-Contexts;

if (obj.hits > 0) {
set resp.http.Cache-Tags = “HIT”;
}
else {
set resp.http.Cache-Tags = “MISS”;
}
}

# Instruct Varnish what to do in the case of certain backend responses (beresp).
sub vcl_backend_response {
# Set ban-lurker friendly custom headers.
set beresp.http.X-Url = bereq.url;
set beresp.http.X-Host = bereq.http.host;

# Cache 404s, 301s, at 500s with a short lifetime to protect the backend.
if (beresp.status == 404 || beresp.status == 301 || beresp.status == 500) {
set beresp.ttl = 10m;
}

# Don’t allow static files to set cookies.
# (?i) denotes case insensitive in PCRE (perl compatible regular expressions).
# This list of extensions appears twice, once here and again in vcl_recv so
# make sure you edit both and keep them equal.
if (bereq.url ~ “(?i)\.(pdf|asc|dat|txt|doc|xls|ppt|tgz|csv|png|gif|jpeg|jpg|ico|swf|css|js)(\?.*)?$”) {
unset beresp.http.set-cookie;
}

# Allow items to remain in cache up to 6 hours past their cache expiration.
set beresp.grace = 6h;
}

9. Change Apache Listening ports

nano /etc/apache2/ports.conf

Change:
Listen 80
to
Listen 8080

Edit the main Apache configuration file (/etc/apache2/apache2.conf), search for ” and change ‘AllowOverride None’ to ‘AllowOverride All’ so it looks like:

Options Indexes FollowSymLinks
AllowOverride All
Require all granted

Also, change the port from 80 to 8080 in all virtual hosts located in /etc/apache2/sites-available directory.

10. Create a New Virtual Host in Apache

Create a new virtual host directive in Apache. For example, create a new Apache configuration file named ‘yourdomain.conf’ on your virtual server:

touch /etc/apache2/sites-available/yourdomain.conf
ln -s /etc/apache2/sites-available/yourdomain.conf /etc/apache2/sites-enabled/yourdomain.conf
nano /etc/apache2/sites-available/yourdomain.conf

Then, add the following lines:

ServerAdmin admin@your-domain.com
DocumentRoot /var/www/html/yourdomain.com
ServerName yourdomain.com
ServerAlias www.yourdomain.com

SetHandler application/x-httpd-php

Options FollowSymLinks
AllowOverride All

DirectoryIndex index.php
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require all granted

ErrorLog /var/log/apache2/yourdomain.com-error_log
CustomLog /var/log/apache2/yourdomain.com-access_log common

If you downloaded Drupal 8 using Composer, replace ‘/var/www/html/yourdomain.com’ with ‘/var/www/html/yourdomain.com/web’ in the ‘DocumentRoot’ and ‘Directory’ virtual host directives.

11. Restart Apache and Varnish

Restart Apache and Varnish services for the changes to take effect:

service apache2 restart
service varnish restart

12. Install Drupal 8

Open http://yourdomain.com in a web browser , choose install language, click on the ‘Save and continue’ button, select an installation profile (standard), enter the database name, username and password and start the installation. Once installed, you will automatically be redirected to the Drupal 8 administration back-end.

13. Configure Caching

Go to the Drupal 8 administration back-end, click Configuration >> Performance >> set the page cache maximum age and click on the ‘Save configuration’ button:

14. Install Purge and Varnish Purger Modules in Drupal 8

Install the Purge module from the Drupal 8 administration back-end by clicking on Extend >> Install new module , then enter: https://ftp.drupal.org/files/projects/purge-8.x-3.0-beta8.tar.gz in the ‘Install from a URL’ field and click on the ‘Install’ button.

Then, install the Varnish Purger module by clicking on Extend >> Install new module >> enter: https://ftp.drupal.org/files/projects/purge-8.x-3.0-beta8.tar.gz in the ‘Install from a URL’ field and click on the ‘Install’ button.

Open http://yourdomain.com/admin/modules and select Purge, Purge Drush, Purge Tokens, Purge UI, Cron processor, Late runtime processor, Core tags queuer, Varnish Focal Point Purger, Varnish Image Purge, Varnish Purger and Varnish Purger Tags, then click on the ‘Install’ button.

15. Configure Varnish Purger

Open http://yourdomain.com/admin/config/development/performance/purge , click Add purger >> Varnish Purger and click on the ‘Add’ button. Click on the newly created button, select configure and add ‘Varnish Purger’ in the name field:

Configure the Purger’s headers by clicking on Headers >> and enter ‘Cache-Tags’ in the header field with the value [invalidation:expression] and click on the ‘Save configuration’ button.

16. Test if Varnish Caching works

In order to test if Varnish caching is woking properly, run the following command on your server:

curl -s --head http://yourdomain.com/about | grep -i cache
Cache-Tags: MISS

Then, run it once again:

curl -s --head http://yourdomain.com/about | grep -i cache

You should receive an output like this:

Cache-Tags: HIT

You can also use varnishadm, varnishstat and varnishlog command line utilities to check if everything works OK.

That is it. Drupal 8 has been configured to use Varnish.

Of course you don’t have to speed up Drupal using Varnish on Debian 9, if you use one of our Linux Server Support Services, in which case you can simply ask our expert Linux admins to do this for you. They are available 24×7 and will take care of your request immediately.

PS. If you liked this post, on how to speed up Drupal using Varnish on Debian, please share it with your friends on the social networks using the buttons on the left or simply leave a reply below. Thanks.

The post How to Speed Up Drupal Using Varnish on Debian 9 appeared first on LinuxHostSupport.

Speed Up SSH Connections in Linux

admin — Wed, 03 Jan 2018 08:16:10 +0000

We’ll show you, how to speed up SSH connections in Linux. SSH is a very secure method for managing Linux servers. Sometimes it can be very slow especially if you need to open multiple SSH connections to your server. One such scenario would be if you use Git for your development work, as Git uses multiple SSH connections to transfer files and if your server is not configured correctly it will add unnecessary overhead by re-establishing a connection for every file transferred. In today’s tutorial we are going to learn how to speed up SSH connections in Linux. Let’s get started!

1. Disable DNS lookup on the server

The OpenSSH server has DNS lookups enabled by default, this means that the OpenSSH server will first look up the host name of the connecting host and then will check if the resolved host name’s IP address is the same as the connecting IP address.To disable DNS lookups, add the ‘UseDNS’ directive at the end of the ‘/etc/ssh/sshd_config’ file and set the value to ‘no’:

# nano /etc/ssh/sshd_config

# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

# Disable DNS lookups
UseDNS no

2. Re-use existing SSH connection

If you open multiple SSH connections to your server frequently, it would be best to configure your SSH client to use the existing connection when creating a new SSH session.This can speed up the sessions opened after the initial connection as it avoids the overhead of establishing a new connection.

Open the ‘~/.ssh/config’ file with nano and add the following lines in it:

# nano ~/.ssh/config

Host *
ControlMaster auto
ControlPath  ~/.ssh/sockets/%r@%h-%p
ControlPersist 600

The ‘Host *’ directive above tells the SSH client to re-use the initial connection for all remote servers.

3. Setting up a password-less SSH login

Setting up a password-less SSH login is pretty easy and saves you time because you don’t have to enter a password when you open a new SSH connection.This can be done in three easy steps.

1.Generate the public/private key pair using this command:

# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): Press Enter.
Enter passphrase (empty for no passphrase): Press Enter.
Enter same passphrase again: Press Enter.
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:/LEFoGKAt/qC9NeEfIfWm988IUqJaAuYBDvuDuu/jk8 root@test
The key's randomart image is:
+---[RSA 2048]----+
| ..     .        |
|o ..   . .       |
|.o .o .   .      |
|o... . .   .     |
|ooo . o S o .    |
|.= . = * * = .   |
|=..Eo * o * . .  |
|+o+. o . +  o.   |
|+=+=o     .. o.  |
+----[SHA256]-----+

2.Copy the public key to the remote server using this command:

# ssh-copy-id -i ~/.ssh/id_rsa.pub remote-server
root@remote-server's password:
Now try logging into the machine, with "ssh 'remote-server'", and check in:

.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

3.Log in to the remote server to check if the password-less login is working:

# ssh remote-server

Last login: Thu Dec 28 20:10:38 2017 from 10.20.30.4


root@remote-server$

If everything goes well you should see the output displayed above.

4. Changing the encryption used by the OpenSSH server

Changing the default cipher order for the SSHv2 protocol on the OpenSSH server can further speed up SSH connections as some ciphers can encrypt data faster than others.
For Ubuntu 16.04 the default order according to ‘man ssh_config’ is:

The default is:

	chacha20-poly1305@openssh.com,
	aes128-ctr,aes192-ctr,aes256-ctr,
	aes128-gcm@openssh.com,aes256-gcm@openssh.com,
	aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc

If you do have a server which supports the new AES-NI instructions it would be better to change this order and add it to the end of the ‘/etc/ssh/sshd_config’ file like this:

# nano /etc/ssh/sshd_config

# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

# Disable DNS lookups
UseDNS no

# Change the order of the ciphers used
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,chacha20-poly1305@openssh.com,3des-cbc

According to several benchmarks available online, aes128-ctr is twice as fast as chacha20-poly1305 on processors that support the AES-NI instructions so if you have a high-bandwidth connection to your server the file transfer speed should increase significantly after making the change.

That’s it, now your SSH connections should be a lot faster.

Of course, you don’t have to Speed Up SSH Connections in Linux, all by yourself, if you use one of our outsourced linux support services, in which case you can simply ask our expert Linux admins to speed up the SSH connections on your Linux server for you. They are available 24×7 and will take care of your request immediately.

PS. If you liked this post on how to speed up SSH connections in Linux, please share it with your friends on the social networks using the buttons on the right or simply leave a reply below. Thanks.

The post Speed Up SSH Connections in Linux appeared first on LinuxHostSupport.