Disk IOPS for disk-bases caching (Apache)

[guest2013-1]

I was wondering, disk-based caching with mod_cache in Apache, how many IOPS do you think is required to sustain a pretty heavy website? (50k hits a day)

I wrote my own caching for an API I'm using, and only it's data (which is less than 100kb per hit), is causing my "wa" time to exceed 25% on the disk and pushes my server load up to 6 - 9...

So now I'm wondering about the disk stuff

 

[encrypted]

Your cache engine is doing it wrong.

50k hits is pretty much idle considering a day is 86400 seconds.

How many objects are you caching ?

If its just cache data you should be doing a delayed write. You are spinning the rust too much.

 

[TheRoDent]

memcached ?

 

[nkawit]

There is a problem if you hitting loads of 6-9 for 50k hits a day which are 100k each.

I wouldn't mind having a look at it for you.

 

[guest2013-1]

memcached ?

I switched over to memcached yes. I now want to implement disk-based caching for frequently generated PHP files using a reverse-proxy like Varnish or even switch to Litespeed instead of using Apache. What I noticed when using the disk-based caching was that it pushed up the load times, so it's my only worry here.

I guess I'd have to implement and test to see if my worry about the disk not being able to cope with something like this is correct or not. I'm currently on a cloud-based server, so disk access is limited to begin with.

 

[guest2013-1]

There is a problem if you hitting loads of 6-9 for 50k hits a day which are 100k each.

I wouldn't mind having a look at it for you.

I should have been a bit more clear, the 50k are unique visits. The hits to the API is about 500-600k daily. Hopefully Varnish and/or Litespeed uses delayed writing as encrypted mentioned. Thanks for the offer. I might take you up on it. I've been messing around with servers for a decade now, but it's not my primary function, and my linux experience is less than 3 years unfortunately

 

[koffiejunkie]

Your cache engine is doing it wrong.

+1

The idea of caching on a webserver is to *avoid* hitting the disc. As others have said, look into memcached. It's pretty simple, there are modules for just about every language, and any web host worth half a zim dollar should offer it on their webservers (assuming we're talking Linux here).

Disc I/O is a complicated beast, as long as there are moving heads. It's even more complicated when you're considering an array when what you get is not really what you see. It is not uncommon to see high iowait on a RAID-1 array that's doing 3MB/s - thats what concurrent random reads and writes does to your performance.

 

[guest2013-1]

Yup, all is memcached with about a 20% hit rate at the moment, have a dedicated server for that as the other 2 servers I have uses the same API so I thought it best to consolidate their calls and serve from cache where-ever possible.

AFAIK Varnish does have the ability to serve cache from memory, but since I'm going to be scaling my project up to around 150+ sites (all using the same API with different layouts etc), having a Varnish "ram only" cache vs a disk-based on and/or running litespeed instead is something I'm having to consider.

I'm also splitting off the MySQL servers on both servers and consolidating that into one dedicated machine. Thinking I should try varnish and check it out first...ugh

 

[guest2013-1]

I wanted to get litespeed up and running but apparently 64bit isn't supported on the Standard/Free version. So had to abandon that idea. I opted to go for Varnish and reverse proxy it to Apache.

All I can say is "wow". The disk didn't even flinch and my average response time for my site went from 2200ms to 550ms Some speed tests indicate a response time of 280ms. I'm really liking the change I've seen.

 

[koffiejunkie]

Yep, varnish does add a certain, uh, varnish to a solution