Re: Workaround to browser maximum connection limit ?
Mariano Martinez Peck <[email protected]>
| Newsgroups | gmane.comp.lang.smalltalk.squeak.seaside |
|---|---|
| Message-ID | <CAA+-=mXqxGQu2s9SL+WVJr_4qu3AY-4hJYK_4P8iL=3tYBysXQ@mail.gmail.com> |
On Mon, Mar 20, 2017 at 10:11 PM, Paul DeBruicker <[email protected]> wrote: > Are you using HTTP/2 in your nginx config? > https://en.wikipedia.org/wiki/HTTP/2 It both multiplexes & pipelines > requests so the browser's limits have less, if no effect. > > Yes, this is very interesting idea. Do you have such a setup working with Seaside and GemStone? I am compiling now newer version of nginx with ALPN support and correct version of SSL on CentOS7. But I am not sure what else must be done to close the loop so that to be sure HTTP2 is used everywhere. Do I need to do something on the Seaside adaptors? > > > Could also maybe adapt the functionality of the lazy-loading code that is > sometimes used for images. If the report isn't on the screen & hasn't been > scrolled to do you really need it in the DOM? > > > > > > > > Mariano Martinez Peck wrote > > Hi guys, > > > > In my app I have one scenario where we render huge reports. These reports > > could have say... 20/30 large tables as well as quite some charts and > some > > other report elements. > > > > Previously we were using a single ajax request to generate the whole > > report > > html but that was a pain because client machine would have a really large > > TTFB. So I was wasting CPU and network at client machine while waiting. > > > > What we did now is that each report element renders a title + spinning > > while and does an ajax request which, on success does a #replaceWith: > > with > > the real contents. The idea is to show the report as soon as possible and > > start replacing spinning wheels with real contents as soon as content is > > ready. That way I maximize CPU and network on client side. > > > > 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. > > > > This change was nice and improved performance. However, when I analyze > > requests, I see that I have many that are "Stalled". And yeah, on Chrome, > > they are all stalled when there is more than 6 requests to the same > > location. > > > > To conclude, it looks like i am doing what is called "Loading page > content > > with many Ajax requests" [1]. But I still don't find an easy workaround. > I > > would like to be able to use my 10 Gems over the 8 CPU cores.... > > > > Any idea? > > > > Thanks in advance, > > > > > > [1] > > http://sgdev-blog.blogspot.com.ar/2014/01/maximum- > concurrent-connection-to-same.html > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > _______________________________________________ > > seaside mailing list > > > [email protected] > > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > > -- > View this message in context: http://forum.world.st/ > Workaround-to-browser-maximum-connection-limit-tp4939444p4939450.html > Sent from the Seaside General mailing list archive at Nabble.com. > _______________________________________________ > seaside mailing list > [email protected] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Mariano http://marianopeck.wordpress.com _______________________________________________ seaside mailing list [email protected] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside