On Mon, 16 Sep 2013 09:01:02 +0200, Michael Wallner wrote:
On 10 September 2013 13:29, Michael Wallner wrote:
On 28 August 2013 08:14, Michael Wallner wrote:
On 27 August 2013 23:17, Gustavo Lopes wrote:
I think it's generally a good idea, but I have some concerns:
...
Fixed. The input
Hi all!
On 10 September 2013 13:29, Michael Wallner wrote:
> On 28 August 2013 08:14, Michael Wallner wrote:
>> On 27 August 2013 23:17, Gustavo Lopes wrote:
>
>>> I think it's generally a good idea, but I have some concerns:
> ...
> Fixed. The input stream is reusable *and* may be used JIT.
>
On 28 August 2013 08:14, Michael Wallner wrote:
> Hi Gustavo, thank you for your review!
>
> On 27 August 2013 23:17, Gustavo Lopes wrote:
>> I think it's generally a good idea, but I have some concerns:
>>
>> * The whole point of PG(enable_post_data_reading) is to be able to read the
>> input o
Hi Gustavo, thank you for your review!
On 27 August 2013 23:17, Gustavo Lopes wrote:
> On 27-08-2013 14:08, Michael Wallner wrote:
>>
>> Hi,
>>
>> I prepared a patch to replace sapi_globals' request_info post_data and
>> raw_post_data with a temp stream and remove support for
>> HTTP_RAW_POST_DAT
On 27-08-2013 14:08, Michael Wallner wrote:
Hi,
I prepared a patch to replace sapi_globals' request_info post_data and
raw_post_data with a temp stream and remove support for
HTTP_RAW_POST_DATA. [1]
PROS:
* save up to 300% on post_data_len memory (on non-form POSTs)
* a local siege (c=512/512,
Hi,
I prepared a patch to replace sapi_globals' request_info post_data and
raw_post_data with a temp stream and remove support for
HTTP_RAW_POST_DATA. [1]
PROS:
* save up to 300% on post_data_len memory (on non-form POSTs)
* a local siege (c=512/512, 2.4k form/2.2k json) showed no (negative)
perf
