Performance Issues on AMI deployed Build Server

So I made a Build Server (Windows Server 2016 on a T2.Small) with everything needed, and had it working directly in TeamCity without issue. Builds were 3-4 minutes including deployment. 

I then connected that EC2 instance via the Cloud Integration, and it also worked nicely. Starting and stopping the single instance without issue. I couldn't work out how to share that one EC2 instance in Cloud Integration across many projects however, so moved to an AMI.

I took an AMI from that instance, and have wired it up into the Cloud Integration. Everything *works*, it's actually really cool. I've even gone as far as enabling spot pricing, etc. very cool. 

but its slow. A build now takes 10-15 minutes where it is much quicker on the non AMI image. I can understand it taking longer to come online, deploying a server form the AMI obviously takes longer than just powering on an existing server, that's fine, but this is after its booted. Most of the speed issues seem to be in the GIT stages, the build logs show that "compute revisions" takes a LONG time. the rest isn't so bad.

I even tried bumping up to c5 and m5 instance types to see if that helps, and while it adds some speed to the actual build steps, it doesn't help this initial GIT step. 

 

Any ideas why the AMI version of the Build Agent would be so much slower? (I even tried re-activating the EC2 instance I took the AMI image from, and it's as fast as always, despite being a t2.small!)

0
2 comments

The 'compute revisions' stage happens on TeamCity server, not the agent. Please take several thread dumps at Administration > Diagnostics and provide them together with logs from TeamCity server machine and a log of the slow build.

0
Avatar
Permanently deleted user

I did some more digging, this is purely on the AWS side. When an EC2 instance is using an EBS volume, initial boot is directly/live from S3, data is copied upon first access, so the initial boot of windows, and use of each file/component is MAJORLY slower. For an instance that is transient and single-use, it never gets past this. 

 

I've found some basics on how to bypass this behaviour, or otherwise work around it, and this should hopefully resolve it. 

https://www.reddit.com/r/aws/comments/8pr4oa/ec2_from_ami_slower_than_original_machine/

Link to reddit where it is discussed in some details if it helps anyone else in a similar boat. 

0

Please sign in to leave a comment.