TYPO3 Performance Issue: How We Resolved It

When a new product is launched, the task that tops the to-do list is usually predetermined. The team concentrates its efforts on building the minimum viable product (MVP) and thus turns an idea into something tangible for users at the earliest date. By getting the product in the MVP stage out to the focus group, the team collects feedback, modifies the concept in line with the user preferences and sets priorities for the future rollout version.

This is how ROI4CIO project started off. From day one this project had all the hallmarks of a unique venture that promised to revolutionalize collaboration and sales processes in the IT sector. Cutting-edge AI technology, new business model and dedicated focus on detail-oriented execution, it stands to reason why the ROI4CIO release was so much anticipated. As a proof of concept, Agiliway team implemented a quick solution with TYPO3 CMS. At this stage, the solution had all those core features sufficient to deploy the product. TYPO3 CMS successfully covered the necessary functionality (user interface visualization, data storage, processing of customer requests and responses).

Further, the original roadmap anticipated building fully functioning solution within Laravel framework after successful MVP. Such migration to PHP framework had to step up an early prototype to the scalable and fully reliable version that works under a heavy load. Yet the client decided to put the migration on hold until new important features were added.

As we integrated new features, turned ROI4CIO into a TYPO3 collaboration platform with advanced logic and complex configuration options, a system performance issues started to interfere.

Troubleshooting TYPO3 Performance Issue

CMS was running slow, took longer to respond or stopped responding. Large ORM objects caused average response time to fall dramatically under peak load. Accordingly, too many queries running at page load created bad experiences with performance.

Before users could start taking advantage of all that added functionality, Agiliway team had to find a way to reconcile complex system models with slow website load and response time. The solution came gradually. Neither a short-cut nor a trap of never-ending missteps, the problem-solving process took place in several stages.

Stage 1: Utilizing TYPO3 default settings of cache configuration

At the very outset using the default TYPO3 cache settings for the Redis cache seemed an obvious solution to the performance issue. Redis would cache queries, pages with static information and the front-end part. The measure significantly improved processes, yet the effect was only temporary. Tideways.io profiling for pages that send and receive multiple HTTP requests/responses located bottlenecks both in TYPO3 and server settings. In particular, inefficiencies associated with web service called for user data session management, created the need to cache ViewHelpers and Formhendler as well as use the lazy load design pattern to process large data objects. The issue was addressed by changing TYPO3 default settings and transferring the user data session from the database to Redis Cache. These measures improved the web site performance, optimized TYPO3 Fluid plugin and the TYPO3 extension Formhandler. For obvious reasons, the solution proved effective only in the short run.

Stage 2: Rebuilding TYPO3 data layer

As the solution grew, the new features started showing a growing number of related business objects with a large number of data records. TYPO3 has become slow in processing requests with multiple related objects, so we decided to review the ORM structure of TYPO3 and to optimize it. In the first place, we rewrote the main queries built by the core TYPO3 extensions.

Going further, we conducted a global analysis of the ORM relationships. As a result, the team constructed a new structure of database queries and redesigned the database structure. ORMs relationship was replaced with Individual Database Queries.

These actions reduced the number of requests from particular pages, which led to a dramatic impact on TYPO3 performance – page load speed increased 3-10 times depending on a page.

Stage 3: Upgrading to latest PHP 7.2 version

The project kept evolving, requests for new features and an improvement to an existing functionality kept pouring in, gradually wearing off this short-term effect of the suggested solution. Given the growing number of users and the vast amount of ever-expanding information on the website, Agiliway team considered moving away from the monolith system built for the beta version and adopt a scalable architecture for fast and stable website performance. In the light of new features, functions, and performance enhancements the latest PHP 7.2 version had to offer, migrating to PHP 7.2 was defined as an uppermost task.

PHP 7.2 offered around a 40% improvement in performance speed. For comparison, when using PHP 5.6, the page took about 3.5 seconds to load, while after moving to PHP 7.2 the page load time index dropped to 2 seconds. Similarly, Start Render and Response time indices increased by 30-40%.

Stage 4: Migration from Apache/ mod_php to Nginx / PHP-FPM

Equipped with some great new features and improvements following PHP 7.2 upgrade, we went for another important update, that is migration from Apache/ mod_php to Nginx / PHP-FPM. Apache/ mod_php, though popular and easy-to-setup web server, is quite inefficient for PHP applications where performance is a crucial quality attribute. On the contrary, built for maximum performance and stability, Nginx displays features fairly fit for the purpose:

• fast, reliable, highly customizable web server;
• effectively maintains static content and redirects dynamic queries to PHP-FPM;
• highly modular for extensive functionality;
• uses a reactor pattern (event-driven approach) to handle a large amount of simultaneous connections;
• excellent documentation and strong tech support from Nginx team.

The transition to Nginx ensured a 30% increase in speed and efficiency with which requests are processed to the database. Such improvement positively affected the website performance and increased the max number of simultaneous user connections 3 times.

Stage 5: Leveraging Amazon Web Services

When a website experiences increased traffic and offers extensive functionality, a strain is also put on a cloud service platform. For this reason, Agiliway team set out to ensure a cloud service platform can efficiently deliver the solution by leveraging the latest powerful cloud-based best services. The decision was made to move to AWS (Amazon Web Services) platform known for its increased scalability. To solve the problem of a high load on the website and database, the cluster group was created and certain features added, in particular:

• Database server copy and two read replicas. Read-only queries to a database would be read from the read replica while write-only queries written in the database;
• ROI4CIO service containerization was implemented;
• Amazon ECS would support multiple containers. When the generator uses over 80% CPU an additional container is launched;
• Amazon CloudFront service was configured for media content management. All content would be stored in an Amazon S3 bucket that supports CloudFront content distribution;
• Amazon ElasticCache service (Redis) was installed and configured for ROI4CIO service.

In retrospect, resolving TYPO3 performance issue at times felt like breaking the back of the beast. With our backs to the wall, our team rose to the challenge by upgrading the entire system based on TYPO3 CMS to the new PHP version, simultaneously migrating from Apache to Nginx and stepping up cloud hosting services. We had to fix malfunctioning extensions, change server configurations and TYPO3 settings. With all these actions, not only did we speed up request processing and shortened the website response time, but also took the load off the primary as well as the database server.

READ ALSO: TYPO3 Regulation Adoption System for a Hospital Operator