On Nov 12, 4:33 am, Frank Stelzer <[EMAIL PROTECTED]> wrote:
> Our IT director is a performance freak (ok, we too) and thinks that
> processing a page is slower, when a web server has to manage the cache
> folder on its own.
Hmm... I would think the overhead of communicating when using a sha
I think you're really heading in the wrong direction with this - what
happens when ALL nodes try and rebuild the SAME configuration at the
same time? even if you can sort out the locking issue, what are the
other nodes meant to do with requests whilst this is happening?
If the node that obt
Hi,
@Lee
>> Why would you want to share your cache directories?
>> I can only see negative impact for doing this.
Our IT director is a performance freak (ok, we too) and thinks that
processing a page is slower, when a web server has to manage the cache
folder on its own.
So, he wants to ge
On Nov 11, 2:49 am, Frank Stelzer <[EMAIL PROTECTED]> wrote:
> However every web server has to process its cache folders on their
> own. This is redundant work and i want to get rid of it.
>
> I see those "easy" possibilities:
> - shared folder (bottle neck, not scalable)
> - rsync every x minu
On 11 Nov, 07:49, Frank Stelzer <[EMAIL PROTECTED]> wrote:
> all of this cached stuff to MemCached (overwriting sfConfigCache), but
> i am not sure, if this would be the best solution.
>
In your factories.yml set your view_cache class to sfMemcacheCache
with the right parameters:
http://tra
Why would you want to share your cache directories?
I can only see negative impact for doing this... with each machine
having its own cache directory, you don't affect the whole cluster
when you issue a clear-cache, there's no SPOF... above all, it's less
work to set up and maintain.
On 11
