Cancel
Start searching
This search is based on elasticsearch and can look through several thousand pages in miliseconds.
Learn more
This search is based on elasticsearch and can look through several thousand pages in miliseconds.
Learn more
We have already discussed the topic of Front-end performance in a previous blog post. This article is about performance in the backend and which factors play a role in application development. What needs to be considered and what levers are there?
There are already considerable differences in performance when choosing a programming language as the basis for developing an application as part of a project.
If you look at the pure numbers, e.g. when calculating the "Leibniz formula" for an approximation of Pi, it becomes clear that languages such as PHP, which we use in many of our projects, are at a clear disadvantage compared to JS or Rust. In this case, the calculation for pi was iterated through the Leibniz formula 1,000,000,000. (Source: GitHub, Niklas Heer)
It is therefore important to take a serious look at the task for the application at the start of a project. In addition to pure computing power, there are of course many other factors that play a role in the selection process.
For example, Rust would be a good choice if the application is security-critical (memory and type security), scalability plays a role (multithreading) or system-oriented programming is crucial. These are all areas in which PHP performs worse.
For many customer projects, PHP scores points with a large selection of established frameworks(Laravel, Symfony etc.), simple hosting, higher development & debugging speed and a more dynamic nature in terms of typing.
In our experience, it pays to analyze the objectives of the application in detail at the beginning of the project in order to take advantage of speed benefits through the choice of programming language.
In practice, however, other factors are more important for backend performance in our project business.
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
For the overall performance of an application, it is of course important to consider the infrastructure or peripheral systems in which it is embedded. Many components influence performance. The interaction of databases, caches, file storage and interfaces must be examined. From our project experience, there is considerable optimization potential for an application in this interaction.
But how do we proceed and where do we start without wasting important project resources on small performance gains?
How can we identify and narrow down the actual need for optimization in our application in order to waste as few resources as possible on non-critical optimizations? This question arises again and again in everyday project work.
A good example of a tool in this area is"blackfire", which we are currently evaluating for our PHP projects. Through continuous profiling, live monitoring, tests and CI/CD integration, the software can quickly identify bottlenecks and also visualize them for our developers. It remains to be seen to what extent we will integrate the software into our existing CI/CD processes.
Another "tool" or good indicator that we have been using in our projects for some time is the analysis of the Varnish cache status from the Nginx logs.
We look at which content is successfully cached and which is not (miss, uncacheable, unconfigured) and observe deviations. The "clustering" of content types from the Nginx log according to "request time" also provides initial conclusions about the causes of performance problems in the application.
Well-designed caching, which differentiates between cache units, brings a direct performance gain with moderate effort. there is a whole range of cache units into which caching can be divided. The most important are "object caches" and "full page caches", but there are of course also query caches, OpCode caches and many more.
It may sound trivial, but in practice, our projects have shown that it is worth taking the time and distinguishing between dynamic and static content is not always easy for our customers. But the analysis is worthwhile in order to realize performance gains.
These caches are suitable for complicated, deterministic operations as part of the application routines, e.g. dynamic web applications with personalized content or dynamic data. As the request is retrieved from the cache, the database and APIs are relieved. Redis, Memcached or APCu are often used here.
With "Full Page Caches" (FPC), as the name suggests, complete rendered pages (HTML, CSS, JavaScript) are cached and delivered directly, which reduces the load on the web server and the database enormously. This type of caching is perfect for static content, but also has its pitfalls, as there can be delays when changes are made, e.g. by the editorial team, as these first have to be updated in the cache. FPC works with pure "GET" requests.
Varnish, Nginx or Fastly are often used here. In addition to the higher performance, the cache in this case also protects against success or DOS problems, as the web server is not accessed directly.
To avoid performance problems, it makes sense to use relational databases (RDB) such as MySQL, PostgreSQL or MariaDB. Of course, it must be checked for each application whether relational or non-relational databases should be used; in the classic CMS, CRM or e-commerce area, relational databases can often be used.
The advantages of RDBs are obvious; the structure in table form means that queries can be carried out efficiently. It is even faster if additional "indices" are defined. However, it should be noted that even small changes in the database require the index to be rebuilt, which can also take time. The aim is to move the logic to the database, which is best suited for this and can process it very efficiently. If performance problems are detected in the database, a pragmatic solution can also be to simply increase the available working memory.
Without wasting resources unnecessarily on code optimization, for example, a lot of performance can be gained on the query and database side.
Vertical and horizontal scaling are classic methods for improving performance. Both methods have their advantages and disadvantages, but have a significant impact on performance and should be examined more closely if problems arise.
Vertical scaling (scale-up) is based on an increase in performance on the hardware side. Additional CPU & RAM capacities are provided in order to execute operations faster.
The advantages are that this method is easy to implement and hardly causes any additional latencies (e.g. network overhead). No additional complexity is created by additional software, as the optimization takes place on the hardware side.
A clear disadvantage is of course the physical limits of the hardware and the risk of failure. It can also be costly to maintain a powerful server and not switch to several small instances (horizontal scaling).
The aim of horizontal scaling (scale-out) is not to rely on one server with high performance, but to distribute the load of an application across several shoulders. This relies on a microservice architecture that can be combined with load balancers, for example, and also includes database sharding and container orchestration.
The advantages are incredibly flexible scalability, where new instances can be easily added and a high level of reliability can be guaranteed. Dynamic scaling with Kubernetes or Auto Scaling Groups also has many advantages for dynamic applications.
One clear disadvantage is the complexity of the system. This increases with every additional component. The requirements for synchronization and consistency (consistency management) increase and there is more database and network overhead (network communication, data replication). Applications based on relational databases in particular are not suitable for horizontal scaling.
There are many adjustments that can be made to improve the performance of an application. Even if you can avoid typical problems when designing an application, e.g. with the architecture and infrastructure, the choice of programming language and the right choice of scaling, it is important not to start optimizing too early and to take the time for an analysis so as not to spend a lot of resources on small performance gains. With "blackfire" and the nginx logs, we have shown two ways in which problems can be identified and highlighted classic fields in caching and the outsourcing of logic to databases.
Especially in large projects with many dependencies, it is often not easy to identify the causes of performance problems. This article is intended to make it easier to find the causes and, if necessary, prevent them from arising in the first place.
If you are unable to find the cause of performance problems in your application, we will be happy to support you with our experience from over 25 years of application development.
