Web pages with >10 embedded cells evaluating slowly or not at all

[Paul Masson]

Over the past few days, I've noticed that pages with greater than around 10 embedded cells evaluate much more slowly in FireFox and often fail to evaluate at all in Safari, both desktop and mobile.

Has something changed recently that would affect multiple evaluations? Or does the server simply need restarting?

[Andrey Novoseltsev]

A week ago we have updated to Sage-7.6 which means picking up new Jupyter components etc. So it is possible that some change in them results in slower behaviour. Are you taking about 10 embedded cells which are autoevaluated? Note that we have only 4 CPU cores, so if someone opens a page with 5 automatic embedded cells there is already a slow down, not to mention what happens with multiple users. So in my opinion it makes sense to use automatic evaluation sparingly and make users press a button whenever sensible. Restarting the server does not affect speed much and is sensible only when nodes are down (in which case they usually restart automatically). At the moment they are running for 3 days, and we are getting load spikes in the afternoons.

[Paul Masson]

I should have said "autoevaluated" in the first post, since that is how I've been using SageMathCell for almost a year now. I've been careful not use any individual calculations that I know will time out and try to use the fastest algorithms possible to reduce evaluation time. I haven't seen any serious problems with autoevaluation before this.

The number of CPUs can't be the direct cause, since the evaluations just queue up and come back when a CPU is available, right? I can accept that, but when the evaluations never return it's a problem.

I just retested some pages with a dozen autoevaluated cells in Chrome, FireFox and Safari on macOS. Evaluations eventually finish in the first two browsers but not in the latter. I first noticed the problem on my iPad, where pages with more than ten cells never autoevaluate.

Whatever new "feature" of Jupyter is preventing Safari from autoevaluting a certain number of cells is likely what is also slowing down other browsers.

[David Farmer]

Whenever there is a problem with one of the browsers, usually it is
Safari.

I think it is difficult/inefficient to say anything more without
seeing an actual page with these issues.

Regards,

David

> --
> You received this message because you are subscribed to the Google Groups "sage-cell" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> sage-cell+...@googlegroups.com.
> To view this discussion on the web visithttps://groups.google.com/d/msgid/sage-cell/1dbede41-f950-4e8f-9826-ef19f7a940af%40googlegroups.c
> om.
> For more options, visit https://groups.google.com/d/optout.
>
>

[Paul Masson]

Here's a couple:

A Simple Deliciously Nonlinear Equation

Closed Orbit Conditions for Power Potentials

[Paul Masson]

And now I finally looked at the JS console: it's a CORS error! This has happened in the past, I believe.

[Paul Masson]

More specifically, a CORS error that only appears for a certain number of embedded cells. This page will render in Safari with only nine embedded cells:

Visualizing the Principle of Least Action

Bizarre...

[Andrey Novoseltsev]

On Monday, 3 April 2017 19:34:14 UTC-6, Paul Masson wrote:

The number of CPUs can't be the direct cause, since the evaluations just queue up and come back when a CPU is available, right? I can accept that, but when the evaluations never return it's a problem.

Of course it is not a reason to stop working, but it is a reason to start being slow even for a single user/page. Now what happens when 10-30-100 students come to a lab and open that page at the same time...

Anyway, I am not telling you that you should stop such usage especially if it tends to work fine. If it does become a major problem then something has to be done on server side to automatically limit the rate of computations for particular users/pages instead of relying on page authors not doing something.

Regarding the current problem - what CORS error is happening? We should be good in terms of certificates, they were recently extended.

Does the problem relate in any way to how threejs is working now? I've seen NS_ERROR_FAILURE: mentioning threejs files, but didn't understand what exactly is happening.

[Paul Masson]

On Monday, April 3, 2017 at 10:36:14 PM UTC-7, Andrey Novoseltsev wrote:

On Monday, 3 April 2017 19:34:14 UTC-6, Paul Masson wrote:

The number of CPUs can't be the direct cause, since the evaluations just queue up and come back when a CPU is available, right? I can accept that, but when the evaluations never return it's a problem.

If it does become a major problem then something has to be done on server side to automatically limit the rate of computations for particular users/pages instead of relying on page authors not doing something.

I would appreciate some clarity on this statement. If you have future restrictions in mind, I would like to know what that might entail. And before you impose restrictions of any sort, you need to have explicit guidelines publicly available detailing what is and what is not going to be allowed.

If a feature is available, I would expect the service to be capable of supporting it. If autoevaluation is not going to be supported, it should be disabled completely.

[Paul Masson]

On Monday, April 3, 2017 at 10:36:14 PM UTC-7, Andrey Novoseltsev wrote:

On Monday, 3 April 2017 19:34:14 UTC-6, Paul Masson wrote:

The number of CPUs can't be the direct cause, since the evaluations just queue up and come back when a CPU is available, right? I can accept that, but when the evaluations never return it's a problem.

Regarding the current problem - what CORS error is happening? We should be good in terms of certificates, they were recently extended.

Does the problem relate in any way to how threejs is working now? I've seen NS_ERROR_FAILURE: mentioning threejs files, but didn't understand what exactly is happening.

Typical error log:

[Error] WebSocket connection to 'wss://sagecell.sagemath.org/sockjs/647/r1x1fwau/websocket?CellSessionID=83356F54EDA644CB81DBE5C03F16F1CC' failed: Failed to send WebSocket frame.

send (embedded_sagecell.js:87:19763)

send (embedded_sagecell.js:86:21881)

send (embedded_sagecell.js:95:7443)

_send (embedded_sagecell.js:98:26976)

send_shell_message (embedded_sagecell.js:98:27173)

_kernel_connected (embedded_sagecell.js:98:24858)

_ws_opened (embedded_sagecell.js:100:5534)

o (embedded_sagecell.js:84:5083)

(anonymous function) (embedded_sagecell.js:95:7366)

[Error] Origin http://analyticphysics.com is not allowed by Access-Control-Allow-Origin.

[Error] Failed to load resource: Origin http://analyticphysics.com is not allowed by Access-Control-Allow-Origin. (1280d404-2a02-4480-a2bd-b0a5c01db9ed, line 0)

[Error] XMLHttpRequest cannot load https://sagecell.sagemath.org/kernel/1280d404-2a02-4480-a2bd-b0a5c01db9ed?_=1491424080302 due to access control checks.

[Error] Origin http://analyticphysics.com is not allowed by Access-Control-Allow-Origin.

[Error] Failed to load resource: Origin http://analyticphysics.com is not allowed by Access-Control-Allow-Origin. (0422b3a2-db03-4823-9db7-fbd63c8b01a0, line 0)

[Error] XMLHttpRequest cannot load https://sagecell.sagemath.org/kernel/0422b3a2-db03-4823-9db7-fbd63c8b01a0?_=1491424080305 due to access control checks.

 

[William Stein]

On Wed, Apr 5, 2017 at 2:03 PM, Paul Masson <paulm...@comcast.net> wrote:

On Monday, April 3, 2017 at 10:36:14 PM UTC-7, Andrey Novoseltsev wrote:

On Monday, 3 April 2017 19:34:14 UTC-6, Paul Masson wrote:

The number of CPUs can't be the direct cause, since the evaluations just queue up and come back when a CPU is available, right? I can accept that, but when the evaluations never return it's a problem.

If it does become a major problem then something has to be done on server side to automatically limit the rate of computations for particular users/pages instead of relying on page authors not doing something.

[...] before you impose restrictions of any sort, you need to have explicit guidelines publicly available detailing what is and what is not going to be allowed.

If a feature is available, I would expect the service to be capable of supporting it. If autoevaluation is not going to be supported, it should be disabled completely.

With all due respect, the Sage Cell Server is a completely free service, which Andrey maintains purely voluntarily in his spare time, and it runs on cloud computing resources donated by SageMath, Inc..    If you need to ensure anything at all about the service, you should run your own server.

 -- William

 

--
You received this message because you are subscribed to the Google Groups "sage-cell" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-cell+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-cell/3f8cf47a-e37b-46ac-b1b0-ed572ef92506%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

William (http://wstein.org)

[David Farmer]

Would it be reasonable to me to make a web page with 100
automatically evaluated cells, all involving sliders?

Answer: No. At least not by any reasonable definition of "reasonable".

So where is the dividing line? Is 10 reasonable? I am thinking
it is not.

Are the readers of the page really going to stop and play with
the sliders for every example? Not if they are like the students
I am used to, but maybe you are writing for a more sophisticated
audience.

If I am going to fiddle with the slider, would it bother me to
first click a button to make the sliders active? I think not,
because the marginal effort would be small.

While writing the above I saw William''s email pointing out
the limits of what can be made available for free. I think that
fits in with the points I am making. If you want/need more than a
minimal service, then it should be available, but at a price.

Regards,

David

[William Stein]

For the record, we (SageMath, Inc.) does not offer such a service for a price at present.  Perhaps someday we will, but we do not now, and don't have any plans for doing so in the near future. 

 

Regards,

David

--
You received this message because you are subscribed to the Google Groups "sage-cell" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-cell+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-cell/alpine.LRH.2.20.1704051728350.32493%40li375-150.members.linode.com.

For more options, visit https://groups.google.com/d/optout.

--

William (http://wstein.org)

[Andrey Novoseltsev]

On Wednesday, 5 April 2017 15:03:28 UTC-6, Paul Masson wrote:

I would appreciate some clarity on this statement. If you have future restrictions in mind, I would like to know what that might entail. And before you impose restrictions of any sort, you need to have explicit guidelines publicly available detailing what is and what is not going to be allowed.

To add some numbers to William's and David's responses (which I completely support):
- Computing 1+1 via SageMathCell is drastically different from doing it in JavaScript not only because it is done on a remote server, but because it involves forking a dedicated Sage process. You don't have to wait for it, typically, because there are some waiting for you, but this forking does take noticeable time, something like 1/10 of a second. A page with 10 very easy cells thus consumes 1 second.
- Each interact requires a dedicated Sage process running to support it, which takes noticeable RAM, something like 100MB, so a page with 10 interacts consumes 1GB.
- Americas are served by a machine with 4 CPU cores and 15GB RAM, so 15 students opening a page with 10 interacts will consume all RAM.

A sensible solution to this is to increase capacity on demand via preemt instrances or containers or whatever, but a) it has to be implemented and b) the current minimal setup already costs ~$130/month. So the actual solution to overused server will be more likely to limit requests for the same user/session to something reasonable. Say allow only one cell or evaluation per second. Which should be just fine for someone who actually reads a web-page. Those who want more resources and/or stability should consider running their own servers as I have done in the past.

[Ingo Dahn]

At first I'd like to express to Andrey and Bill the high appreciation of the teachers in the NetMath network in the German land of Rhineland-Palatinate for providing and supporting SageCell as a free service. Usually it works fine and the support is fast and helpful. We understand that resources are limited. So the Virtual Campus of Rhinland-Palatinate has considered setting up its own SageCell server for the community, but found that it requires more resources than the Campus can currently afford.

I'd suggest to maintain - at a central place - a list of Known Issues/Tips and Tricks listing problems that might occur and possible workarounds.

[David Farmer]

> - Each interact requires a dedicated Sage process running to support it, which takes noticeable
> RAM, something like 100MB, so a page with 10 interacts consumes 1GB.

That explains why those 10 sage cells become inactive when I
leave the page for a while and then go back.

This suggests to me that interacts should be weighted by a factor of
a dozen or so when determining if a page has a reasonable number of
auto evaluate cells.

[Andrey Novoseltsev]

On Thursday, 6 April 2017 00:48:16 UTC-6, Ingo Dahn wrote:

At first I'd like to express to Andrey and Bill the high appreciation of the teachers in the NetMath network in the German land of Rhineland-Palatinate for providing and supporting SageCell as a free service. Usually it works fine and the support is fast and helpful. We understand that resources are limited. So the Virtual Campus of Rhinland-Palatinate has considered setting up its own SageCell server for the community, but found that it requires more resources than the Campus can currently afford.

I'd suggest to maintain - at a central place - a list of Known Issues/Tips and Tricks listing problems that might occur and possible workarounds.

We do have GitHub issues and this list, I also use a personal TODO file which has less overhead. Mostly it seems to work.

Regarding this particular issue with autoevaluation, I've added a caution to our embedding instructions:
https://github.com/sagemath/sagecell/blob/master/doc/embedding.rst#automatic-evaluation