For instance, all statistic values, as well as the information about tests (name, duration, status) are stored in the database.īoth the agent and the server maintain buffers for the build results data: the agent sends results to the server when the buffer becomes full, the server also processes results in packs, because it greatly improves performance. During processing of these results, the server stores data in the build log on the file system and can also write some data into the database. Most of the time the results are being sent in real time, while build is still running, which allows us to show a nice real-time progress of the build in the web interface, send notifications early, and so on.Īn agent sends results to the server by the RPC protocol established over HTTP. Agents run builds and send results (build log, artifacts, tests, etc.) back to the server. We’ll start with the TeamCity architecture first: this will let us understand results better.Īs you already know, TeamCity consists of a server and a number of agents. In this post I’ll explain what kind of benchmarks we use and will also show some of the results measured against the latest TeamCity version – 9.1.1. This reply is based partly on our own experience and partly on our internal benchmarks. In synthetic tests the server was functioning OK with as many as 500 agents (the server with 8 cores, 32Gb of total memory running under Linux, and MySQL server running on a separate comparable machine). The latest TeamCity version is known to work well with up to 300 build agents (300 concurrently running builds actively logging build run-time data). This is our official reply to the question in the title:
Julia Alexandrova How many agents can be handled by TeamCity server?
0 kommentar(er)
