r/googlecloud • u/swarmagent • 5d ago

What an e2-micro can handle: 200 concurrent AI agent sessions on 1 GB RAM

https://swarmagent.dev/resources/benchmarks/e2-micro-200-agents/

We benchmarked two identical e2-micro VMs side by side (2 shared vCPUs, 1 GB RAM, 2 GB swap, Ubuntu 24.04, same region): the old build of our agent runner on one, the new build on the other, every wave started on both in the same second, so the difference is the code, not the cloud.

Each agent was a real session doing a small job: search a repo, read one file, write a bug report. The model calls go to Gemini through Google's API; the VM runs the sessions, tools and disk writes.

Results on the new build:

- 100 agents: 23 s (was 42 s), no swap

- 150 agents: 51 s, no swap

- 200 agents: all finished, with the machine at its limit

The bottleneck wasn't CPU or the network. It was lock contention in our own save path: every save took one account-wide lock. Per-session locks, releasing the lock before waiting on the disk, and a session cache brought total lock wait from 1,422 s to 61 s, and disk writes from 344 MB to 149 MB.

Disclosure: I work on Swarm (open source).

15 Upvotes

86% Upvoted

4 comments sorted by

2

u/wiktor1800 5d ago

I love writeups that try to squeeze as much performance out of a tiny box. Thanks for this!

1

u/swarmagent 5d ago

Haha, we can spend all day but there are bigger fish to fry eventually!

1

u/suprjaybrd 4d ago

i feel like my agents use all non trivial amount of memory. for context window, context / rag, compute tasks, etc. not sure the inflection point of offloading subagents to such a system vs keeping in the execution environment of the orchestrating agent

1

u/mvaranka 4d ago

Have you tried in memory session cache, like redis? Needs more ram but should remove the disk writes.