Thinking of switching from shared hosting to Linode

@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).

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.

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.

IMHO You'll have no problems, just use the my-small.cnf as a baseline for your mysql configuration.

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.)

Not sure about phpbb3, but most forum software allow static file building for threads, which should help to reduce mem usage

@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?

Thanks for the advice guys.

@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 - that is, a "graceful" Apache reload isn't so graceful, and kills all PHP scripts executing at that very moment sending HTTP 500 to users. With currently available FCGI handlers for Apache there's no workaround, unless one prefers using mod_fcgid and php in "dumb handler" mode without APC.