[Glass] Workaround to browser maximum connection limit ?

[Paul Baumann via Glass]

Increase shared page cache size. Use ssd drives to cut seek time. Cluster
data to pages so more data that you know will be needed occupies fewer
pages. Cluster static data to pages.

Distributing work into separate gems is a great start, but it sounds like
you are data access limited and so now more gems now wait for data. Even if
you've done all mentioned above, there is still a cost of moving data from
spc to temp obj cache of each of those gems. Because of that cost, you can
achieve incredible performance (like 45 seconds cut to milliseconds) by
using a work queue serviced by a single gem that has warm caches because it
does the same kind of work (same data) repeatedly.

Code tuning techniques would also have incredible gains, but I'd have to
tune that code myself because there are just too many tricks to list.

Paul Baumann


On Mar 21, 2017 6:52 AM, "Otto Behrens via Glass" <
glass at lists.gemtalksystems.com> wrote:

> Hi,
>
> We use a background process to generate big reports. This is a topaz
> session that logs in on its own (nothing to do with seaside as such)
> and picks up the report to generate. It commits the report results in
> GemStone and the UI aborts to pick up the progress and results.
>
> There is not much sophistication here on the UI because we do not
> display results until the report is done (only progress, which shows a
> simple line of relative progress). We could display results I suppose,
> but then you can sort them yet, and things like that.
>
> Maybe you can spawn multiple background process jobs that each take a
> bit of the work and commit the results as they do it. I suppose you've
> already looked at the concurrency issues to do something like that?
>
> If the rendering is heavy weight, you could perhaps generate some of
> your html in the results of the report in stead of some report result
> object.
>
> Cheers
> Otto
>
> On Tue, Mar 21, 2017 at 12:41 PM, Mariano Martinez Peck via Glass
> <glass at lists.gemtalksystems.com> wrote:
> >
> >
> > On Tue, Mar 21, 2017 at 3:20 AM, Johan Brichau via Glass
> > <glass at lists.gemtalksystems.com> wrote:
> >>
> >> Hey Mariano,
> >>
> >> On 21 Mar 2017, at 01:01, Mariano Martinez Peck via Glass
> >> <glass at lists.gemtalksystems.com> wrote:
> >>
> >> The second thing is that making this on AJAX calls, that would end up on
> >> different Gems on my GemStone which was very performant. I have 10
> Seaside
> >> gems on a 8 cores CPU so all those AJAX request were load balanced via
> nginx
> >> over the 10 seaside gems, which on the other hand were split across all
> >> cores. Previously, with a single request, only one Gem took care and
> hence
> >> only one CPU core was used.
> >>
> >>
> >> Quick question: does this mean these requests are "Seaside
> session-less”?
> >
> >
> > Uhhhh ... great question. I think they are indeed "quite session-less"
> ...
> > but.. is there an easy way to check this? Of course, something easier
> than
> > following code to see if I access session. Maybe simply putting some
> logging
> > in session accessing code ?
> >
> >
> >>
> >> Because processing seaside requests in parallel is not possible (the
> >> session object is locked).
> >
> >
> >
> > Yes, maybe this is the case for my scenario. But at least, the report can
> > still be rendered ASAP rather than having to wait until fully done, even
> if
> > all requests would not go parelel even if they are on multiple gems.
> > But...honestly, I would love they go paralel....  do you have some
> reference
> > or link explaining the locking? I remember some old Dale posts as well as
> > some code but any hint would be appreciated.
> > Have someone improved or make any progress on this locking / multi-gem
> > issue?
> >
> > Thanks in advance!
> >
> >>
> >>
> >> Johan
> >>
> >> _______________________________________________
> >> Glass mailing list
> >> Glass at lists.gemtalksystems.com
> >> http://lists.gemtalksystems.com/mailman/listinfo/glass
> >>
> >
> >
> >
> > --
> > Mariano
> > http://marianopeck.wordpress.com
> >
> > _______________________________________________
> > Glass mailing list
> > Glass at lists.gemtalksystems.com
> > http://lists.gemtalksystems.com/mailman/listinfo/glass
> >
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170321/37c7e66f/attachment.html>