All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Which matters more? I/O or CPU?
I have a joomla website with 35,000+ articles and recently (a bit after 20,000items) i've started to notice that my load speed is going down.
I am using fastcgi cache and its great, but as my content is pretty dynamic my timeout is set for 5mins. Also, logged in users do not get cached (commenting, forum and whatnot) and I feel pretty horrid with the sub-par quality that registered users get.
This site is currently on vultr's $7 plan. I was looking to get an upgrade and was wondering for a database intensive site, do i need CPU power or disk I/O?
--- more background for the adventurous ---
I benched my potential ramnode server today (using Server Bear) and got an i/o of 1,200 (dafuq?) the cpu on the other hand left to be desired with a score of 2700 on Unixbench (1024gb SVZ)
I also benched my second potential server, Vultr's $15 plan with double ram. Disk I/0 was 300ish but Unixbench gave me a score of 3500.
Trying to decide between the two, seems like a question of CPU or I/O at this point.
Comments
Have you checked your resource usage for the bottleneck? This is something I'd recommend doing before you dive into purchasing other plans.
The Cpu spikes alot but it's always brief and my load stays under 20%. If there's any way to check i/o usage id love to know.
Disk is always important for database, you can cache indexes and stuff but some operations still are going to hit the disk. CPU depends on various load factors of the database, you should check your CPU usage on your current system and see based on that. Since you are already running your application on a VM it shouldn't be hard to see what's limiting the response time as @WSCallum said.
Raw I/O throughput is poor comparison for disk. Best comparison would be to benchmark the performance of your application on the VM, but you could also try something like seeing how long it takes to upgrade packages. Either way RamNode probably has better disk setup than Vultr.
Edit: you can use iotop to check I/O throughput being used, but more importantly probably to run iostat 1 and see what I/O wait is. You can also run a test like copying your database over to RamNode and running some queries that your web application would perform, on the cloned database.
You could maybe try php-apc as well..
Pretty sure that would just measure the i/o which I've already did. what I wanted was to see the current usage.
regarding php-apc, as I am using dotdeb I got some compatability issues trying to install that. In the end I settled with memcached. If I'm not mistaken I believe they do pretty similar data/opcode caching.
iotop and iostat check current usage, in different metrics. Note that bandwidth (which iotop displays, among other things) isn't particularly useful, sequential writes is always going to be faster than random writes, even for SSD (although difference would be much smaller).
My view: you're looking at the wrong spot.
In pretty every dynamic web site something like the 80/20 rule holds true, i.e. 20% (typically even less but, oh well, it's called 80/20 rule) cause 80% of load/io/throughput/whatever. And the other 80% cause quite little work.
So, find the "20%" that causes work (io, cpu load, whatever) and optimize that.
Where "optimize" in the context of DB means, for instance, buffer the hot spot aggressively and take away buffering from rarely used tables. Or find the best working number of DB connections. Or ...
I will assume you have SSH access. if so then :
on CentOS (you may need external repo)
yum install iotop
on Debian/Ubuntu
apt-get install iotop
then execute
iotop
Highest Regards
Mohammed H
They do have xcache, which is also very good. Are you using php5-fpm?
Run top and show is up the top section most importantly:
%Cpu(s): 0.8 us, 0.1 sy, 0.0 ni, 99.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
before any conclusion, run
https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl
Then check, maybe your db needs just a bit of optimization
thanks for that man, got quite a bit of red flags there.
Any luck ?
@drserver followed general instructions, got slightly better performance. gonna do a mixture of your and @bsdguy recommendations and try to find the 20% that is causing it. Will re-install joomla, re-import posts, optimize database then add extensions one by one and test...
Find the slow queries. Optimize then by introducing the proper missing index
yea, when I ran the mysqltuner script it found like 30,000 joins without indexes O.o
That is issue most likely.
It will work better than before when you are done with it. Good luck