Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66780
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ellisons.org.uk from 79.170.44.47 cause and error)
Message-ID: <514F2BD2.30405@ellisons.org.uk>
Date: Sun, 24 Mar 2013 16:37:38 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: PHP internals <internals@lists.php.net>
References: <514DFAFF.4010901@lerdorf.com>
In-Reply-To: <514DFAFF.4010901@lerdorf.com>
Content-Type: multipart/alternative;
 boundary="------------090106000706050600060007"
Subject: Re: [PHP-DEV] Continuous Integration Atomic Deploys and PHP 5.5
From: Terry@ellisons.org.uk (Terry Ellison)

--------------090106000706050600060007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rasmus,
> <snip>
>
> - Request 1 starts before the deploy and loads script A, B
> - Deploy to a separate directory and the docroot symlink now points to here
> - Request 2 starts and loads A, B, C
> - Request 1 was a bit slow and gets to load C now
The issues that you raise about introducing atomic versioning in the 
script namespace do need to be addressed to avoid material service 
disruption during application version upgrade.  However, surely another 
facet of the O+ architectural also frustrates this deployment model.

My reading is that is that O+ processes each new (cache-miss) compile 
request by first sizing the memory requirements for the compiled source 
and then allocating a single brick from (one of) the SMA at its high 
water mark.  Stale cache entries are marked as corrupt and their storage 
is then allocated to wasted_shared_memory with no attempt to reuse it.  
SMA exhaustion or the % wastage exceeding a threshold ultimately 
triggers a process shutdown cascade.  This  strategy is lean and fast 
but as far as I understand this, it ultimately uses a process death 
cascade and population rebirth to implement garbage collection.

Wouldn't your non-stop models would require a more stable reuse 
architecture which recycles wasted memory stably without the death 
cascade?  Perhaps one of the Zend team could correct my inference if 
I've got it wrong again :-(

Regards
Terry

--------------090106000706050600060007--