Exhausted from sluggish pipelines despite applying all possible techniques? Try Cloud-Runner and see your pipeline times cut by a factor of ten. Experience the speed for yourself with our free trial!
As an easy way to run CI/CD pipelines for your projects, GitLab provides shared runners. These runners may, however, be slow for a variety of causes. GitLab shared servers can occasionally be sluggish for the following reasons:
The n1-standard-1 instance, the smallest and most fundamental service offered by the Google Cloud Platform, serves as the platform for GitLab shared runners. (GCP). This service is limited in terms of system resources, which can cause issues for runners that are handling tasks that require significant amounts of memory or CPU power. Additionally, if multiple jobs are running simultaneously, the shared runner may not have enough resources to handle all of the requests, resulting in slower performance and longer wait times.
Shared runners only have one core, which means that tasks cannot take advantage of multithreading. If you are performing parallel processing-intensive, compute-intensive tasks, this may be a particular problem. For example, if you are running a lot of tests that require compilation, each test may take longer to execute on a shared runner, which can slow down the complete pipeline.
GitLab shared runners are pre-emptible instances on GCP, meaning they can be stopped at any time. As a result, there may be a longer wait for jobs to begin. Additionally, during periods of high demand, GCP may favor other users over your tasks, which can lead to even longer wait times. This can make it challenging to forecast when tasks will begin or end, making pipeline planning challenging.
GitLab shared runners are virtual machines, which means that they have a layer of virtualization between the host machine and the container that executes the job. This additional layer may cause overhead, which could slow down work and extend wait times. Performance may also be restricted because the runner may not have direct access to all of the host machine's resources because it is running inside a virtual machine.
As was already stated, the billing per minute model underlies GitLab's business strategy. Therefore, GitLab has no cash motivation to make investments to raise the efficiency of shared runners. Shared runners are designed to be used by all users, so there may be several users performing jobs on one runner at once, which can cause resource contention and slower performance.
Shared runners may experience stability, reliability, and maintenance issues in addition to the aforementioned restrictions. You do not have direct control over the infrastructure of the runner because it is provided by GitLab, which may result in unanticipated downtime or update problems. Furthermore, since shared runners are used by numerous users, there might be incompatibilities between the jobs of various users, which can have an even greater impact on performance and dependability.
CI/CD pipelines can be easily run using GitLab shared runners, but they have a number of drawbacks that can result in slower performance and longer wait times.
In contrast, we, at Cloud-Runner, offers runners that are optimized for performance and can handle high workloads with ease. With dedicated resources, multithreading, and a high-speed network, Cloud-Runner can provide faster pipeline execution and shorter wait times. Performance can be further enhanced because there is no resource contention because each runner is dedicated to a single user.
