Help! We are slow­ing down - part 2

In our previous post, we pointed out that from a business point of view, the profile editor is the essential function of Speakerhub.com. We also explained how the data structure of the profiles reached the limit of possibilities provided by Drupal in a short time, with the increased number and complexity of fields.

Slow-slow, but what is slow?

From the development and hosting aspects, the feedback that was the hardest to manage and to understand was slowness. We continuously questioned back: which user experienced slowness? What is the user doing? Where is he coming from, and when? Does the page download latency only affect a few users? Or everyone? When? Is it one part of the recently running code that is slow, or is it a part of the system that is slowing down regardless of Drupal?

After some email exchange, it turned out that we have two different problems that require a divergent approach. One is the decrease of performance appearing when running scheduled tasks, which arise bothering server performance. We managed to smoothen these load projections on the hosting side, by fine-tuning the server parameters and making changes in the timing of tasks.

The other slowdown problem that occurred was from the business point of view, much more awkward. The feedback arrived each time from users who uploaded the most data, and who had the most detailed profile. From a business aspect, the most valuable users lost their user experience.  When we investigated these profiles, it turned out that the problem is not only the slowness of loading the profile editor, but the saving process is also time-consuming.

Let's measure

When we were able to reproduce the incident, we could start to define questions that were supposed to lead us to the root cause. Our first thought was that the database is slow; the profile object builds up slowly. Let's have a look at the indexes on the database tables storing profile data. It proved to be entirely below the previously specified time limit, even when loading elements with massive data. Even the loading of 1000 randomly selected components finished within 2-3 seconds.

The next thing we considered was that the form is quite severe, with many fields and values. It should certainly take a long time to build it up. It was a big surprise for us that this took far less time than we originally anticipated. We did not have any other explanation, then generating HTML for the browser takes most of the time. The measurements confirmed that in case a user has a significant amount of data, it takes around one second for the server to collect all data and build the form. Another 25-55 seconds are used to generate the output. Besides comes the time spent with network communication, plus the time it takes for the browser to display the site with all the photos and run other necessary codes.

How much time is spent?

Around this point, Andras came up with the autosave idea and the demand for three new fields. It was evident that we can sort out the new fields, but starting an autosave would soon lead to a server overload. 

Opportunities

Based on our measurements, it became evident that we could not resolve this problem within the frames provided by Drupal.

We hypothesized that while keeping the Drupal field module, we can generate machine-readable outputs that describe the form's structure. By using this structure and with the help of a client-side technology, we can build a web app to be used by the users. So we would exclude the sub-system struggling with performance problems, and replace it with a client-side resolution. 

After collecting the ideas, the shape of a system appeared that: 

• moves much fewer data between server and client than the current one 
• loads much faster
• can save changes faster

As a result, it would provide a better, speedy editing experience for the users. 

Server-side developments

According to the new operational logic, the server-side application should only be responsible for four factors. It should provide information regarding the structure of the form, and the edited profile, as well as managing file-uploads and saving profile changes. We couldn't resolve the first two tasks with the planned initially simple solution, but we still managed to put it together very fast. 

Saving changes was more difficult. First, we wanted to fix this with the tools provided by Drupal to avoid implementing complicated control mechanisms. But as this approach did not work, the compulsion became a prospect: we optimized the saving process. 

Client-side developments

The client-side technologies showed rapid improvement in the last years. Cursory observers may only sense that another world-beater project comes out each month, and everyone starts to write their framework. Lots of different sized packages, accessories, and tools are on the market. It is challenging to decide upon any objective criteria. As Andras did not have any specific preferences, we could also consider our comfort and sympathy aspects.

It would have been an obvious decision to choose jQuery, also used by Drupal, and support it with supplements. The event management and plugin system have proven it's worth the past decade, but still, we felt that we wouldn't learn from this solution, and also we would miss self-education possibilities and testing new things.

Tibi had experience with the first version of Angular system, but he didn't like it, it wasn't comfortable and is not supported anymore either. Angular 2 has only its name in common with the first version, while version 4 would be a significant technology change. We couldn't take this risk in this project. 

In the end, the actual superstar, the React, and the aspiring Vue.js system remained. We had to decide between these two. We looked through lots of example codes, open-source solutions, so we could estimate how we could resolve the real task with these.

We considered the usage conditions supported by license expectations and the surrounding community, but we couldn't decide. Suddenly a question was asked: "Which one would you rather use after half a year?" The obvious answer was Vue, so we started working with it. 

All our expectations were fulfilled once we were ready. In the case of an average user, the time from clinking to starting editing decreased to the tenth, the amount of data sent from the client to the server was reduced to the half.  Through the whole editing process, the server load also fell back dramatically.