That's actually not really bad all considered. 171ms response time is more or less reasonable, your database server response times in specific seem reasonably good (and that's what we're optimizing here). PHP is the major limiting factor here now. What version of PHP are you running? You should definitely look into enabling OPcache if you haven't already. This comes native with PHP 5.5, before that (5.2 - 5.4) you can install PHP OPcache as a PECL extension . Statistics from just the last 30 minutes also only say so much, it would be good to see how your application performs over a 24 hour period. Now that you have this set up, you'll be able to see the real impact to any server configuration changes you make as well.
I know I've read up on read committed transaction isolation before, once a long time ago, but I guess I never gave it much serious thought for whatever reason, I don't remember why. I've read into the implications of it a bit more and it is very interesting. It seems like it's a perfectly safe default setting to use for most web applications, and if it really makes such a large performance impact on IP.Board that's awesome, I'll test this on my production websites a bit soon and see if it makes any noticeable difference for me. (Though, my average database response time is only 6-10ms anyways ) Disabling flush log at transaction commit is one of the best tweaks I know of. Normally MySQL/InnoDB has to flush its log to disk at the end of each transaction without this setting, which naturally can be detrimental to performance. Setting it to 0 just causes it to be done in the background every second instead at the end of each transaction. It's a simple tweak that's great for improving performance (as long as you don't mind the risk of losing a ~single seconds worth of data in the event of a sudden server crash or loss of power, which it's very unlikely you do).
So a user can't have both an inline notification and an email notification sent to them for the same event? It seems a little silly to get an email for all replies to a topic, except for replies in which someone quotes you.
IPS runs off a custom built framework. Even if it adheres to the MVC paradigm, it's going to be very difficult to learn much just by looking at its code. Everyone has different coding styles and different ways of doing some things. If you're looking to learn more about the Laravel PHP framework as well as some best practices centered around it, I can personally strongly recommend Laracasts to you as an excellent learning resource. Also feel free to drop by #laravel on Freenode if you ever need help, there are many experienced Laravel users here happy to help here if you need it. You can usually find me idling in there as well
Ah, yeah, affiliate marketing can be a good alternative to general purpose advertising if you can find affiliate programs that target your forums niche. Even Amazon has an affiliate program that you can sign up for, which can be great if your forum is centered around just about anything you can buy on Amazon (e.g. for a forum centered around a specific TV series, you could list ads for the bluray collection of the series. For a general automotive forum, you can offer advertisements for products an auto enthusiast might be interested in. So on so forth.).
If AdSense isn't producing enough revenue for you, the only other option is self-served ads. There are pretty much no alternative services that can come even remotely close to competing with AdSense, they all pay horribly and generally serve terrible ads on top of that. I would love for someone to prove me wrong on this, but this has been the reality of the advertising industry for the average webmaster for as long as I can remember. It's awful. Advertisement revenue is almost always completely terrible with anything other than AdSense and even then unless you run a high traffic website you're not going to be making much. I don't run ads on any of my websites because of this. $1/CPM actually seems like a very high rate to me, but it's very niche specific and advertisement rates are based entirely on how much people are willing to pay, so if people are actually buying ad space from you for that much, power to you, that's impressive.
Please be sure you're referencing data from a server side utility like Newrelic and not WebPageTest.org. These third party utilities are impacted by a wide variety of factors outside of your control and are really not reliable for testing server/application performance. Don't worry about bind-address for right now, it's a security directive to prevent remote connections but I don't know enough about your server configuration to suggest changing it. Yes, mounting tmp as tmpfs can be helpful as long as you have memory to spare.
There's still a disk overhead in other areas but ideally yes. I know it may sound a bit contradictory, and I used to frequently say SSD's shouldn't be necessary on properly tuned database servers with plenty of memory available, but I don't really bother trying to preach this ideal world scenario anymore. It's such an easy upgrade that makes such a significant improvement to overall server performance that it's very hard to argue against. With enough memory available and a large enough buffer pool, MySQL should be reading and working almost entirely from memory. Even so, there has always an undeniable substantial improvement to database (and overall) performance with every server I've worked on after upgrading the primary OS drive to a SSD, no matter how thoroughly optimized it may have been. So, I really shouldn't have painted this as something specific to the database server, because it's not. It's also a general server upgrade. You're probably running off a standard 7200RPM disk currently. You will likely be amazed at the difference in performance you will see after upgrading your primary OS drive to a good solid state drive. It's really not that different from the feeling of upgrading your desktop to a SSD for the first time. (Which, by the way, if you haven't already :P) I'm not saying it's an alternative to properly tuning your database server or anything of the sort, it's not, but if you're trying to improve your overall server performance and have enough room in your budget to upgrade, it's probably the easiest and most significant performance upgrade available to you right now.
If it's an option for you and within your budget, I would seriously consider building a server utilizing a SSD as the primary drive and an extra HDD for storage if you need it. Spinning disks are simply slow and one of the primary bottlenecks for a database server, that's why a lot of the major performance optimizations are centered around minimizing disk I/O. Upgrading your server to a solid state drive will give you an immediate all around substantial performance increase. To offer a bit of perspective, this one of my main production forums running off a RAID 1 SSD configuration for the operating system and database server (and a hardware RAID 5 configuration for storage),
This is also running on a customized Nginx + PHP-FPM setup among many other various server optimizations, but getting scalable database performance like this on anything but a solid state drive is going to be pretty much impossible, MariaDB 10 and InnoDB/XtraDB 5.6 have introduced a lot of improvements in this area, but your HDD will always be a large bottleneck no matter what you do. Upgrading your server to a SSD is probably the single best thing you can do to improve overall performance. So, again, if it's an option for you and within your budget, it's something to seriously consider.
Measuring TTFB using third party tools like WebPageTest and so on isn't very accurate or reliable. I recommend installing and utilizing something like Newrelic as @RevengeFNF is using in his above screenshot, that will provide you with real accurate performance metrics of your application itself , which is what you want here. By the way, I don't think you ever mentioned, this is this an actual dedicated server you are renting/leasing right, not a VPS? I'm assuming this is an actual dedicated server being that you have 16GB of memory available to you. And if this is a dedicated server, what is your current hardware configuration? (Specifically, what is your database server running on? A single spinning disk, a SSD, a RAID configuration?)
You can ignore the suggestion to enable query cache. I've seen mixed information regarding increasing table_open_cache, you can continually try and increase this and mysqltuner will just immediately tell you to increase it further. This is what I currently have configured, and you can try increasing this steadily yourself and see if it makes any noticeable improvements for you, table_open_cache = 4096
table_cache = 4096
table_definition_cache = 4096
The only negative impact of having a large buffer pool that I know of is that it makes recovery slower in the event of a crash. Quoting from the MySQL docs, 32MB may be a perfectly fair value for your current traffic requirements, but keeping burst traffic and scaling in mind I would avoid setting this value too low, and leaving it at 1/4th the buffer pool I think should be fine unless you are constrained on storage and have a really large buffer pool.
The default value for innodb_buffer_pool_instances in MariaDB 10 is actually already 8. I don't mind having to let my forum warm up again after restarting, as restarts are so rare and warm up doesn't take that long anyways, but it's certainly a fair suggestion.
As a friendly correction (since I don't think English is your primary language), when you want to tell someone you'd like to take up a project for them, you generally say you're "interested in it", not "interesting in it". Interesting just describes a specific something. "This is interesting" vs "I'm interested in this", as an example. I hope that makes sense, and I don't mean to insult you or anything, this again is just meant as a friendly...