[Glass] rest api returning large result

[Richard Sargent]

One of our clients uses session stats to count things like retries. Might
be a good idea to incorporate into the Seaside GemStone version.

On Tue, May 21, 2024, 23:07 Otto Behrens via Glass <
glass at lists.gemtalksystems.com> wrote:

> I usually see this in logs when we hit retries, not 100% sure, will look
> out for it, thanks.
>
> On Tue, 21 May 2024, 02:51 Paul DeBruicker via Glass, <
> glass at lists.gemtalksystems.com> wrote:
>
>> Oh also - I wonder if you're hitting the request timeout so retry logic
>> the Seaside/GemStone handlers have.  It would take no time in a profiler
>> but cause the response generation to happen up to 10 times.
>>
>>
>>
>>
>> On 5/20/24 23:46, Paul DeBruicker wrote:
>> > Have you tried the WAGsZincStreamingServerAdaptor or WAStreamedResponse
>> > classes?
>> >
>> > In the WAGsZincStreamingServerAdaptor you'd need to override the
>> > #responseTo: method to use the WAStreamedResponse explicitly to get rid
>> > of all adaptor buffering.  *I think*
>> >
>> >
>> > Not sure that it would help but they're there and when I was messing
>> > with this https://github.com/SeasideSt/Seaside/pull/1319 I think they
>> > were working OK.
>> >
>> >
>> >
>> > On 5/20/24 17:08, Otto Behrens via Glass wrote:
>> >>     Okay, I’ll give that a try and see what I can get when using the
>> >>     Zinc adaptor in GemStone…
>> >>
>> >>
>> >> Thanks
>> >>
>> >>     Btw, if you have the file on disk, consider using X-Sendfile
>> >>     protocol to nginx.
>> >>     Something like this, where ‘document url’ is the url where it is
>> >>     reachable through nginx:
>> >>
>> >>
>> >> Yes, we use this extensively. We serve pdf documents and things like
>> >> that. The rest API data can possibly also be written to a file. But
>> >> not for all the api endpoints, maybe for this specific one that's
>> >> giving us trouble. But that surely just bypasses the issue?
>> >>
>> >>     self requestContext
>> >>     respond: [ :response |
>> >>     response headerAt: 'X-Accel-Redirect' put: document url ]
>> >>
>> >>>         I’m using FastCGI in production, and serving large json files
>> >>>         as well. Did not see this performance issue pop up though.
>> >>>
>> >>>
>> >>>     O dear, we did use FastCGI many moons ago and ended up reverting
>> >>>     to an HTTP proxy. It was a bit easier to work with as HTTP is more
>> >>>     readable, but I just remember it was a bit of a battle.
>> >>
>> >>     I would not recommend it anymore in the sense that the protocol
>> >>     itself is outdated and prohibits things like websockets.
>> >>     But I mentioned it to say that the performance issue might very
>> well
>> >>     be in the Zinc Adaptor for GemStone.
>> >>     _______________________________________________
>> >>     Glass mailing list
>> >>     Glass at lists.gemtalksystems.com
>> >> <mailto:Glass at lists.gemtalksystems.com>
>> >>     https://lists.gemtalksystems.com/mailman/listinfo/glass
>> >>     <https://lists.gemtalksystems.com/mailman/listinfo/glass>
>> >>
>> >>
>> >> _______________________________________________
>> >> Glass mailing list
>> >> Glass at lists.gemtalksystems.com
>> >> https://lists.gemtalksystems.com/mailman/listinfo/glass
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> https://lists.gemtalksystems.com/mailman/listinfo/glass
>>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> https://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20240521/7aab8913/attachment-0001.htm>