Differences between revisions 11 and 32 (spanning 21 versions)
Revision 11 as of 2011-01-07 21:05:46
Size: 2744
Editor: was
Comment:
Revision 32 as of 2017-03-22 01:25:40
Size: 5089
Editor: mrennekamp
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from Notebook scalability
Line 3: Line 4:
Google Docs Scratchpad: [[https://docs.google.com/document/d/19R8AEc-l_MytmOduyPpsTxcXk_9cwnStOCrZuFTFgLs/edit?hl=en|public view]]. The notebook was written with the intent of being a local GUI, and as a side-effect of taking advantage of the browser, it's usable over the net. But the performance of sagenb.org is ''terrible'' since there are around 40,000 users, so we need to make the server much more scalable and robust overall. The plan is currently to tackle this during [[days27|Sage Days 27]].
Line 5: Line 6:
The notebook was written with the intent of being a local GUI, and as a side-effect of taking advantage of the browser, it's usable over the net. But the performance of sagenb.org is ''terrible'' since there are around 40,000 users, so we need to make the server much more scalable and robust overall. The plan is currently to tackle this during [[days27|Sage Days 27]]. == Two main projects ==

  * Porting the notebook over to use Flask on top of a Twisted web server

  * Redesigning the entire communication architecture to be database-centric.
     * [[Notebook design|Notebook 0.9 basic design]]
     * [[/walkthrough|What happens when some code is evaluated in our new model]]
     * The [[DrakeSageGroup]] has started extending the [[http://code.google.com/p/simple-python-db-compute|simple compute server]] to be a single-cell notebook.



== Scratch documents ==


  * [[https://docs.google.com/document/d/19R8AEc-l_MytmOduyPpsTxcXk_9cwnStOCrZuFTFgLs/edit?hl=en|Google Docs Scratchpad]] to keep track of tasks

  * [[/worksheet|Idea for how to rewrite worksheet.py in new flask code.]]

  * [[/Database calls|Working documentation on JSON protocol and database calls]]

== Google Code Repositories ==

 
  * [[http://code.google.com/p/simple-python-db-compute/|A simple Python compute server using flask and a database]]
  * [[http://code.google.com/p/sage-device/|William Stein's sage-device Branch at Google Code]]
  * [[http://code.google.com/r/mhansen-flask/|Mike Hansen's Flask Branch]]
  * [[http://code.google.com/r/wstein-sd27/source/browse|William Stein's Sage Days 27 Notebook Branch]]
  * [[https://github.com/acleone/sageserver|Alex Leone's Github repo]]
  * [[http://code.google.com/r/rkirov-flask/|Rado's clone of Mike's repo; has openid login available]]

== Technologies ==

  * http://projects.unbit.it/uwsgi/ -- micro wsgi
Line 11: Line 44:
 1. Rewrite twist.py to use [[http://flask.pocoo.org/ flask]]. The notebook will then depend on Flask and no longer use Twisted. The main advantage to using flask is the excellent support for mod_wsgi.  1. Rewrite twist.py to use [[http://flask.pocoo.org/|flask]]. The notebook will then depend on Flask and no longer use Twisted. The main advantage to using flask is the excellent support for mod_wsgi.
Line 21: Line 54:
 * In order to limit connection bandwidth, packet loss, etc. on OSX and FreeBSD, use ipfw. On Linux, apparently you can use netem (search for netem or tc). To limit any connection to 128Kbit/s with a packet loss rate of 10%, (and a queue of 50Kbytes)
{{{
sudo ipfw add pipe 1 ip from any to any
sudo ipfw pipe 1 config bw 128Kbit/s queue 50Kbytes plr 0.1
}}}

If you make the bandwidth smaller, then make the queue smaller. For example, 64Kbit/s might use 10Kbytes queue.
Line 28: Line 68:
 * Radoslav Kirov
Line 34: Line 75:


= TODO =
 * flask fully in
   * debug output <- add app.debug = True in base.py
   * run doctest <- done
   * /src broken <- workaround found
   * test SSL <- notebook(secure=True) works fine
   * run selenium test suite
 * Device object (querying a db)
   * 0mq device worker pool
 * database
   * data model and document
   * implement
      * JSON messages
      * flask
      * database code

Preamble

The notebook was written with the intent of being a local GUI, and as a side-effect of taking advantage of the browser, it's usable over the net. But the performance of sagenb.org is terrible since there are around 40,000 users, so we need to make the server much more scalable and robust overall. The plan is currently to tackle this during Sage Days 27.

Two main projects

Scratch documents

Google Code Repositories

Technologies

Tasks

  1. Write testing code to identify bottlenecks, and generally improve robustness.
  2. Convert notebook data structures to a database architecture to allow for concurrent scalable access to a centralized data store by different processes.
  3. Rewrite twist.py to use flask. The notebook will then depend on Flask and no longer use Twisted. The main advantage to using flask is the excellent support for mod_wsgi.

  4. Use mod_wsgi and Apache (say) to make the server scale massively.

Notes

  • Be aware of the sage-devel discussion.

  • It is OK if the "highly scalable notebook server" has dependencies that the usual single (or small group) server doesn't have. E.g., depending on Apache and a database (like MongoDB) would be just fine, even though neither will be included in Sage.
  • It is, of course, important that the notebook still have a zero configuration mode, where it works fine for a small number of users, but without any complicated dependencies.
  • 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. This is of course by far the biggest bug with the Sage notebook, and it is only an issue because the notebook is used so heavily. That said, it will be useful to think through how to implement everything on the wishlist before deciding on how to implement scalability, so it is easier to implement the other features later.
  • A proposal for a scalable server: google docs link and discussion

  • In order to limit connection bandwidth, packet loss, etc. on OSX and FreeBSD, use ipfw. On Linux, apparently you can use netem (search for netem or tc). To limit any connection to 128Kbit/s with a packet loss rate of 10%, (and a queue of 50Kbytes)

sudo  ipfw add pipe 1 ip from any to any
sudo ipfw pipe 1 config bw 128Kbit/s queue 50Kbytes plr 0.1

If you make the bandwidth smaller, then make the queue smaller. For example, 64Kbit/s might use 10Kbytes queue.

People

  • Tom Boothby
  • Robert Bradshaw
  • Jason Grout
  • Mike Hansen
  • Radoslav Kirov
  • Alex Leone
  • William Stein

Motivation

http://xkcd.com/844/

TODO

  • flask fully in
    • debug output <- add app.debug = True in base.py

    • run doctest <- done

    • /src broken <- workaround found

    • test SSL <- notebook(secure=True) works fine

    • run selenium test suite
  • Device object (querying a db)
    • 0mq device worker pool
  • database
    • data model and document
    • implement
      • JSON messages
      • flask
      • database code