Thinking of switching from shared hosting to Linode
However I wanted to ask about my likely requirements for a Linode. I'm hoping (for cost reasons) to get away with using a Linode 360. The main purpose of which will be a forum I currently have hosted elsewhere.
The forum current has about 500,000 hits a months (<= 2,000 visits a day). Max concurrent users might be about 50 when busy. I'm looking to runs omething like phpbb3 on a LEMP setup. I should in at current rates be looking at less than 100GB transfer a month. Does this sound feasible on a 360 or should I be looking higher up the scale?
Thanks for your help in advance, I'm looking forward to being a Linode customer.
11 Replies
@RoryH:
The forum current has about 500,000 hits a months (<= 2,000 visits a day). Max concurrent users might be about 50 when busy. I'm looking to runs omething like phpbb3 on a LEMP setup.
I've heard of 360s handling more traffic; just be cautious with memory and you should be fine. You are already way ahead of the curve using LEMP as opposed to LAMP, as it's easier to optimize for a low-memory situation.
Also optimize MySQL for the available RAM.
A 540 would give you a touch more breathing room, but you'd probably end up using most of the extra RAM as cache (which isn't a bad thing).
I started with a 540 then dropped down to a 360 when I realised it was too much for my requirements. The downtime wasn't too long and I was refunded to the day for what I didn't use so that's always an option.
@different:
Feasible, sure, but something to burst with if you're ever slashdotted or just extra RAM so 50 concurrent users aren't hitting the hard disk too hard would lean me towards recommending a 540.
Well. It might not actually "burst" in the sense that a pre-fork Apache setup would bring the box to its spiral of death when it gets Slashdotted.
With NginX + fix sized PHP/FastCGI backend, the number of FastCGI processes pretty much caps the maximum amount of memory you are going to use. So when you get slashdotted/dugg, it's just going to be slow (Nginx finding the next available FastCGI backend), but it probably won't kill the box.
Using LEMP is a really good idea (personally I still use apache as a back end since it allows me to use caching facilities of apc and mod_wsgi for python, roll on PHP-FPM getting released with the PHP core).
I run a system with a similar number of hits and have no problems.
@scotty:
@different:Feasible, sure, but something to burst with if you're ever slashdotted or just extra RAM so 50 concurrent users aren't hitting the hard disk too hard would lean me towards recommending a 540.
Well. It might not actually "burst" in the sense that a pre-fork Apache setup would bring the box to its spiral of death when it gets Slashdotted.
With NginX + fix sized PHP/FastCGI backend, the number of FastCGI processes pretty much caps the maximum amount of memory you are going to use. So when you get slashdotted/dugg, it's just going to be slow (Nginx finding the next available FastCGI backend), but it probably won't kill the box.
A properly configured apache setup would do the same thing.
@glg:
A properly configured apache setup would do the same thing.
Agreed, I have a little happy 360 server (3x25threads apache worker, 25 php fastcgi backends, 30-60 requests/sec) that works in almost constant memory space. Fluctuations aren't larger than 10-15 MB, and I usually have about 200 MB of RAM available to disk cache. In cases of heavy rush, it doubles the number of worker processes (+~20MB physical) and if that's not enough… it just gets slower.
Just a hint if you're gonna use worker and care about the (Mostly Harmless) virtual memory commit readout…
<ifmodule mpm_worker_module=""># ...
ThreadStackSize 2097152</ifmodule>
Default is 8MB. And theoretically, 1MB should be plenty, but better to err on the side of caution.
@RoryH:
about 500,000 hits a months (<= 2,000 visits a day).
Hits and visits are completely different beasts. 2,000 hits a day calculates to less than 2 per minute on average, while 2,000 visits a day would amount to dozens or perhaps hundreds of times more.
In either case, there's no reason a 360 shouldn't be able to handle it, especially with a LEMP setup, provided that: (1) you pay attention to the MySQL configuration, and (2) the active part of your database plus indexes can fit in RAM.
If you're slashdotted, static files will be served by nginx just as efficiently as before, and dynamic requests will simply queue up until a FastCGI process becomes available. The server won't run out of memory, it will just become a little slower than usual due to the CPU and I/O load. (Unless, as mentioned above, MySQL betrays you.)
@rsk:
@glg:A properly configured apache setup would do the same thing.
Agreed, I have a little happy 360 server (3x25threads apache worker, 25 php fastcgi backends, 30-60 requests/sec) that works in almost constant memory space. Fluctuations aren't larger than 10-15 MB, and I usually have about 200 MB of RAM available to disk cache. In cases of heavy rush, it doubles the number of worker processes (+~20MB physical) and if that's not enough… it just gets slower.Just a hint if you're gonna use worker and care about the (Mostly Harmless) virtual memory commit readout…
<ifmodule mpm_worker_module=""># ... ThreadStackSize 2097152</ifmodule>
Default is 8MB. And theoretically, 1MB should be plenty, but better to err on the side of caution.
;)
Could you share your whole worker config and how you setup fastcgi?
@hybinet:
@RoryH:about 500,000 hits a months (<= 2,000 visits a day).
Hits and visits are completely different beasts. 2,000 hits a day calculates to less than 2 per minute on average, while 2,000 visits a day would amount to dozens or perhaps hundreds of times more.
Sorry, I think I may gotten confused alright quoting stats, to clarify:
In the last month:
* 53,675 visits: 1,731.45 Visits / Day
- 434,220 page views
> Could you share your whole worker config and how you setup fastcgi?
It isn't much.
Note that I don't consider myself an expert by any way, it simply works Good Enough For Me ™. You will need to pay attention to your rewrite and/or redirect rules so /WhateverFakePath/ is exempted from them.
<ifmodule mpm_worker_module="">StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
ThreadStackSize 2097152</ifmodule>
EDIT: Heh, seems that in the meantime these very values appeared in mpm_worker docs as an example.
FastCgiConfig \
-idle-timeout 120 \
-initial-env PHP_FCGI_CHILDREN=24 \
-initial-env PHP_FCGI_MAX_REQUESTS=500 \
-killInterval 100000 \
-listen-queue-depth 300 \
-maxClassProcesses 1 \
-singleThreshold 0
# You will need to pay attention to your rewrite
# and/or redirect rules so /WhateverFakePath/
# is exempted from them.
AddHandler php5-fastcgi .php
Action php5-fastcgi /WhateverFakePath/php-cgi
Alias /WhateverFakePath/php-cgi /usr/bin/php-cgi
<location whateverfakepath="" php-cgi="">Order Deny,Allow
Deny from All
Allow from env=REDIRECT_STATUS
Options ExecCGI
SetHandler fastcgi-script</location>
Works cool, except for one little PITA you can read about in this thread