In this scenario, the cpu cycles required to read from the database and render to PHP will all be handled by a single core, ie they will be handled one after the other. This will be about the slowest way to deliver website traffic out of your server.
Each time a request is made, a certain amount of memory is occupied by PHP. You are also able to handle aroundcan test the actual amount, but you can only ever be sure it is not greater than memory_limit. Based on a use of no more than 256MB per Drupal site request, you can divide your 1GB of memory by that number (minus some memory for apache, MySQL and the OS). The result are 3 requests in parallel beforefit into memory only. You certainly do not want to allow more, because either your serversystem runs out of memoryRam or it will use swap disk space. You better have no
The use of swap configureddisk space is even worse, as there is noit will slow down requests even more and consumes cpu to handle the copyingitself.
3 requests can be used up quickly by some Ajax requests in the page or your Admin backend, either one likely bringing the server to its knees. It would be best to check in Chrome inspector how many PHP requests the site makes on frontend and backend.
Your situation will improve somewhat if you can dial down your PHP memory limit to say 64mb, but you still have the single core as the bottleneck.
If you can remove all interactivity fromSo the site you maykey to keep this stable is to reduce the number of requests allowed either in apache or php-fpm to a number multiplied by PHP memory limit that stays smaller than your 1gb memory.
Your best option would be better offto copy out your Drupal pages to a static website every time a change is made. A transparent way for this is to put a Cdncdn in front ifof your site and only start up a server on aws whenwebsite. However you need to be sure.
Another non technical practical solution is to quadruple your hosting budget and find a sponsor or side gig to pay the backendcharges. This could be cheaper than $5