Low performance of TextResponse and another related responses about laminas-diactoros HOT 11 OPEN

@codercms are you always experiencing that low performance or it depends on the text length? Does anything change if /maxmemory:NN gets added to php://temp? The filesystem should only be used when the text is big (default limit is 2Mb).

from laminas-diactoros.

my suggestion is to implement pure RAM string stream.

Overall agree, php://memory could suffice here, but we also are not sure if the provided string|StreamInterface will fit in memory, hence why a more conservative php://temp was used here.

I suggest sending a patch, and then we discuss the implications there: it is also acceptable to tell end-users that TextResponse is not intended for large payloads (which is in fact the original design anyway)

from laminas-diactoros.

@lcobucci there is two cases:

1. I'm experiencing low performance because TextResponse doing excess allocation of PHP native stream (allocation time + string copying time)
2. With large text length performance difference is even more

Patched TextReponse:

$size = 10 * 1024 * 1024;
$body = new Stream("php://temp/maxmemory:{$size}", 'wb+');

It is still slower than approach without PHP native stream allocation.
320 RPS without native PHP stream
260 RPS with native PHP stream

from laminas-diactoros.

@Ocramius I guess this patch will not affect end users, because php native stream is only allocated when string was passed to the constructor - this means that the memory for response is already allocated.

from laminas-diactoros.

Looking back at this, I think that for text, we can use php://memory, and let consumers with large text/plain payloads implement their own streamed response perhaps?

Unsure if this should be considered a BC break.

from laminas-diactoros.

Similar for html, which is the more common response object.

from laminas-diactoros.

@Ocramius I think there is one more approach (in two different ways):

1. Create a “fake” stream object that is just simulating stream behavior (under the hood its just a string wrapper which implements StreamInterface) - end user will have to create stream object
2. Create a true plain string response which will create a “fake” stream object under the hood - no additional actions for end user

from laminas-diactoros.

I didn't really understand the difference between those suggested approaches 🤔

from laminas-diactoros.

@Ocramius actually its only one approach which can be implemented in two manners

from laminas-diactoros.

But basically, if I understand it correctly, avoiding usage of a stream at all, and having a string variable instead (since html/text responses are generally well within the memory limits)

from laminas-diactoros.

@Ocramius yes it is. The performance problem occurs when the Response object allocates stream for string (I mean PHP stream), but actually there is no need to allocate memory one more time.

from laminas-diactoros.