[Glass] rest api returning large result

[Otto Behrens]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20240522/41c72a14/attachment.htm>