Skip to main content
added 943 characters in body
Source Link
jdog
  • 650
  • 3
  • 10

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

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. You are also able to handle around only 3 requests in parallel before your server runs out of memory. You better have no swap configured, as there is no cpu to handle the copying. 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.

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 from the site you may be better off to put a Cdn in front if your site and only start up a server on aws when you need the backend. This could be cheaper than $5

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 can 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 fit into memory only. You certainly do not want to allow more, because either your system runs out of Ram or it will use swap disk space.

The use of swap disk space is even worse, as it will slow down requests even more and consumes cpu itself. 

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.

So the key 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 to copy out your Drupal pages to a static website every time a change is made. A transparent way for this is to put a cdn in front of your website. 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 charges.

Source Link
jdog
  • 650
  • 3
  • 10

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. You are also able to handle around only 3 requests in parallel before your server runs out of memory. You better have no swap configured, as there is no cpu to handle the copying. 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.

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 from the site you may be better off to put a Cdn in front if your site and only start up a server on aws when you need the backend. This could be cheaper than $5