Litespeed vs NGINX

Comparing NGINX and LiteSpeed

In a series of benchmarking tests, LiteSpeed’s HTTP/3 implementation demonstrated higher performance than that of the hybrid NGINX/Quiche.

Overall, LiteSpeed managed to transfer resources faster, demonstrate stronger scaling, and utilized less CPU & memory in the process. LiteSpeed bettered NGINX in all of these metrics by a factor of two or above. While NGINX was unable to complete certain tests, it achieved just below TCP speed in others.

Below, we’ll delve deep into the setup process and the range of benchmarks used.

  1. LiteSpeed vs NGINX: Why it Matters
  2. What is Cloudlare’s Patch for Quiche?
  3. Benchmarking Setup
  4. NGINX vs LiteSpeed: Benchmark Testing
  5. LiteSpeed Found to be More Impressive than NGINX

LiteSpeed vs NGINX HTTP/3: Why it Matters

HTTP/3 is a new web protocol, succeeding Google QUIC and HTTP/2. With the IETF QUIC Working Group approaching a finalized version of the drafts, it’s clear that the nascent HTTP/3 implementations are becoming more mature and some are beginning to see production use.

LiteSpeed became the first to ship HTTP/3 support in LiteSpeed Web Server, and QUIC has been supported since 2017. Improvements have been made here and there. It’s on this foundation that the support for HTTP/3 stands.

Recently, Cloudflare launched a special HTTP/3 NGINX patch and encouraged users to start experimenting.

What is Cloudlare’s Patch for Quiche?

Quiche is Cloudflare’s HTTP/3 and QUIC library, written in Rust (this language is high level and new). Said library provides a C API, which is how NGINX uses it.

Benchmarking Setup

The Platform

Both the servers and load tool run on the same VM. This is an Ubuntu-14 machine featuring a 20 core Intel Xeon E7-4870 and 32GB RAM. Netem was used to modify the bandwidth and RTT.

The Servers

We leveraged OpenLiteSpeed, an open-source version of the LiteSpeed Web Server (specifically, version 1.6.4.).

With regards to NGINX, we utilized 1.16.1 with Cloudflare’s Quiche patch.

OpenLiteSpeed and NGINX had been configured to utilize a single worker process, and NGINX’s maximum requests setting was boosted to 10,000. This enabled us to issue 1,000,000 requests with 100 connections.

# OpenLiteSpeed
httpdWorkers 1
# nginx
worker_processes 1;
http {
    server {
        access_log off;
        http3_max_requests 10000;
    }
}

The Website

This comprised a simple collection of static files, including a 163 byte index file with files of varied sizes (1MB, 10MB, 100MB, 1GB).

The Load Tool

Load was generated with h2load with HTTP/3 support . This is easy to build when utilizing the Dockerfile supplied.

NGINX vs LiteSpeed: Benchmark Testing

We ran three LiteSpeed or NGINX tests and took the median value to get each number (the requests per second or resource fetch time).

LiteSpeed or NGINX: small page fetching

This testing involved fetching the 163 byte index page in numerous ways, through multiple network conditions. Key h2load options:
  • -n: Overall number of requests to be sent
  • -c: Amount of connections
  • -m: Amount of concurrent requests for each connection
  • -t: Amount of of h2load threads
-n 10000 -c 100
LiteSpeed NGINX
100 mbps, 100 ms RTT 925 reqs/sec 880 reqs/sec
100 mbps, 20 ms RTT 3910 reqs/sec 2900 reqs/sec
100 mbps, 10 ms RTT 6400 reqs/sec 4150 reqs/sec
-n 100000 -c 100 -t 10 Every connection will send 1000 requests now, with this being a longer run.
LiteSpeed NGINX
100 mbps, 100 ms RTT 995 reqs/sec 975 reqs/sec
100 mbps, 20 ms RTT 4675 reqs/sec 4510 reqs/sec
100 mbps, 10 ms RTT 8410 reqs/sec 7100 reqs/sec
At 100ms, LiteSpeed is quite a bit faster. But its speed increases substantially at 20ms and 10ms RTT. -n 100000 -c 100 -m 10 -t 10
LiteSpeed NGINX
100 mbps, 100 ms RTT 9100 reqs/sec 7380 reqs/sec
100 mbps, 20 ms RTT 24550 reqs/sec 5790 reqs/sec *
100 mbps, 10 ms RTT 25120 reqs/sec 6730 reqs/sec *
* High variance It was fascinating to find in the initial test that NGINX used 100 percent CPU, when OpenLiteSpeed utilized around 45 percent CPU only. This is why NGINX’s numbers tend to not improve despite the RTT dropping. Still, OpenLiteSpeed doesn’t utilize 100 percent CPU even with 20 and 10ms RTTs. -n 1000000 -c 100 -m 10 -t 10 We had to set the NGINX http3_max_requests parameter to 10000 (from the 1000 default value) to make sure it could issue in excess of 1000 requests for each connection.
LiteSpeed NGINX
200 mbps, 10 ms RTT 29140 reqs/sec 7120 reqs/sec *
* High variance At this point, LiteSpeed was using 100 percent CPU. NGINX allocated in excess of 1GB of memory during this test, while LiteSpeed remained below 28MB. So, that equates to greater than four times the performance for approximately 1/37th of the price.

Single file fetching

In this situation, we fetched a single file using alternative network conditions and measured the length of time required to download it. 10MB
LiteSpeed NGINX
10 mbps, 100 ms RTT 9.6 sec 10.9 sec
10 mbps, 20 ms RTT 9.6 sec 10.5 sec
10 mbps, 10 ms RTT 9.4 sec 10.8 sec
It’s clear that NGINX is a little slower here. It also utilizes three to four times more CPU than LiteSpeed did in the above tests. 100MB
LiteSpeed NGINX
100 mbps, 100 ms RTT 11.9 sec 39 sec *
100 mbps, 20 ms RTT 9.2 sec 38 sec *
100 mbps, 10 ms RTT 8.9 sec 29 sec
*High variance Across all three of the NGINX vs LiteSpeed benchmarks, NGINX utilized 100 percent CPU. It’s highly likely this is the cause of its weaker performance. 1GB We attempted to download a 1GB file with NGINX at 1gbps. However, we became tired of waiting for the download to complete. We believe the contrast in LiteSpeed and NGINX’s respective performance was pronounced at this speed.

NGINX vs LiteSpeed: Shallow Queue

NGINX has struggled with high bandwidth, so we decided to see how it would fare with low bandwidth instead. We used a shallow queue with netem’s limit parameter and set it to seven. Single 10MB file fetching
limit LiteSpeed NGINX
5 mbps, 20 ms RTT 1000 * 19.5 sec 23.1 sec
5 mbps, 20 ms RTT 7 29.5 sec 47.9 sec
*netem default We found LiteSpeed’s performance decreased by around 50 percent when we introduced a shallow queue on path. However, NGINX’s performance was degraded by more than 100 percent. So, LiteSpeed was found to be substantially faster than NGINX in both situations.

Conclusion – LiteSpeed Found to be More Impressive than NGINX

In all, we used numerous LiteSpeed vs NGINX benchmarking tests, and LiteSpeed performed to a higher standard than NGINX.

Files were transferred faster and less CPU & memory were used. NGINX never reached TCP level throughput when at a low bandwidth, and its throughput was a fraction of LiteSpeed’s at a high bandwidth.

NGINX’s HTTP/3 is unprepared for production use, as it provides weak performance and consumes more memory and CPU.

We’re not surprised by this result, frankly. QUIC and HTTP/3 are complicated protocols, and new implementations will find it difficult to match LiteSpeed’s performance.

NGINX is likely to show improvement in years to come, and we’ll be interested in running further benchmark tests when that time comes. But LiteSpeed HTTP/3 can’t be beaten in the meantime.

NGINX Configuration Guide

NGINX configuration guide

NGINX is a web server designed for use cases involving high volumes of traffic. It’s a popular, lightweight, high-performance solution.

One of its many impressive features is that it can serve static content (media files, HTML) efficiently. NGINX utilizes an asynchronous event-driven model, delivering reliable performance under significant loads.

This web server hands dynamic content off to FastCGI, CGI, or alternative servers (including Apache), before it’s sent back to NGINX for delivery to clients.

In this guide on how to configure NGINX, we’ll explore the essentials of NGINX to help you understand how it works and what benefits it offers.

NGINX Configuration: Understanding Directives

Every NGINX configuration file will be found in the /etc/nginx/ directory, with the main configuration file located in /etc/nginx/nginx.conf .

NGINX configuration options are known as “directives”: these are arranged into groups, known interchangeably as blocks or contexts .

When a # appears before a line, these are comments and NGINX won’t interpret them. Lines that contain directives should end with a semicolon (;). If not, NGINX will be unable to load the configuration properly and report an error.

Below, we’ve included a shortened copy of the /etc/nginx/nginx.conf file included with installations from NGINX repositories. This file begins with four directives:

  • user

  • worker_processes

  • error_log

  • pid

These exist outside any particular context or block, and are said to be within the main context.

Additional directives are found within the events and http blocks, and these also exist within the main context.

File: /etc/nginx/nginx.conf

user nginx;

worker_processes 1;

error_log /var/log/nginx/error.log warn;

pid /var/run/nginx.pid;

events {

. . .

}

http {

. . .

}

What is the Http Block?

The http block includes directives for web traffic handling, which are generally known as universal . That’s because they get passed on to each website configuration served by NGINX.

File: /etc/nginx/nginx.conf

http {

include /etc/nginx/mime.types;

default_type application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$http_user_agent" "$http_x_forwarded_for"';

access_log /var/log/nginx/access.log main;

sendfile on;

#tcp_nopush on;

keepalive_timeout 65;

#gzip on;

include /etc/nginx/conf.d/*.conf;

}

What are Server Blocks?

The http block shown above features an include directive. This informs NGINX where website configuration files can be found.

  • When installing from NGINX’s official repository, the line will read include /etc/nginx/conf.d/*.conf; just as you can see in the http block placed above. Every website hosted with NGINX should feature a unique configuration file in /etc/nginx/conf.d/, and the name will be formatted as example.com.conf.Those sites that have been disabled — not served by NGINX — should be titled example.com.conf.disabled.

  • When installing NGINX from the Ubuntu or Debian repositories, the line will read: include /etc/nginx/sites-enabled/*;. The ../sites-enabled/ folder will include symlinks to the site configuration files located within /etc/nginx/sites-available/. You can disable sites within sites-available if you take out the symlink to sites-enabled.

  • According to the installation source, an illustrative configuration file can be found at /etc/nginx/conf.d/default.conf or etc/nginx/sites-enabled/default.

No matter the installation source, though, server configuration files feature one or more server blocks for a site. As an example, let’s look at the below:

File: /etc/nginx/conf.d/example.com.conf

server {

listen 80 default_server;

listen [::]:80 default_server;

server_name example.com www.example.com;

root /var/www/example.com;

index index.html;

try_files $uri /index.html;

}

What are Listening Ports?

The listen directive informs NGINX of the hostname/IP and TCP port, so it recognizes where it must listen for HTTP connections.

The argument default_server means that this virtual host will be answering requests on port 80 which don’t match the listen statement of a separate virtual host. When it comes to the second statement, this will listen over IPv6 and demonstrate similar behavior.

What is Name-based Virtual Hosting?

The server_name directive enables a number of domains to be served from just one IP address, and the server will determine which domain it will serve according to the request header received.

Generally, you should create one file for each site or domain you wish to host on your server. Let’s delve into some examples:

  1. Process requests for example.com and www.example.com:

  2. The server_name directive can utilize wildcards. *.example.com and .example.com tell the server to process requests for all example.com subdomains:

File: /etc/nginx/conf.d/example.com.conf

server_name *.example.com;

server_name .example.com;

  1. Process requests for all domain names starting with example.:

File: /etc/nginx/conf.d/example.com.conf

server_name example.*;

With NGINX, you can define server names that are invalid domain names: it utilizes the name from the HTTP header to answer requests regardless of whether the domain name is valid or invalid.

You may find non-domain hostnames helpful if your server is on a LAN or you know all the clients likely to make requests on the server. This encompasses front-end proxy servers with /etc/hosts entries set up for the IP address NGINX is listening on.

What are Location Blocks?

NGINX’s location setting helps you set up the way in which NGINX responds to requests for resources inside the server. As the server_name directive informs NGINX how it should process requests for the domain, location directives apply to requests for certain folders and files (e.g. http://example.com/blog/.) .

Let’s consider a few examples:

File: /etc/nginx/sites-available/example.com

location / { }

location /images/ { }

location /blog/ { }

location /planet/ { }

location /planet/blog/ { }

These locations are literal string matches and match any part of an HTTP request following the host segment:

Request: http://example.com/

Returns: Let’s assume there’s a server_name entry for example.com. In this case, the location / directive determines what occurs with this request.

With NGINX, requests are always fulfilled with the most specific match possible:

Request: http://example.com/planet/blog or http://example.com/planet/blog/about/

Returns: This will be fulfilled by the location /planet/blog directive as it’s more specific, despite location /planet being a match too.

File: /etc/nginx/sites-available/example.com

location ~ IndexPage\.php$ { }

location ~ ^/BlogPlanet(/|/index\.php)$ { }

When location directives are followed by a ~ (tilde), NGINX will perform a regular expression match, which is always case-sensitive.

For example, IndexPage.php would be a match with the first of the above examples, while indexpage.php wouldn’t.

In the second example, the regular expression ^/BlogPlanet(/|/index\.php)$ { } would match requests for /BlogPlanet/ and /BlogPlanet/index.php but not /BlogPlanet, /blogplanet/, or /blogplanet/index.php. NGINX utilizes Perl Compatible Regular Expressions (PCRE).

What if you prefer matches to be case-insensitive? Well, you should use a tilde followed closely by an asterisk: ~*. You can see the above examples define that NGINX should process requests ending in a certain file extension: the first example determines that files ending in .pl, PL, .cgi, .perl, .Perl, .prl, and .PrL (as well as others) will all be a match for the request.

File: /etc/nginx/sites-available/example.com

location ^~ /images/IndexPage/ { }

location ^~ /blog/BlogPlanet/ { }

When you add a caret and a tilde (^~) to location directives, you’re informing NGINX that, should it match a particular string, it should stop searching for more specific matches and utilize these directives here instead.

Beyond this, these directives function as the literal string matches do in the first group. Even if a more specific match comes along at a later point, the settings will be utilized if a request is a match for one of these directives.

Now, let’s look at additional details on location directive processing.

File: /etc/nginx/sites-available/example.com

location = / { }

Finally, adding an equals symbol to the location setting forces an exact match with the requested path and ends searching for matches that are more specific.

So, for example, the last example will be a match for http://example.com only, as opposed to http://example.com/index.html. If you use exact matches, you can enhance the speed of request times moderately. This can prove beneficial if certain requests are especially popular.

The processing of directives will follow this sequence flow:

  1. Exact string matches will be processed first: NGINX stops searching if a match is located and will fulfill the request.
  2. Any remaining literal string directives will be processed next. NGINX will stop and fulfill a request if it finds a match using the ^~ argument. If not, NGINX will continue processing of location directives.
  3. Each location directive with a regular expression (~ and ~*) will get processed next. If a regular expression is a match for the request, NGINX will end its search and fulfill the request.
  4. Finally, if there are no matching regular expressions, that literal string match which is most specific will be used.

Be sure that every file and folder found under a domain is a match for one or more location directives.

Nested location blocks are not recommended and not supported.

How to Use Location Root and Index

The location setting is another variable with its own arguments block.

When NGINX has identified the location directive that is the best match for a specific request, its response will be based on the associated location directive block’s contents. So, for instance:

File: /etc/nginx/sites-available/example.com

location / {

root html;

index index.html index.htm;

}

We can see, in this example, that the document root is based in the html/ directory. Under the NGINX default installation prefix, the location’s full path is /etc/nginx/html/.

Request: http://example.com/blog/includes/style.css

Returns: NGINX will try to serve the file found at /etc/nginx/html/blog/includes/style.css

Please note:

Absolute paths for the root directive can be used if you wish. The index variable informs NGINX which file it should serve when or if none are specified.

So, for instance:

Request: http://example.com

Returns: NGINX will try to serve the file found at /etc/nginx/html/index.html.

When a number of files are specified for the index directive, the list will be processed in order and NGINX will fulfill the request with the first file found to exist. If index.html can’t be located in the relevant directory, index.htm will be utilized instead. A 404 message will be delivered in the event that neither exists at all.

Let’s consider a more complicated example that showcases a number of location directives for a server responding to the example domain:

File: /etc/nginx/sites-available/example.com location directive

location / {

root /srv/www/example.com/public_html;

index index.html index.htm;

}

location ~ \.pl$ {

gzip off;

include /etc/nginx/fastcgi_params;

fastcgi_pass unix:/var/run/fcgiwrap.socket;

fastcgi_index index.pl;

fastcgi_param SCRIPT_FILENAME /srv/www/example.com/public_html$fastcgi_script_name;

}

Here, we can see that the second location block handles all requests for resources ending in a .pl extension, and it specifies a fastcgi handler for them. NGINX will use the first location directive otherwise.

Resources are found on the file system at /srv/www/example.com/public_html/. When no exact file names are defined in the request, NGINX will search for the index.html or index.htm file and provide it. A 404 error message will be returned if zero index files are located.

Let’s consider what takes place during a number of example requests:

Request: http://example.com/

Returns: /srv/www/example.com/public_html/index.html if this exists. Otherwise, it will serve /srv/www/example.com/public_html/index.htm. And if both of these don’t exist, a 404 error will be provided.

Request: http://example.com/blog/

Returns: /srv/www/example.com/public_html/blog/index.html if this exists. If the file can’t be found because it doesn’t exist, a /srv/www/example.com/public_html/blog/index.htm will be served. If neither exists, NGINX will return a 404 error.

Request: http://example.com/tasks.pl

Returns: NGINX will take advantage of the FastCGI handler to execute the file found at /srv/www/example.com/public_html/tasks.pl and return the relevant result.

Request: http://example.com/username/roster.pl

Returns: NGINX will utilize the FastCGI handler to execute the file found at /srv/www/example.com/public_html/username/roster.pl and return the relevant result.

This ends our guide on how to configure NGINX. We hope it helps you get started and set up in next to no time!

Why Do You Need PHP FastCGI Process Manager?

php fpm blog Plesk

PHP-FPM (an acronym of FastCGI Process Manager) is a hugely-popular alternative PHP (Hypertext Processor) FastCGI implementation.

As you may or may not know, PHP is one of the biggest open-source software programming languages utilized online. It features heavily in web development across such well-known platforms as Drupal, Magento, and WordPress, and was originally devised to preprocess plain text in UTF-8.

When PHP was invented by Rasmus Lerdorf in the mid-’90s, it was one of the first languages capable of featuring within HTML coding with no need to call external files.

Lerdorf’s scripting language has continued to evolve over the decades since, and it’s now supported by any web platform or operating system. However, as PHP’s publication is under the PHP licence, it’s incompatible with GNU General Public License because of restrictions related to the PHP term.

PHP-FPM Key Features

PHP-FPM includes numerous features that can prove beneficial for websites receiving traffic in large volumes frequently. These are:

  • Ability to start workers using various uid/gid/chroot/environment and php.ini, which replaces the safe mode users may expect
  • In-depth management for simple stop/start processing
  • Logging of stdout and stderr
  • Emergency restart available, in the event of an opcode cache being destroyed accidentally
  • Support for uploads is faster
  • Based on php.ini configuration files
  • Slowlog variable configuration for detecting functions that take longer than usual to execute
  • FastCGI improvements, with a special function for stopping and downloading data while completing long processes (e.g. processing statistics)
  • Basic stats are available, similar to the mod-status module in Apache

PHP-FPM and Nginx

Nginx is the ideal combination with PHP-FPM. Why? Because it’s a stable web server recognized for its impressive performance and low resource-consumption.

It features an asynchronous structure that’s highly-scalable, according to events. On top of this, memory consumption performance is significantly better when using Nginx and PHP-FPM together.

PHP runs as an isolated service when you use PHP-FPM. Employing this PHP version as the language interpreter means requests will be processed via a TCP/IP socket, and the Nginx server handles HTTP requests only, while PHP-FPM interprets the PHP code. Taking advantage of two separate services is vital to become more efficient.

PHP-FPM and HHVM

Nobody uses HHVM (HipHop Virtual Machine) anymore, as it’s unavailable. This was an open-source virtual machine, based on the Just-in-Time (JIT) compiler, serving as a PHP and Hack execution engine.

HHVM executes PHP or Hack code in intermediate Bytecode HipHop code, through the use of the Just-in-Time compiler principle. This code is converted into machine code at a later point, before being optimized natively and, eventually, executed.

This is a stark contrast to the standard PHP interpreted execution: the Zend Engine converts PHP code into opcode, via the Zend Engine virtual CPU.

PHP’s last version, along with FPM, means the language’s performance is now the same — or even better — without needing to use HHVM. It’s compatible with the majority of PHP 7 functions.

Before PHP 7 arrived, the PHP HHVM processor (created by Facebook, available on GitHub with Zend and PHP licenses) was typically used.

PHP-FPM and WordPress

An Nginx server with PHP-FPM support is crucial if you operate an online newspaper, content platform, or WordPress site receiving a huge number of visits daily. This set up enables you to facilitate the execution of your WordPress CMS’s PHP code to a higher standard.

PHP-FPM and Magento

Magento, a popular ecommerce platform, integrates with Nginx and PHP-FPM well. If you want to achieve your online store’s top performance, you’ll need to use this web server along with PHP-FPM support. Balancer and caches are essential, too.

PHP-FPM is a very challenging topic for newcomers, but we hope this guide has shed light on it. You should feel more comfortable with PHP-FPM, its features, and everything else covered above now that you’ve read our expert insights!

PHP-FPM and Plesk

To insure high performance and low memory consumption for highly loaded web apps PHP-FPM handler is available under Plesk. You need to make sure that PHP-FPM is installed and the option “Process PHP by nginx” is on under Websites & Domains > YourDomain > Web Server Settings.

Conclusion

PHP-FPM is an efficient method on how to minimize the memory consumption and rise the performance for the websites with heavy traffic. It is significantly faster than traditional CGI-based methods in multi-user PHP environments. If your primary goal for hosting your web application is to achieve optimal performance and security, then PHP-FPM is the way forward.

NGINX vs Apache – Which Is the Best Web Server in 2020?

NGINX vs Apache – which server is superior? NGINX and Apache are two of the biggest open source web services worldwide, handling more than half of the internet’s total traffic. They’re both designed to handle different workloads and to complement various types of software, creating a comprehensive web stack.

But which is best for you? They may be similar in many ways, but they’re not identical. Each has its own advantages and disadvantages, so it’s crucial that you know when one is a better solution for your goals than the other.

In this in-depth guide, we explore how these servers compare in multiple crucial ways, from connection handling architecture to modules and beyond.

First, though, let’s look at the basics of both Nginx and Apache before we take a deeper dive.

NGINX - NGINX vs Apache - Plesk

NGINX Outline

NGINX came about because of a grueling test, where a server has to reach 10,000 client connections all at the same time. It uses a non-synchronized, event-driven architecture to cope with this prodigious load. And its design means that it can take high loads and loads that vary wildly all in its stride, leveraging predictions for RAM usage, CPU usage, and latency to achieve greater efficiently.

NGINX is the brainchild of Igor Sysoev in 2002. He saw it as a solution to the C10K issue causing issues for web servers handling thousands of connections at the same time. He released it initially in 2004, and this early iteration achieved its objective through the utilization of an events-driven, asynchronous architecture.

Since its public release, NGINX has continued to be a popular choice, thanks to its lightweight utilization of resources and its flexibility to scale simply even with minimal equipment. As fans will testify, NGINX is excellent at serving static content with speed and efficiency, due to its design to pass dynamic requests to different software, which suits the specific purposes more effectively.

Administrators tend to choose NGINX because of such resource efficiency and responsiveness.

Apache - NGINX vs Apache - Plesk

Apache Outline

Robert McCool is credited with producing the Apache HTTP Server back in 1995. But as of 1999, it has been managed and maintained by the Apache Software Foundation instead. Apache HTTP Server is generally known as “Apache”, due to the HTTP web server being the foundation’s initial — and most popular — project.

Since 1996, Apache has been recognized as the internet’s most popular server, which has led to Apache receiving considerable integrated support and documentation from subsequent software projects. Administrators usually select Apache because of its power, wide-ranging support, and considerable flexibility.

It can be extended with its dynamically loadable module system, and is capable of processing various interpreted languages with no need to connect to external software

Apache vs NGINX – Handling Connections

One of the most significant contrasts between Nginx and Apache is their respective connection- and traffic-handling capabilities.

As NGINX was released following Apache, the team behind it had greater awareness of concurrency issues plaguing sites at scale. The NGINX team was able to use this knowledge to build NGINX from scratch to utilize a non-blocking, asynchronous, event-driven algorithm for handling connections. NGINX is designed to spawn worker processes capable of handling many connections, even thousands, courtesy of a fast-looping function. This searches for events and processes them continuously. As actual work is decoupled from connections easily, every worker is free to make connections only after new events are activated.

Every connection handled by the workers is situated in the event loop, alongside numerous others. Events inside the loop undergo asynchronous processing, so that work is handled in a non-blocking way. And whenever each connection closes, it will be taken out of the loop. NGINX can scale extremely far even with limited resources, thanks to this form of connection processing. As the single-threaded server doesn’t spawn processes to handle every new connection, CPU and memory utilization remains fairly consistent during periods of heavy load.

Apache offers a number of multi-processing modules. These are also known as MPMs, and are responsible for determining how to handle client requests. This enables administrators to switch its connection handling architecture simply, quickly, and conveniently.

So, what are these modules?

mpm-prefork

This Apache module creates processes with one thread to handle each request, and every child is able to accommodate one connection at one time. Provided the volume of requests remains less than that of processes, this module is capable of extremely fast performance.

But it can demonstrate a serious drop in quality when the number of requests passes the number of processes, which means this module isn’t always the right option.

Every process with this module has a major effect on the consumption of RAM, too, which makes it hard to achieve effective scaling. However, it could still be a solid choice when utilized alongside additional components built without consideration of threads. E.g. as PHP lacks thread safety, this module could be the best way to work with mod_php (Apache’s module for processing these specific files) safely.

mpm_worker

Apache’s mpm_worker module is designed to spawn processes capable of managing numerous threads each, with each of those handling one connection. Threads prove more efficient than processes, so this MPM offers stronger scaling than the module discussed above.

As there are no more threads than processes, fresh connections can take up one of the free threads rather than waiting for another suitable process to come along.

mpm_event

Apache’s third module can be considered similar to the aforementioned mpm_worker module in the majority of situations, though it’s been optimised to accommodate keep-alive connections. This means that, when using the worker module, connections continue to hold threads, whether or not requests are made actively for the full period during which the connection remains alive.

It’s clear that Apache’s connection handling architecture offers considerable flexibility when selecting various connections and request-handling algorithms. Options provided are primarily a result of the server’s continued advancement, as well as the growing demand for concurrency as the internet has changed so dramatically.

Apache vs NGINX – Handling Static and Dynamic Content

When pitting Nginx vs Apache, their ability to handle static and dynamic content requests is a common point of comparison. Let’s take a closer look.

NGINX is not designed for native processing of dynamic content: it has to pass to an external processor to handle PHP and other dynamic content requests. It will wait for content to be returned when it has been rendered, before relaying the results back to the client.

Communication has to be set up between NGINX and a processor across a protocol which NGINX can accommodate (e.g. FastCGI, HTTP, etc.). This can make things a little more complicated than administrators may prefer, particularly when attempting to anticipate the volume of connections to be allowed — an extra connection will be necessary for every call to the relevant processor.

Still, there are some benefits to using this method. As the dynamic interpreter isn’t integrated within the worker process, the overhead applies to just dynamic content. On the other hand, static content may be served in a simpler process, during which the interpreter is only contacted when considered necessary.

Apache servers’ traditional file-based methods mean they’re capable of handling static content, and their performance is primarily a function of those MPM methods covered earlier.

But Apache is designed to process dynamic content too, by integrating a processor of suitable languages into every worker instance. As a result, Apache can accommodate dynamic content in the server itself, with no need to depend on any external components. These can be activated courtesy of the dynamically-loadable modules.

Apache’s internal handling of dynamic content allows it to be configured more easily, and there’s no need to coordinate communication with other software. Modules may be swapped out if and when requirements for content shift.

NGINX or Apache – How Does Directory-level Configuration Work?

Another of the most prominent differences administrators discuss when discussing Apache vs NGINX relates to directory-level configuration, and whether it’s allowed in their content directories. Let’s explore what this means, starting with Apache.

With Apache, additional configuration is permitted on a per-directory level, through the inspection of files hidden within content directories — and the interpretation of their directives. They’re referred to as .htaccess.

As .htaccess files are located inside content directories, Apache checks every component on the route to files requested, applying those directives inside. Essentially, this allows the web server to be configured in a decentralized manner, typically utilized for the implementation of rewritten URLs, accessing restrictions, authentication and authorization, as well as caching policies.

Though these offer configuration in Apache’s primary configuration file, there are some key advantages to .htaccess files. First and foremost, they’re implemented instantly without needing to reload the server, as they’re interpreted whenever they’re located on a request path.

Secondly, .htaccess files enable non-privileged users to take control of specific elements of their web content without granting them complete control over the full configuration file.

This creates a simple way for certain software, such as content management systems, to configure environments without giving entry to central configuration files. It’s used by shared hosting providers for maintaining control of primary configurations, even while they offer clients their own directory control.

With NGINX, interpretation of .htaccess files is out of the question.It also lacks a way to assess per-directory configuration beyond the primary configuration file. As a result, it could be said to offer less flexibility than Apache, though it has a number of benefits too.

Specifically, improved performance is one of the main advantages compared to the .htaccess directory-level configuration system. In the case of standard Apache setups that accommodate .htaccess in any one directory, the server assesses the files in every parent directory leading to the file requested, whenever a request is made. Any .htaccess files found throughout this search will be read before being interpreted.

So, NGINX can serve requests in less time, due to its single-directory searches and file-reads for every request. Of course, this is based on files being located in a directory with a conventional structure.

Another benefit NGINX offers with directory-level configuration relates to security. Distributing access also leads to a distribution of security responsibility to single users, and they might not all be trustworthy. When administrators retain control of the whole server, there’s less risk of security-related problems which grant access to people who can’t be relied upon.

How does File and URI-based Interpretation Work with NGINX and Apache?

When discussing Nginx vs Apache, it’s important to remember the way in which the web server interprets requests, and maps them to system resources, is another vital issue.

When NGINX was built, it was designed to function as a web and proxy server. The architecture demanded to fulfil both roles means NGINX works with URIs mainly, and translates to the filesystem as required. This is evident in a number of ways in which its configuration files function.

NGINX has no means of determining filesystem directory configuration. As a result, it’s designed to parse the URI. NGINX’s main configuration blocks are location and server blocks: the former matches parts of the URI which come after the host and port, while the latter interprets hosts requested. Requests are interpreted as a URI, rather than one of the filesystem’s locations.

In the case of static files, requests are eventually mapped to a filesystem location. NGINX chooses the location and server blocks for handling the specific request, before combining the document root with the URI. It also adapts whatever’s required, based on the configuration specified.

With NGINX designed to parse requests as URIs rather than filesystem positions, it makes for simpler functionality in various areas. Specifically, in the following server roles: web, proxy, and mail. This means NGINX is easily configured by laying out appropriate responses to varied request patterns, and NGINX only checks filesystems when it’s prepared to serve the request. This is why it doesn’t implement .htaccess files.

Interpret requests as physical resources on a filesystem. It may also interpret requests as a URI location, which demands an assessment that’s a little less specific. Generally, Apache utilizes <Directory> or <Files> blocks for these purposes, and <Location> blocks for resources that are more abstract.

As Apache was conceived as a server for the web, its standard function is interpreting requests as traditional filesystem resources. This process starts with the document root and changing the part of the request which comes after host and port numbers, as it attempts to locate an actual file. So, on the web, filesystem’s hierarchy appears in the form of the available document tree.

Apache gives various alternatives for when requests fail to match underlying filesystems. E.g., Alias directives may be utilized for mapping alternative placements. Leveraging <Location> blocks is a way to work with the URI rather than the filesystem. A number of expression variants may be utilized to apply configuration throughout filesystems with greater flexibility.

As Apache is capable of functioning on the webspace and underlying filesystems, it has a heavier focus on filesystem methods. This is evident in a number of the design choices, such as the presence of .htaccess files in per-directory configuration. Apache documentation advises not to utilize URI-based blocks for inhibiting access when requests match those underlying filesystems.

NGINX vs Apache: How Do Modules Work?

When considering Apache vs NGINX, bear in mind that they can be extended with module systems, though they work in significantly different ways.

NGINX modules have to be chosen and compiled into its core software, as they cannot be dynamically loaded. Some NGINX users it’s less flexible as a result. This may be particularly true for those who feel unhappy managing their compiled software that’s positioned external to the distribution’s conventional packaging system.

Even though packages typically include modules which are used commonly, you would need to create the server from source if you need a non-standard module. Still, NGINX is incredibly useful, allowing users to dictate what they want out of their server by including only the functionality you plan to utilize.

For many people, NGINX seems to offer greater security as a result of this. Arbitrary components are unable to connect to the server. But if the server is in a scenario where this appears to be likely, it may have been affected already.

Furthermore, NGINX modules offer rate limiting, geolocation, proxying support, rewriting, encryption, mail functionality, compression, and more.

With Apache, the module system provides users with the option to load or unload modules dynamically based on your individual needs. Modules may be switched on and off even though the Apache core remains present at all times, so you can add or take extra functionality away and hook into the main server.

With Apache, this functionality is utilized for a wide range of tasks, and as this platform is so mature, users can choose from a large assortment of modules. Each of these may adjust the server’s core functionality in various ways, e.g. mod_php embeds a PHP interpreter into all of the running workers.

However, modules aren’t restricted to processing dynamic content: some of their functions include authenticating clients, URL rewriting, caching, proxying, encrypting, compression, and more. With dynamic modules, users can expand core functionality significantly — with no need for extensive extra work

NGINX or Apache: How do Support, Documentation, and Other Key Elements Work?

When trying to decide between Apache or Nginx, another important factor to bear in mind is actually getting set-up and the level of support with other software.

The level of support for NGINX is growing, as a greater number of users continue to implement it. However, it still has some way to go to catch up with Apache in certain areas.

Once upon a time, it was hard to gather detailed documentation for NGINX (in English), as the majority of its early documentation was in Russian. However, documentation has expanded since interest in NGINX has grown, so there’s a wealth of administration resources on the official NGINX website and third parties.

On the topic of third-party applications, documentation and support is easier to find. Package maintainers are starting to offer choices between NGINX and Apache auto-configuring. It’s easy to configure NGINX to complement alternative software without any support, as long as the specific project documents clear requirements (such as headers, permissions, etc.).

Support for Apache is fairly easy to find, as it’s been such a popular server for such a long time. An extensive library of first- and third-party documentation is on offer out there, for the core server and task-based situations that require Apache to be hooked up with additional software.

As well as documentation, numerous online projects and tools involve tools to be bootstrapped within an Apache setting. This could be present in the projects or the packages managed by the team responsible for the distribution’s packaging.

Apache receives decent support from external projects mainly due to the market share and the sheer number of years it’s been operating. There may be a higher likelihood of administrators having experience of using Apache, not just because it’s so prevalent but as a lot of them begin in shared-hosting scenarios which rely on Apache, due to the .htaccess distributed management capabilities.

NGINX vs Apache: Working with Both

Now that we’ve explored the advantages and disadvantages of NGINX and Apache, you could be in a better position to understand whether Apache or NGINX is best for you. But a lot of users discover they can leverage both server’s benefits by utilizing them together.

Traditional configuration for using NGINX and Apache in unison is to position NGINX ahead of Apache. This way, it serves as a reverse proxy — enabling it to accommodate every client request. Why is this important? Because it takes advantage of the quick processing speeds and NGINX’s capabilities to handle a lot of connections at the same time.

In the case of static content, NGINX is a fantastic server, as files are served to the client directly and quickly. With dynamic content, NGINX proxies requests to Apache to be processed. Apache will then bring rendered pages back. After this, NGINX is able to send content back to clients.

Plenty of people find this is the ideal setup, as it enables NGINX to perform as a sorting machine, handling all requests and passing on those which have no native capability to serve. If you reduce Apache’s level of requests, it’s possible to reduce the level of blocking which follows when Apache threads or processes are occupied.

With this configuration, users can scale out through the addition of extra backend servers as required. NGINX may be configured to pass to a number of servers with ease, boosting the configuration’s performance and its resistance to failure.

Apache vs NGINX – Final Thoughts

It’s fair to say that NGINX and Apache offer quality performance — they’re flexible, they’re capable, and they’re powerful. Choosing which server works best for your needs depends largely on assessing your individual requirements and testing with those patterns you believe you’re likely to see.

A number of differences between these projects have a tangible effect on capabilities, performance, and the time required to implement each solution effectively. But these tend to be the result of numerous trade-offs that shouldn’t be dismissed easily. When all is said and done, there’s no web server that meets everyone’s needs every single time, so it’s best to utilize the solution that suits your objectives best.

Enable NGINX-only Hosting for Your Domain

NGINX Hosting for Your Domain

NGINX is an HTTP and reverse proxy server that many small and medium-sized websites love using. Mostly because of its sleek design and high performance fine-tuning for difficult conditions. It’s no surprise that lots of users are switching from Apache to NGINX – the former pre-installed on most Linux servers. Apache has been around for over two decades and has established itself as a popular web server worldwide. So why should you switch and set up NGINX-only hosting?

NGINX may be a better option for your high-traffic sites, making it a more robust and reliable service. Unsurprisingly, Apache performs relatively poorly under similar high pressure situations. Thus, resulting in a more sluggish performance under heavier loads. Therefore, more users want to know how to set up NGINX-only hosting in order to avoid such performance constraints. Thankfully, we have a very useful technical guide of how to achieve this switch.

Get Started and Set up NGINX-only Hosting

NGINX Hosting

Plesk for Linux users can choose from a variety of ways to host websites. Such as using a combination of NGINX and PHP-FPM. However, NGINX-Only hosting is a great alternative for websites that run on PHP. As well as for the hosting of static websites and application servers.

You can configure individual websites so that they’re only served by NGINX, without stopping or disabling Apache. By doing this, you make sure there’s no impact on the websites that are already hosted by Apache. If users employ other Plesk services such as Webmail, these will not be affected by the NGINX hosting switch. The former will just continue working using Apache.

NGINX-only Hosting: Limitations & Configurations

NGINX Hosting Limitations

There are a number of limitations you should consider when setting up NGINX-only hosting. Firstly, File Sharing becomes unavailable when you make this change. Secondly, SSI, Perl, and Python support services also stop being available. Lastly, know you can only use the “FPM application server by NGINX” PHP handler once they select NGINX-only hosting. Think about these limitations before proceeding with changing your server configurations.

In terms of configuration, with Linux servers, the default setting is that NGINX and Apache work simultaneously. Apache servers the dynamic content, while NGINX is popular for a proxy serving static content. We set this up to optimize the usage of server resources so that we can serve requests to hosted websites more efficiently. However, Plesk also allows users to choose the way in which static content is handled for their websites.

Serving content and files

nginx hosting - serving content and files

There are different ways of serving content and files when using NGINX hosting. Users can serve all static content via NGINX – the default way which Plesk for Linux works. Each time a request for static content comes in, Apache only indicates the corresponding file’s location. Then, NGINX finds it and serves it.

Users can also serve files with specific extensions via NGINX. Meanwhile, Apache is the one which servers other files generally classified as static content. It’s important to note that when using this specific scenario, requests for files with specified extensions never reach Apache. Therefore, they don’t pass through Apache handlers. So, be aware that rewrite rules or htaccess directives do not apply.

Another option is serving all static and dynamic content via Apache by disabling NGINX. This method can be useful in specific cases, such as when there is NGINX troubleshooting. However, we do not recommend this if you’re managing production websites.

You can easily use NGINX as a reverse proxy, and Apache still does a great job of handling dynamic content. As you can see from the various configurations in this article, you can use both servers at the same time. In fact, it’s more common to have Apache in the back-end, with NGINX as the proxy server on the front-end, managing requests.

Check our docs for more info on Apache and NGINX settings on Plesk Obsidian.

How to switch on NGINX hosting for your domain

  1. In Plesk, go to Domains > example.com > Apache & nginx Settings.
  2. In the nginx settings section, disable the Proxy mode setting.
How to switch on NGINX-only hosting for your domain

3. Apply the changes.

Enable NGINX-only hosting for all new domains under a service plan

  1. In Plesk, go to Service Plans > Example Plan > Web Server tab.
  2. In the nginx settings section, disable the Proxy mode setting.
  3. Click Update & Sync.

What is LAMP? LAMP stack basics to get you up and running fast

LAMP stacks

The LAMP stack has nothing to do with lighting, but it’s still a pretty bright idea (sorry, couldn’t resist!) It underpins many of the world’s most widespread open source web apps, like WordPress and Drupal, but its history goes back further than just being the bedrock of those currently popular platforms though. It’s one of the web’s original open source software stacks, and many developers still turn to it today when they are working on new custom web apps. As a developer you’ll find yourself running into it a lot too because it’s everywhere, and you’ll appreciate the fact that its uncomplicated and robust.

What is LAMP?

Glad you asked. LAMP stands for Linux, Apache, MySQL and PHP, and each one of them adds something unique to the development of high-performance web applications.

  • Linux: the LAMP Stack’s operating system. Linux started life in 1991. It’s an open source operating system and its free. It’s endured partly because it’s flexible and other operating systems are harder to configure. It’s used around the world and has proved itself in lots of different industries. So, it has a loyal fan base willing to shout its praises and help new users get up to speed.
  • Apache: the LAMP Stack’s web server. Apache HTTP Server is a free web server software package made available under an open source license. It used to be known as Apache Web Server when it was created in 1995. It offers a secure and extendable Web server that’s in sync with current HTTP standards.
  • MySQL: the LAMP Stack’s dbms. MySQL is a relational database management system used to store application data. It’s open source, and it lets you keep all your data in a format that can easily be queried with the SQL language. SQL works great with well-structured business domains and it’s a great workhorse that can handle even the largest and most complicated websites with ease.
  • PHP: the LAMP Stack’s programming language. PHP is an open source scripting language. It fits hand in glove with Apache to make building dynamic web pages a breeze. For instance, it steps into do what HTML can’t: enabling dynamic processes that involve pulling elements out of a database. PHP makes it easy to do tasks like this. You can add your code to the page at the part that you want to be dynamic, and hey presto! Job done. It’s an efficient and flexible language, and you can see the results of your new code as soon as you’ve written it. Just add it, hit refresh and it’s there. But if you’d prefer to use Perl or Python instead then you can, no problem. (Isn’t it handy that they both begin with the P?)

What is LAMP architecture like?

LAMP architecture is layered in the classic style, with Linux at the bottom, followed by Apache, MySQL, then PHP. Although PHP sits on the highest layer, it’s actually inside Apache.

How do the elements work together?

It all begins when someone’s browser sends a request for a web page to the Apache web server. If it’s for a PHP file, the request is forwarded to PHP, which loads the file and runs its code, then asks MySQL to fetch any information that the code may have referenced.

The code and the data it pulls up are used to create the output that lets browsers display webpages. The LAMP stack is good at delivering both static and dynamic pages, which is good because this is slightly more difficult to achieve because as the name suggests, dynamic content can change every time the page is loaded.

Once the file code has been run, PHP sends the data it produces back to the Apache web server, which then shunts it on to the browser, and this new data can also be stored in MySQL.

We haven’t mentioned Linux, but it’s the base on which all of this rests.

Flexibility

As the name suggests, the LAMP stack is based on Linux, but you could also use Windows if you needed to, which would give it the equally attractive title of a WAMP stack. You can swap in Mac OS to get a MAMP stack, or there’s even WIMP, which uses Windows and the Internet Information Services web server from Microsoft.

But the beauty of the LAMP stack is that all its components are free and open source, so you’re not tied in to use or pay for any of them. You just use what you need, when you need it.

The LAMP stack is flexible in other ways too. Apache has a modular design, so it’s possible to add on custom modules to extend functionality.

It’s also worth mentioning that the LAMP stack features enterprise-level encryption and security, so it’s “as safe as houses,” as they say.

Improving Efficiency – LAMP vs LEMP

The LAMP stack is a veteran that has been around for more than 10 years now, which means there are plenty of users who’ve been building modules for it for ages. The advantage of this is that whatever you might need to build for your own project, a lot of the work will have been done already. It’s great knowing that whatever you need, the work of others is waiting to help you cut down on your development time.

Another way to gain efficiency is by replacing Apache with NGINX, which is an is  an open-source high-performance web server is a web server which can also be used as a reverse proxy, mail proxy, load balancing solution and HTTP cache. NGINX focuses strongly on high concurrency, high performance and low memory use. Nowadays NGINX powers variety of high-load sites including Pinterest, Cloudflare, Airbnb, Netflix, Hulu, WordPress.com and GitHub.

How to Secure Nginx Against Malicious Bots

Nginx Security

Protective measures for a server are very important and there are several ways to protect your websites and apps from malicious bots. We’ll be looking at different bots and how they operate, and how you can use Plesk’s security measures to secure Nginx against malicious bots.

Malicious Bot Types

Nginx vs malicious bots

There are Bots that scan API keys on Git (Scanbots) and bots that download web pages. But even worse, you’ll find hackers using bots as a group of hijacked computers to take down websites (botnets). Or even send out innumerable spam emails (Spambots). Let’s take a deeper look at the latter two.  

Bots For Spamming Emails     

Spambots are special programs that crawl the internet for email addresses posted in forums, discussions boards, comments and websites. Spam generally means unwanted and unwarranted emails. They usually look for ‘mailto’ expressions (HTML used to display email IDs online), with a format such as the one below.

<ahref=“mailto:[email protected][email protected], [email protected],[email protected]&subject=Web%20News“>Email Us

Apart from mailto, others have resorted to using words, just to make it difficult for Spambots to crawl email addresses. For instance, instead of  ‘‘[email protected]’’, others prefer to use this format rather: support[at]abz[dot].com on the web. However, spam programs identify these different formats and affect users. Costing time, money and productivity.

Bots For Hijacking Computers

Malicious botnets are a network of infected computers with malicious software controlled as a group by hackers to perform distributed denial of service attacks (DDOS). Botnet makes a way for malware to enter networks and control them.

Let’s look at how attackers use botnet hijack computers by studying a click-fraud botnet which made a profit for its creators through Google search program.

Paco Redirector is a botnet trojan which affected search engines, such as Google and Bing. Here’s how.

  1. First, it infects users’ computers when they download and install fake versions of popular software
  2. Afterward, Paco changes browser’s local registry keys to include two entries to ensure malware starts at boot time.
  3. Finally, the malware implements a proxy configuration file that captures traffic and routes it through attackers command and controlled server.

How to Secure Nginx Server against malicious Bots

Due to the fact that most websites run on an Nginx server, we need to know how to secure Nginx against malicious bots. We can protect the resources running on Nginx servers by using Plesk extensions and Fail2ban.

1. Using SpamExperts Email Security Extension

Using SpamExperts Email Security Extension

SpamExperts specifically protects a hosting environment from threats like spam and viruses. It comes with an incoming filter, which separates valid emails from unsolicited ones. And also an outgoing filter, which prevents your IP address from being blacklisted since spam can be sent from your compromised account within your web infrastructure.

2. Using DDOS Deflate Interface Extension

Using DDOS Deflate Interface Extension

Hackers often use malicious bots to automatically brute-force authentication. So, you can use DDOS Deflate Interface to mitigate DDOS attacks by blocking IP addresses which exceed the configured threshold.

3. Using Fail2ban to Block Internet Bots

Fail2ban is a prevention software that protects servers like Nginx from bot attacks. You can install Fail2ban software by using the following command:

apt-get install fail2ban

Ubuntu users can make use of this command to install Fail2ban whilst Fedora and CentOS users can use the command below:

yum install fail2ban

Afterwards use the following command to create a second copy of Fail2ban local configuration file:

cp /etc/fail2ban/jail.conf /etc/fail2ban/local.conf    

Below is a screenshot of the Fail2ban jail configuration file:                   

Fail2ban jail configuration file screenshot - How to Secure Nginx Against Malicious Bots - Plesk

Search for the maxretry parameter and set it to 5. Maxretry is the parameter used to set the limit for the number of retry by a host. If the host exceeds this limit, the host is banned.

Maxretry parameter

Apart from the maxretry parameter in the configuration file, there are other parameters such as Ingoreip which is used to set the list of IP addresses which will not be banned.
Then execute the following commands to run Fail2ban package on the server:

 sudo systemctl enable fail2ban    

 sudo systemctl start fail2ban

Now let ‘s go ahead to configure Fail2ban to monitor nginx server logs.

Because these hackers use bots to perform brute-force, we can create a specific jail for login attempt by adding the following content to the jail.conf file under [nginx-http-auth]

enable = true
filter = nginx-auth
action = iptables-multiport[name=NoAuthFailures,port="http,https"]
logpath = /var/log/nginx*/*error*.log
bantime = 600
maxretry = 6[nginx-login]
enabled = true
filter = nginx-login
action = iptables-multiport[name=NoLoginFailures, port="http,https"]
logpath = /var/log/nginx*/*access*.log
bantime = 600
maxretry = 6

Finally you can create filter for the [nginx-http-auth] by navigating to the following path:

cd /etc/fail2ban/filter.d

The screenshot below shows all files inside the filter.d directory

Files inside the filter.d directory

Open the file nginx-http-auth.conf and add the following content below failregex specification.

^ \[error\] \d+#\d+: \*\d+ no user/password was provided for | authentication, client: <HOST>, server: \S+, request: "\S+ \S+ HTTP/\d+\.\d+", host: "\S+"\s*$

Save and close the nginx-auth.conf.  You can now activate your nginx jail by using the following command:

 sudo service fail2ban restart

These solutions may not be the only ways to stop bots from attacking your Nginx server.  However, you can rely on these methods to avoid the negative effects of malicious bots. Get in touch with one of our Plesk experts if you need further assistance regarding a bot attack.

How useful and straightforward was this guide? Any issues? Let us know in the comments below.

arrow icon - Plesk

My Plesk User Experience (2): Lessons learned from testing Plesk Onyx

My Plesk user experience 2 - Plesk Onyx testing and analysis

So Plesk Onyx came along and it had implemented NGINX caching. Naturally I was curious and removed all my customizations. Then I started to compare the website performance with the inbuilt NGINX caching, other caching methods, and the Speed Kit extension that speeds up websites.

This was the variety of tests and configurations I made on the platform:

Platform Web Server Configuration Caching Engine Configuration
1 WordPress Website on Plesk Onyx 17.8.11 Proxy Mode and Smart static files processing turned ON NGINX Caching OFF
2 WordPress Website on Plesk Onyx 17.8.11 Proxy Mode and Smart static files processing turned ON NGINX Caching ON
3 WordPress Website on Plesk Onyx 17.8.11 Proxy Mode and Smart static files processing turned ON NGINX Caching OFF Redis Caching ON
4 WordPress Website on Plesk Onyx 17.8.11 Proxy Mode and Smart static files processing turned ON NGINX Caching ON Redis Caching ON
5 WordPress Website on Plesk Onyx 17.8.11 Proxy Mode and Smart static files processing turned ON NGINX Caching OFF SpeedKit Ext. ON
6 WordPress Website on WordPress.com Everything in default mode —
7 WordPress Website on Vesta CP NGINX Web Template turned ON with the WordPress2 Option selected —

I installed the Plesk server (version 17.8.11 update 25) on the Digital Ocean droplet on CentOS7 with 2 GB RAM. Next, installing the Redis server as it was. I plugged in Redis Object Cache with its default settings. And had no additional parameters in additional NGINX directives.

There was PHP version 7.2.10 with default settings and the “FPM application served by NGINX mode. And the VestaCP server installed on Digital Ocean droplet on Ubuntu 16.04.

As a test page, I used a typical blog post with lots of photos. Hosted both on the server and externally, with a small chunk of text and one comment.

Testing on the Plesk Onyx Platform

Testing on Plesk Onyx platform

For testing, I used the httperf command line tool (with the same launch parameters) and a well-known online testing system GTmetrix.com. From the GTmetrix.com reports, I chose the following parameters:

Time to First Byte (TTFB) is the total amount of time spent to receive the first byte of the response once it has been requested. It is the sum of “Redirect duration” + “Connection duration” + “Backend duration“. This metric is one of the key indicators of web performance.

Once the connection is complete and the request is made, the server needs to generate a response for the page. The time it takes to generate the response is known as the Backend duration.

    • Fully Loaded Time: RUM Speed Index is a page load performance metric indicating how fast the page fully appears. The lower the score, the better.
    • PageSpeed Score
    • YSlow Score

The httperf utility was launched with the following parameters:

httperf –hog –server jam.pavuk.su –uri=/index.php/2018/10/03/kgd/ –port=443 –wsess=100000,5,2 — rate 1000 –timeout 5

The creation of 100,000 sessions (5 calls each 2 seconds) with speed 1,000. And here, the following markers received with httperf were the most interesting:

  • Connection rate – the real speed of creating new connections. It showed the server ability to process connections.
  • Request rate – the speed of processing requests, in other words a number of requests a server can execute per second. It showed web app responsiveness.
  • Reply rate – an average number of server replies per second.

Plesk Onyx Test Results

Plesk test results

Clearly, there’s an ocean of tools and solutions to test website performance. Some more complete and respected than others. But even the tools I used allowed me to come to pretty objective conclusions. The test results are summarized in the table below with the green buts highlighting the best values of the parameter, and the red – the worst.

Plesk Onyx test results table

And so, after analyzing the received data, we can conclude the following:

  1. Unchanged PageSpeed and YSlow Scores
    PageSpeed and YSlow Score metrics in Plesk remain absolutely the same, no matter the configuration. Therefore, they don’t depend on caching or other server settings like for code optimization, image size, gzip compression and CDN usage.
  2. Caching is essential for speed
    No caching on Plesk at all gives the worst time metrics. Fully Loaded Time and TTFB dramatically increase. Websites with the turned off caching are significantly slower.
  3. NGINX and Redis are a successful combo
    Comparing caching methods, NGINX caching used in Plesk seems better than Redis Cache. It’s possible the default Redis Cache configuration doesn’t let us achieve a higher performance. It’s not quite clear how the used combination of both caching tools works, but it gives quite alright TTFB и Backend duration metrics.
  4. WordPress performance suffers
    WordPress.com shows the worst performance results. However, by default, it doesn’t actually offer bad optimization for the PageSpeed Score.
  5. Vesta and NGINX mean extremely fast page load
    Using the lightweight Vesta control panel with the turned on NGINX Web Template + php-fpm (wordpress2) designed for WordPress hosting gives great speed results. Even more, for WordPress hosting, VestaCP has custom NGINX web templates including NGINX caching support.

Moving to a new DigitalOcean Droplet

Plesk on Digital Ocean droplet - install - now a one-click app

I deployed Plesk to the new DigitalOcean droplet using Web Installer as it doesn’t require me to go to the server via SSH and do all the stuff in web interface. This recent migration from my VPS to a new DigitalOcean droplet gave me new data for my last Plesk experience. All in all, the migration was successful with minor warnings, which in most cases I resolved using migration wizard suggestions.. The bottom line is that Plesk with turned on key features and settings gives very good results for your website.

Also, I strongly recommend you turn on NGINX caching with your Plesk if you’re seeking a simple and reliable way to speed up your website. You won’t need to set up any difficult configurations. And web pros can make the most of Plesk by fine-tuning as they see fit. That’s what it’s made for. their right.

Finally, my story was aimed at people without professional knowledge who simply want to use built-in Plesk features. So I hope that this story will be good reason for you to login to Plesk and take a fresh look.

My Plesk User Experience (1): Easy Starts and Common Issues

Plesk User Experience While Testing Plesk Onyx

Plesk first crossed my path when it came packaged with web hosting acquired from a Russian provider. At the time it was version 12.0, but I never paid any attention to it until I discovered that part of its service was domain names registration.

Starting Off with Plesk

It couldn’t hurt to register a couple of domains for myself, and so I did. I added them to Plesk, and configured the DNS records. Now these websites loaded default web pages. Then, as I already had websites hosted in Plesk, I thought “Why not use mailboxes registered on my own domains?”. So I went and created a couple of mailboxes and configured Roundcube webmail.

But it was all just personal use until I occasionally started to use this complete infrastructure as a sort of a test server. Why? In order to solve tasks related with questions from forum users. And so, my Plesk server operated like this for a while without any use cases development. That is, until the start of 2017 – when I spontaneously took a closer look at something I had available, but which was laying there unused this whole time.

Easy Building on the Plesk Platform

Building on Plesk Platform

I realized that I could now use my own platform for my personal blog. It didn’t take me long to choose WordPress as I had previous experience with it. What’s more, the new Plesk Onyx had integrated its WordPress Toolkit, which looked promising. After getting a license with additional extensions, I started building – themes, plugins, you name it, before publishing my first posts.

Plesk is also built for multiple domains. So when my famous, American Instagrammer friend needed a website to develop her “Travelling with kids” idea, I offered my hosting platform.

Within Plesk, I created a personal account for her and subscriptions with two domains. One was used to host her website, and the other to host her personal mail.

She quickly learned how to use the WordPress admin dashboard and Plesk. She created mailboxes and installed WordPress plugins and themes. Then created posts and moderated comments. Which I believe says a lot about how easy Plesk’s interface is.

As thousands of subscribers were actively visiting both our blogs, it was time to pay more attention to Plesk server maintenance. And later, to server optimization, creating regular work in the Plesk interface and even more in the Linux command line. But more on that later. Before that, there were common issues of all sorts that I had started to face.

Issues uncovered and solved by using Plesk

Issues solved by using Plesk
  • Service downtime
    Various services like httpd and MySQL stopped every now and then. I managed to solve this by turning on and configuring Watchdog.
  • Memory usage
    Then Health Monitor started to constantly notify that MySQL consumes RAM.
  • Basic MySQL settings
    I had optimized operation modes of MySQL via CLI and thought it would benefit to have at least some basic settings of MySQL optimization in the Plesk interface. Eventually, RAM for VPS was increased from 1 to 2 GB, solving the issue.
  • Frequent updates
    Email notifications about new WordPress plugins made me login to Plesk often. I am one of “update-it-all” types and very meticulous when it comes to installing the latest software versions. The Smart Updates feature in WordPress Toolkit solved this task.
  • Extensions accessibility
    I used to find accessing my installed extensions inconvenient. So it was great when WordPress Toolkit had installed extension icons in the left menu.

Speeding up and hardening the WordPress Website

Speed Up WordPress Website

During an internal contest for the best WordPress website hosted in Plesk, I focused on two goals. I wanted to make my WordPress website the fastest and the most secured.

To achieve the A+ note on ssllabs.com, special NGINX parameters became necessary. They were installed via Additional nginx directives and the /etc/nginx/conf.d /ssl.conf file. An attempt to maximize the speed of my website powered by NGINX was a special matter.

At that time, NGINX caching wasn’t yet implemented in Plesk. So I tried various caching solutions, such as redis, memcached, and the very same NGINX caching. All via the CLI, of course, but with the help of customized settings.

It didn’t take long to realize the NGINX version shipped with Plesk was not suitable to use with trendy acceleration technologies. Ones like caching, the brotli compression method, PageSpeed Module, or TLS1.3. Even the Plesk Forum also raised this issue as it seemed to occupy the minds of advanced users.

The result was publishing different ways how to compile the latest NGINX versions. Thus, supporting modern technologies, and substituting the NGINX version shipped with Plesk for a custom one. I also joined forum users in compiling and optimizing NGINX builds for my Plesk server, all during the contest.

In the end, I got the speedy WordPress site I wanted powered by customized NGINX with Redis caching. All was well until Plesk Onyx was released. See what happened next in part 2 of my Plesk experience story tomorrow.

What can go wrong without the best web hosting platform? [Infographic]

Without the right host for your website, a lot can go wrong for your business. Read on to learn more about the importance of choosing the right web hosting platform.

How important is choosing the right web host

Web Hosting Platform - infographic by Plesk

Choosing the right web hosting platform is as important as your site content. And the wrong web hosting platform can seriously impact your business. Your web host must protect your site from security breaches, and backup all your data in case of hacking.

Slow websites or ones that go down for even a few minutes will negatively impact your SEO ranking. (In this event, see how to turbocharge your website speed to get back on track.)

So how important is choosing the right web host? Let’s look at the facts.

One-second page load delay leads to 7% conversion drop

Load delay and conversion drop

Page loading time is one of the most important factors that contribute to your website’s success. Also, it affects whether visitors will return to your website and perform profitable or desired actions. According to Aberdeen Group, a 1-second loading delay can result in a 7% decrease in e-commerce conversions and can drop customer satisfaction by 16%.

Sites on Google’s page 1 load in under 2,000 ms

Sites on Google’s page 1 load in under 2,000 ms - Plesk

Websites that appear on Google’s first page of search results load in under 2,000 milliseconds and loading delays can result in a loss of 44.19% in page views for a 20 second loading delay. A slow-loading website isn’t likely to appear in the first page of Google’s results.

Need a mighty page speed boost? Check out Google Pagespeed Insights.

Almost half of websites are hosted on Apache servers

Apache servers - a majority

From all the billions of websites that exist on the internet, Apache servers are the most widely used with 46.9% of existing websites. NGINX is the second most popular with 37.8% of websites hosted on it. So, make sure your hosting platform supports this.

Stats for SMBs and large companies using private cloud

Stats for SMEs and large companies using private cloud - Plesk

Private cloud computing generally feels safer than public cloud computing because access to the resources in a cloud infrastructure is limited. However, many SMEs – about 8%, and even 24% of larger companies do not buy cloud infrastructure altogether. This is mainly because of lack of knowledge about cloud computing. Pick a web host with plenty of opportunities to scale to the cloud.

A whopping 86% of websites have serious security flaws

Whopping 86% of websites have serious security flaws - Plesk

Over 30,000 websites are hacked daily with 86% of websites having at least one serious security flaw, including these top brands.

Over half of WordPress sites run on an outdated CMS version

Over half of WordPress sites have outdated CMS version

One of the reasons why so many websites are hacked is because many of them run on an outdated CMS version. In fact, 56% of hacked WordPress sites, 84% of hacked Joomla sites, 96% of Magento sites and 81% of hacked Drupal were all hacked for the same reason.

Why Choose Plesk web hosting platform?

When it comes to choosing a web hosting platform, look for reliability and security more than anything. Want to offer users the ability to scale and grow your website quickly without compromising on quality? Then, a web hosting platform like Plesk is one of the best options to grow an enterprise website and maximize its potential.

Try Plesk for Free Today