Posted by ay4you on September 7, 2009 at 10:37am
3 followers
Jump to:
| Project: | Boost |
| Version: | 6.x-1.0-beta2 |
| Component: | Caching logic |
| Category: | support request |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
This is more of a question that a request
basically we have 2 server running in load balancer mode everything works fine as at now
i have redirected login to only one server so we dont get any conflict on the database
also we have cron.php only running on one server it works fine for all database issues
but since boost keeps its cache on the file system when the cron runs it only deletes file on one server which is quite normal
my question is can i write a script to delete the files from the cache folder and will this affect boost of my site in anyway
Comments
#1
Long story short you would like boost to clear it's cache on multiple servers with a "signal" from one server.
This is what I'm currently thinking... do a POST to the other servers that contains an array of files that need to get nuked; serialize the array. Need some sort of verification to prevent evil. Could use some sort of cron key; like the crawler currently does. Is this what your asking about; also are you using beta2 or a different version? This is assuming all servers have the same cache.
#2
#3
yes that is what i am talking about yes i am using beta2. but the cache are not the same on the servers, but they are both set to the same config
same website same location just the content are different because of the links people browse. thanks for you reply but i sorted it out by excluding the boost tables from the replication and created a new cron on the second server to delete boost cache. hopefully that will work i am monitoring it now to see if i get any issues.
#4
Excluding the boost tables from the replication and running your own cron sounds like a good way to do it. If you can setup a network drive then both load balancers could point to that 3rd server for the static files, and the 2 front servers could take advantage of hit's from the other.
#5
going to mark this as fixed.
ay4you
Please re-open if excluding the tables didn't do the trick.
#6
Automatically closed -- issue fixed for 2 weeks with no activity.