Magento 2 Types of Profiling (for optimization of site)

Benchmarking and performance analysis is a very common task when developing a web site, especially if the website is ment to sell services or products. A fast website will add a powerful value to customer experience in general; increasing also the chances of building loyalty and trust.

Magento provides two tools for helping with benchmarking a particular site: MAGE_PROFILER for code and database profiler.

MAGE_PROFILER

This profiling will display the processes and class resources involved with the specific url path being analyzed; listed as a dependency list at the bottom of the screen.

This profiling will allow developers to determine what classes or functions are taking too much time to execute, helping in filtering out the sections or coding that requires some improvement.

For enabling MAGE_PROFILER using type html it is required to execute the following commands:    

bin/magento dev:profiler:enable html

bin/magento cache:flush

For disabling MAGE_PROFILER:

bin/magento dev:profiler:disable

 

Database profiler

The database profiler is similar to the MAGE_PROFILER but is focused on database queries performance. 

For enabling this profiling the following steps are required:

Step 1: Add a reference class to env.php

On  <magento_root>/app/etc/env.php to add the following class reference:

‘db’ =>

  …

      ‘default’ =>

      array (

        ‘host’ => ‘localhost’,

        ‘dbname’ => ‘magento’,

        ‘…

        ‘active’ => ‘1’,

        ‘profiler’ => [

            ‘class’ => ‘\Magento\Framework\DB\Profiler’,

            ‘enabled’ => true,

        ],

      ),

    ),

  ),

Step 2 Modify the index.php file

On <magento_root>/index.php add the following after the $bootstrap->run($app); line in your bootstrap file:

/** @var \Magento\Framework\App\ResourceConnection $res */

$res = \Magento\Framework\App\ObjectManager::getInstance()->get(‘Magento\Framework\App\ResourceConnection’);

/** @var Magento\Framework\DB\Profiler $profiler */

$profiler = $res->getConnection(‘read’)->getProfiler();

echo “<table cellpadding=’0′ cellspacing=’0′ border=’1′>”;

echo “<tr>”;

echo “<th>Time <br/>[Total Time: “.$profiler->getTotalElapsedSecs().” secs]</th>”;

echo “<th>SQL [Total: “.$profiler->getTotalNumQueries().” queries]</th>”;

echo “<th>Query Params</th>”;

echo “</tr>”;

foreach ($profiler->getQueryProfiles() as $query) {

    /** @var Zend_Db_Profiler_Query $query*/

    echo ‘<tr>’;

    echo ‘<td>’, number_format(1000 * $query->getElapsedSecs(), 2), ‘ms’, ‘</td>’;

    echo ‘<td>’, $query->getQuery(), ‘</td>’;

    echo ‘<td>’, json_encode($query->getQueryParams()), ‘</td>’;

    echo ‘</tr>’;

}

echo “</table>”;

Step 3: Clean cache

bin/magento cache:flush

Finally, removing the database profiler is just as simple as rolling back the changes above.

There is no need to say that these profiling tools are beneficial for developers that want to understand a little more better the general user experience and to fix any hidden performance issue that is only noticeable  at code or system level.

Magento API’s – SOAP, REST, and GraphQ – A Brief Explanation

The main purpose of Magento is to allow merchants and clients to perform purchasing-related operations, but Magento also provides mechanisms for allowing external applications to communicate with it. 

SOAP

This protocol is the least popular among all the protocols provided by Magento due to its complex learning curve. It is also the least flexible, because it only works with XML; not ideal for speed performance because the payload sizes tend to be big. 

However, the lack of flexibility ensures great security and tends to enforce a clear business flow when interacting with the API.

When to use it?

  • The project requires a very strict request logic.
  • Performance speed is not critical.
  • There is plenty of time for studying the protocol.
  • No need to scale in the future.

REST

At the moment of writing this article this is the most popular API protocol; so it is the most documented API, converting it into the entry point of many new developers into API development. 

Its messaging format is very flexible, allowing many formats such as JSON, XML, objects, Simple Text, etc.

Since it is the most popular API protocol, it is cache friendly in almost all web browsers and HTTP protocols; however, storing huge amounts of unnecessary data is the biggest flaw.

When to use it?

  • The project requires a simple API protocol that follows standard conventions.
  • Performance speed is not critical.
  • Very little time left in the project.
  • More suitable for complex database querying.
  • Scalability is required in the future.

Graph QL

The newest of the API provided by Magento, improves speed performance by only returning the info required; however, the learning curve is very steep; also, not suitable for complex querying, because it will reduce its original performance speed for handling nested queries.

When to use it?

  • Performance speed is critical.
  • No need for performing nested queries.
  • Need to update the project with the newest GraphQL technology.
  • There is plenty of time for learning/studying. 
  • Scalability is required in the future.

According to the documentation, Magento supports SOAP, REST, and GraphQL protocols, allowing almost any external system to communicate with its database/entities; however, when developing a new Magento API, the developer must understand how to choose the correct protocol for the right situation; at the end this will help a project to run smoothly.

Vuestorefront + Magento Implementation

Magento is cool and it has almost everything that you need for your online shops. But, many people complain about its speed, resource intensive, difficulty to maintain, etc. If you want to make your magento experience faster, you might need to burn more money for the server resources. But if you don’t want to do that, Vue Storefront might be an alternative.

“Vue Storefront is a headless and backend-agnostic eCommerce Progressive Web App (PWA) written in Vue.js” – quoted from their site. In theory, you can transform your magento to a PWA which should be able to perform like a native mobile app. So, if you want to make your Magento (especially, Magento 1) faster without spending too much money for the server upgrade, or; spending too much time upgrading to Magento 2, likely this is the answer.

We got a chance to help our major client to implement Vue Storefront to their existing Magento 1. The implementation is not that difficult and we’re on our way to make it happen. This article is gonna talk more about architectural implementations of it. 

AWS has a good reference on how to implement Magento on its cloud service (see pict above). It’s pretty standard architecture for Magento, though: load balancer (with optional autoscaling group), and the load balancer has several availability zone with its own independent services (multiple web servers, one single database, and one redis instance).

However, when you look at Vue Storefront architecture, there’s not so much difference. Vue Storefront will still use Magento to get what it needs via Magento API, then store the information in its own data storage (in this case it can be Elasticsearch or Redis).

This way, Vue Storefront will be the first server behind your load balancer that will process requests from the website’s visitors. Then, it will check on its storage (which is a lot faster because it uses no SQL) of the information that it needs, and return it back to your visitors. If the information doesn’t exist, it will finally request that information via Magento API. Behind the scene, Vue Storefront also does something cool to grab store info such as products, carts, orders, and others via Magento API regularly and store it on its own fast data storage. 

See that you will literally only need at least one additional server for Vue Storefront, one Elasticsearch, one Redis, and you are good to go!

In short, if you want to make your Magento 1 faster without spending too much time and money, Vue Storefront might be good for you. 😉 

Configuring Let’s Encrypt to reload Nginx / Apache2 after successful certificate auto-renewal

Let’s Encrypt is cool. It is more than enough for most of your SSL needs. Not only because it’s free, it can also automatically renew the SSL certificate for you (so theoretically you don’t need to do anything). You can always use Let’s Encrypt for your Nginx, Apache2, or anything else. One thing that you need to be aware of is that by default, it won’t reload / restart your web server after successful renewal. Then eventually, you will realize that your site is running under an expired SSL certificate while you see on the server that your certificate is still valid.

This problem isn’t a Let’s Encrypt bug nor the webserver’s. What you really need to do is just simply reloading / restarting your web server so it will load the newly renewed certificate. Otherwise, your web server will keep serving with the old expired certificate.

For Nginx, you can always do /etc/init.d/nginx reload, but you can automate it after successful Let’s encrypt renewal by using post_hook renewal parameter in your Let’s Encrypt domain renewal config. This way you can configure the post_hook configuration for each domain. Edit the file located at /etc/letsencrypt/renewal/yourdomain.com.conf and append post_hook parameter as below:

The second method, you can setup the renewal hook action for all domain by writing a simple script under /etc/letsencrypt/renewal-hooks/deploy/ and let’s name it with 01-reload-nginx. The full path is /etc/letsencrypt/renewal-hooks/deploy/01-reload-nginx.

Put this inside the file:

#! /bin/sh

set -e

/etc/init.d/nginx configtest

/etc/init.d/nginx reload

Then, save, and run the following command to make it executable:

chmod a+x /etc/letsencrypt/renewal-hooks/deploy/01-reload-nginx

Voila!

Fundamental VPS Security: SSH

In the previous article, we have listed some of the important things that you need to know about VPS security. In this second part, we’d like to dig a little bit deeper for securing your SSH.

SSH (secure shell) is a protocol to securely connect to your VPS over a non-secure network. Means, even if you are on a public wifi, your connection to the server will always be encrypted. We always put SSH security on the top of our security checklist because it is the most important thing to secure. If an intruder can gain access to your SSH, then he most likely will be able to read your files, put some malware, execute some commands, even use your computer resources for bitcoin mining or downloading illegal contents.

There are some prerequisites before we can change the config. All of the commands below need to be executed as root / sudo user.

First, you need to make a new user that we can allow them to SSH to the server, then we can disable root user login. So, let’s create a new user:

adduser john #adding user called John, follow the step and set the password

Then, generate a new SSH keypair for that new user. Remember that we’re gonna disable password-based SSH login. The SSH user needs to use the SSH key to login to the server.

su john     #login as the new user John

ssh-keygen  #and follow the prompts

Now you have the user and his keypair. Next, we’re gonna change the SSH config to secure it. There are at least three things that we normally do to ensure SSH security. What we’re really gonna do in this article is to edit /etc/ssh/sshd_config. Pretty simple.

So you can edit the config file:

vim /etc/ssh/sshd_config (or use any other text editor that you love) then, add these configurations below, or replace the existing ones (if any).

PermitRootLogin no         #disabling SSH login for root user

PasswordAuthentication no  #disable password-based authentication

Port 23232                 #you can change port number to anything here

Lastly, restart the SSHD service and you’re done!

systemctl restart sshd.service

Now you can test SSH login. Copy the private key that you generated on the server to your local machine. The file is usually located at /home/username/.ssh/id_rsa, so in this tutorial it should be /home/john/.ssh/id_rsa. Copy the content and put it somewhere in your local machine.

Then, try to login via ssh:

ssh john@your_domain_or_ip_address -p 23232 -i /path/to/your/copied/private/key

Now your SSH should have better security! Keep in mind not to share your private key to anyone.