Slowness of www.sagenb.org
Jeroen Demeyer
slow that it is essentially unusable. Unfortunately, it is also very
bad advertising for Sage, because for many people their first contact
with Sage might be www.sagenb.org. I've actually been directing my
students to alpha.sagenb.org, but of course that is not a good solution.
Somebody who knows the notebook might be able to understand why it is so
slow. The problem is not the machine, because the load is not high and
other notebooks on the same server are much faster. So it is truly an
implementation problem.
Jeroen.
William Stein
Hi,
To solve this slowness problem will require probably at least a month
of focused work to completely reimplement basically from scratch the
storage and server architecture of the notebook in a much more
scalable way. Nobody is working on this, though if nobody else does
it, then I'll do it sometime in the next year. So the options are:
(1) I simply totally disable www.sagenb.org,
(2) I leave things as they are.
(3) Somebody reimplements the notebook in a way that scales.
Writing scalable web applications is not easy. It's possible, but it
requires much different techniques than are used for the current
notebook, e.g., one must have multiple server instances, and all data
has to be stored in a database that can accessed from any server, etc.
-- William
>
> Jeroen.
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
Jason Grout
> On Sat, Nov 20, 2010 at 12:07 PM, Jeroen Demeyer<jdem...@cage.ugent.be> wrote:
>> I think somebody should seriously look into www.sagenb.org. It is so
>> slow that it is essentially unusable. Unfortunately, it is also very
>> bad advertising for Sage, because for many people their first contact
>> with Sage might be www.sagenb.org. I've actually been directing my
>> students to alpha.sagenb.org, but of course that is not a good solution.
>>
>> Somebody who knows the notebook might be able to understand why it is so
>> slow. The problem is not the machine, because the load is not high and
>> other notebooks on the same server are much faster. So it is truly an
>> implementation problem.
>
> Hi,
>
> To solve this slowness problem will require probably at least a month
> of focused work to completely reimplement basically from scratch the
> storage and server architecture of the notebook in a much more
> scalable way. Nobody is working on this, though if nobody else does
> it, then I'll do it sometime in the next year. So the options are:
>
> (1) I simply totally disable www.sagenb.org,
> (2) I leave things as they are.
> (3) Somebody reimplements the notebook in a way that scales.
>
> Writing scalable web applications is not easy. It's possible, but it
> requires much different techniques than are used for the current
> notebook, e.g., one must have multiple server instances, and all data
> has to be stored in a database that can accessed from any server, etc.
>
But IIRC, we aren't sure exactly where the bottlenecks even are right
now. You've mentioned before that the first step is someone developing
some test suites that will hammer a server and profile the server to see
where the bottlenecks are. Has anyone done this?
Thanks,
Jason
Tom Boothby
> To solve this slowness problem will require probably at least a month
> of focused work to completely reimplement basically from scratch the
> storage and server architecture of the notebook in a much more
> scalable way. Nobody is working on this, though if nobody else does
> it, then I'll do it sometime in the next year. So the options are:
We've got a bug days coming up next year (January), and a man-month
between you, me, Alex Leon, and Mike Hansen (provided they're willing
to play along) -- plus whoever else is willing to join.
Tasks:
(1) Write testing code to identify bottlenecks, and generally
improve robustness.
(2) Convert all notebook data structures to a database architecture.
(3) rewrite twist.py to use flask.
(4) Use mod_wsgi and apache to make it scale massively.
Jason Grout
(pre-3): evaluate whether we want to change from twisted to something
else. For example, it seems like flask will not support websockets for
a long time, but Alex has some really cool demos/ideas for applications
of websockets in the notebook.
> (4) Use mod_wsgi and apache to make it scale massively.
>
(4b) package nginx or lighttpd or something with Sage so that Sage still
comes with a webserver?
Thanks,
Jason
Jeroen Demeyer
> (1) I simply totally disable www.sagenb.org,
Maybe keep www.sagenb.org as it is but remove the link from the Sage
front page?
Jeroen Demeyer
> On Sat, Nov 20, 2010 at 1:45 PM, William Stein <wst...@gmail.com> wrote:
>> To solve this slowness problem will require probably at least a month
>> of focused work to completely reimplement basically from scratch the
>> storage and server architecture of the notebook in a much more
>> scalable way. Nobody is working on this, though if nobody else does
>> it, then I'll do it sometime in the next year. So the options are:
>
> We've got a bug days coming up next year (January), and a man-month
> between you, me, Alex Leon, and Mike Hansen (provided they're willing
> to play along) -- plus whoever else is willing to join.
I'm not sure whether there is much I can do, but I'll gladly join if
there is something I can do.
Jeroen.
Robert Bradshaw
>> I think somebody should seriously look into www.sagenb.org. It is so
>> slow that it is essentially unusable. Unfortunately, it is also very
>> bad advertising for Sage, because for many people their first contact
>> with Sage might be www.sagenb.org. I've actually been directing my
>> students to alpha.sagenb.org, but of course that is not a good solution.
>>
>> Somebody who knows the notebook might be able to understand why it is so
>> slow. The problem is not the machine, because the load is not high and
>> other notebooks on the same server are much faster. So it is truly an
>> implementation problem.
>
> Hi,
>
> To solve this slowness problem will require probably at least a month
> of focused work to completely reimplement basically from scratch the
> storage and server architecture of the notebook in a much more
> scalable way. Nobody is working on this, though if nobody else does
> it, then I'll do it sometime in the next year. So the options are:
>
> (1) I simply totally disable www.sagenb.org,
> (2) I leave things as they are.
> (3) Somebody reimplements the notebook in a way that scales.
A half-way solution is to run multiple notebooks servers, partitioning
the users based on their username (perhaps using a different
front-end/proxy). I agree though that the notebook needs to seriously
be fixed, probably by stripping out twisted (maybe replacing with
flaks, maybe not). Fortunately, most of the javascript would probably
be relatively unaffected by such a rewite. I don't think there are any
major technical obstructions, it's mostly a matter of the poeple with
the know-how finding the time.
- Robert
Tom Boothby
<jason...@creativetrax.com> wrote:
> On 11/20/10 4:05 PM, Tom Boothby wrote:
>>
>> On Sat, Nov 20, 2010 at 1:45 PM, William Stein<wst...@gmail.com> wrote:
>>>
>>> To solve this slowness problem will require probably at least a month
>>> of focused work to completely reimplement basically from scratch the
>>> storage and server architecture of the notebook in a much more
>>> scalable way. Nobody is working on this, though if nobody else does
>>> it, then I'll do it sometime in the next year. So the options are:
>>
>> We've got a bug days coming up next year (January), and a man-month
>> between you, me, Alex Leon, and Mike Hansen (provided they're willing
>> to play along) -- plus whoever else is willing to join.
>>
>> Tasks:
>>
>> (1) Write testing code to identify bottlenecks, and generally
>> improve robustness.
>> (2) Convert all notebook data structures to a database architecture.
>> (3) rewrite twist.py to use flask.
>
> (pre-3): evaluate whether we want to change from twisted to something else.
> For example, it seems like flask will not support websockets for a long
> time, but Alex has some really cool demos/ideas for applications of
> websockets in the notebook.
Alex had some really exciting demos, and last I saw, things were
pretty far from being ready for prime time. I'm not sure that these
things have anything to do with eachother, though. My preference is
to keep the single-user functionality more or less the same, and hook
a new robust server structure into place for sagenb.org and other
large multiuser environments.
>
>> (4) Use mod_wsgi and apache to make it scale massively.
>>
>
> (4b) package nginx or lighttpd or something with Sage so that Sage still
> comes with a webserver?
This is a must -- otherwise, we lose the ability to use the notebook
as the GUI. Nobody plans for that to happen.
I've put up a page on the wiki about this project. Any interested
parties are strongly encouraged to get their input down there.
http://wiki.sagemath.org/Notebook_scalability
>
> Thanks,
>
> Jason
Alex Leone
my ideas to that page when I get a chance. Hopefully we can nail down
a general structure before the bug days in January.
> I've put up a page on the wiki about this project. Any interested
> parties are strongly encouraged to get their input down there.
>
> http://wiki.sagemath.org/Notebook_scalability
- Alex
Dr David Kirkby
> I think somebody should seriously look intowww.sagenb.org. It is so
> bad advertising for Sage, because for many people their first contact
>
> Somebody who knows the notebook might be able to understand why it is so
> slow. The problem is not the machine, because the load is not high and
> other notebooks on the same server are much faster. So it is truly an
> implementation problem.
>
> Jeroen.
suggested making Sage depend on Apache, I was told that it did not
even make sense to suggest. it:
http://groups.google.com/group/sage-devel/msg/e5fce9e4ef53dedc
One option, which might reduce the load, is to offer a command line
interface on the web site too. Some users might prefer a CLI to a GUI
- I know I often do.
Dave
tuxiano
I'm not an administrator of my office PC so I can't install SAGE and
my company filters connections not on port 80 or 8080 so www.sagenb.org
is the only Sage implementation that I can use. Perhaps other people
are in my condition.
Thanks
Tiziano
On Nov 21, 3:18 am, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> On 2010-11-20 22:45, William Stein wrote:
>
> > (1) I simply totally disablewww.sagenb.org,
>
> front page?
William Stein
> Please, don't disable www.sagenb.org
> I'm not an administrator of my office PC so I can't install SAGE and
> my company filters connections not on port 80 or 8080 so www.sagenb.org
> is the only Sage implementation that I can use.
There is also http://demo.sagenb.org and http//demo2.sagenb.org.
William
> Perhaps other people
> are in my condition.
>
> Thanks
>
> Tiziano
>
> On Nov 21, 3:18 am, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
>> On 2010-11-20 22:45, William Stein wrote:
>>
>> > (1) I simply totally disablewww.sagenb.org,
>>
>> Maybe keepwww.sagenb.orgas it is but remove the link from the Sage
>> front page?
>
Eviatar
Notebook is slower than command-line, specifically NumPy operations.
On Nov 21, 12:30 pm, William Stein <wst...@gmail.com> wrote:
> On Sun, Nov 21, 2010 at 5:23 AM, tuxiano <tuxi...@gmail.com> wrote:
> > Please, don't disablewww.sagenb.org
> > my company filters connections not on port 80 or 8080 so www.sagenb.org
> > is the only Sage implementation that I can use.
>
> William
>
>
>
>
>
>
>
>
>
> > Perhaps other people
> > are in my condition.
>
> > Thanks
>
> > Tiziano
>
> > On Nov 21, 3:18 am, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> >> On 2010-11-20 22:45, William Stein wrote:
>
> >> > (1) I simply totally disablewww.sagenb.org,
>
>
> > --
> > To post to this group, send an email to sage-...@googlegroups.com
> > To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
William Stein
> I don't know if this is related, but I've noticed even the local Sage
> Notebook is slower than command-line, specifically NumPy operations.
It makes absolutely no sense that that could happen. Please give a
specific example.
-- William
> For more options, visit this group at http://groups.google.com/group/sage-devel
William Stein
> On Sun, Nov 21, 2010 at 1:33 PM, Eviatar <eviat...@gmail.com> wrote:
>> I don't know if this is related, but I've noticed even the local Sage
>> Notebook is slower than command-line, specifically NumPy operations.
>
> It makes absolutely no sense that that could happen. Please give a
> specific example.
More precisely, please define exactly what you mean by "slower". Do you mean:
(1) it "feels" slower,
(2) the time from press shift-enter until you see output is longer, or
(3) When you use "time a_specific_command(...)", it takes longer.
What I don't think could happen is (3). Obviously (1) or (2) could
happen, due to the client server architecture.
However, this would have absolutely nothing to do with numpy, and you
would notice the same slowdown with
any code in Sage.
William
Eviatar
example:
On Sage Notebook (locally):
"from numpy import zeros
from random import randint
def cellular(rule, N, initial='Single-cell'):
'''Yields a matrix showing the evolution of a Wolfram's cellular
automaton
rule: determines how a cell's value is updated, depending on
its neighbors
N: number of iterations
initial: starting condition; can be either single-cell or a
random binary row
'''
M=zeros( (N,2*N+2), dtype=int)
if initial=='Single-cell':
M[0,N]=1
else:
M[0]=[randint(0,1) for a in range(0,2*N+2)]
for j in range(1,N):
for k in range(0,2*N):
l = 4*M[j-1,k-1] + 2*M[j-1,k] + M[j-1,k+1]
M[j,k]=rule[ l ]
return M[:,:-1]
def num2rule(number):
if not 0 <= number <= 255:
raise Exception('Invalid rule number')
binary_digits = number.digits(base=2)
return binary_digits + [0]*(8-len(binary_digits))
import time
initial=time.clock()
m=cellular(num2rule(90), 100)
print time.clock()-initial"
In Notebook, this returns 5.06. In command-line the same code produces
an output of 0.11 seconds. The code is also here:
http://wiki.sagemath.org/interact/misc#CellularAutomata.
I know this isn't the best way to time execution, but the difference
is significant enough that it shouldn't matter.
On Nov 21, 2:27 pm, William Stein <wst...@gmail.com> wrote:
> On Sun, Nov 21, 2010 at 2:25 PM, William Stein <wst...@gmail.com> wrote:
>
> >>> > --
> >>> > To post to this group, send an email to sage-...@googlegroups.com
> >>> > To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> >>> > For more options, visit this group athttp://groups.google.com/group/sage-devel
> >>> > URL:http://www.sagemath.org
>
> >>> --
> >>> William Stein
> >>> Professor of Mathematics
> >>> University of Washingtonhttp://wstein.org
>
> >> --
> >> To post to this group, send an email to sage-...@googlegroups.com
> >> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> >> For more options, visit this group athttp://groups.google.com/group/sage-devel
> >> URL:http://www.sagemath.org
>
> > --
> > William Stein
> > Professor of Mathematics
William Stein
This has absolutely nothing to do with the notebook. You can't have
this happen if you are actually running the same code. I just tried
this and I get about 5 seconds both in the notebook and on the command
line. *Precisely* how are you running the code on the command line?
You can't just paste it in, since it isn't formatted for that. So
maybe you are saving it to a .py file, then using load or import? If
you do that, then you'll get much, much different times, because of
the Sage preparser, which is not being used on .py files.
Try the following in the notebook:
(1) Make a cell with exactly this content, and evaluate it:
%python
(2) Make another cell with this content and evaluate it:
import time
initial=time.clock()
m=cellular(num2rule(90), 100)
print time.clock()-initial
You'll get a fast timing.
It would be good for you to learn about the Sage preparser more, since
in some cases turning it off (or at least explicitly not using it) can
lead to better performance, especially for numerical code. Turning it
off can also lead to much slower (or wrong) code, but usually in the
context of symbolic (not numerical) computation.
William
> For more options, visit this group at http://groups.google.com/group/sage-devel
Eviatar
comments.
On Nov 21, 6:50 pm, William Stein <wst...@gmail.com> wrote:
William Stein
> Ah, the culprit was the preparser. Thank you; disregard my previous
> comments.
No problem. I bet somebody else will find this message in the
archives later or via a search, and it will help them out.
Also, your example is a good handy example to illustrate the
potentially hugely negative speed consequences of the
preparser on numerical code. So thanks!
William
> For more options, visit this group at http://groups.google.com/group/sage-devel
Dr. David Kirkby
> Please, don't disable www.sagenb.org
> I'm not an administrator of my office PC so I can't install SAGE and
> my company filters connections not on port 80 or 8080 so www.sagenb.org
> is the only Sage implementation that I can use. Perhaps other people
> are in my condition.
Do they filter port 8000? That is not an uncommon port for HTTP traffic?
http://t2nb.math.washington.edu:8000/
I used to run an SSH server on port 443 when my company filtered port 22!!
If your company does filter 8080. is possible I could make
http://t2nb.math.washington.edu:8000/
also work as
http://t2nb.math.washington.edu:8080/
> Thanks
>
> Tiziano
> On Nov 21, 3:18 am, Jeroen Demeyer<jdeme...@cage.ugent.be> wrote:
> On 2010-11-20 22:45, William Stein wrote:
>
>> (1) I simply totally disablewww.sagenb.org,
>
> Maybe keepwww.sagenb.orgas it is but remove the link from the Sage
> front page?
Dave
William Stein
> I've been thinking about architecture for a while. I'll copy some of
> my ideas to that page when I get a chance. Hopefully we can nail down
> a general structure before the bug days in January.
That would be good. It's important that things be well thought
through and truly implementable in the time we have -- it's pointless
to try to implement something just to run out of time.
Here's a data point, by the way. Right now there are 42346 accounts
on sagenb.org. If the damn site were made to scale properly, I bet
we could easily hit 100,000 accounts during 2011. The logfile,
which records when people actually do stuff, has about 1 billion
entries since Sept 1. It's almost a 1GB file, but if somebody wants
to study it, email me and let me know, or if you have an account on
boxen.math.washington.edu, look in /sagenb/sagenb/logs/.
Another good thing to do as part of this sprint would be to greatly
improve the logging ability of the notebook server. The logs could,
of course, get stored to a database, for increased flexibility and
ease of querying. They could be studied from a web admin page.
Probably we can copy ideas from Django or something.
>
>> I've put up a page on the wiki about this project. Any interested
>> parties are strongly encouraged to get their input down there.
>>
>> http://wiki.sagemath.org/Notebook_scalability
>
> - Alex
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
Dan Drake
> Another good thing to do as part of this sprint would be to greatly
> improve the logging ability of the notebook server. The logs could,
> of course, get stored to a database, for increased flexibility and
> ease of querying. They could be studied from a web admin page.
> Probably we can copy ideas from Django or something.
Yes! I would love that. Right now, I have little idea how much the
public KAIST servers are being used -- I can see logins, but I'd like
more information. This would be helpful to me, and also make it easier
to convince administrators / grant funders to drop money on servers.
Dan
--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------
Tom Boothby
>
> Another good thing to do as part of this sprint would be to greatly
> improve the logging ability of the notebook server. The logs could,
> of course, get stored to a database, for increased flexibility and
> ease of querying. They could be studied from a web admin page.
> Probably we can copy ideas from Django or something.
On 2010-11-20 23:33:22, William Stein wrote on the wiki:
>
> We are not going to shoot too high with this project. In particular,
> our goals do *not* include adding new authentication systems or
> making it easy to organize worksheets into folders, etc. We just
> want to solve exactly one problem: make the notebook scalable.
I agree with this sentiment more than I want to see logging.