On Tue, May 27, 2008 at 6:33 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > > Hi, > >>>> Certain limitations of the of google app engine >>>> (no outgoing RPC connections, you must use BigTable, no starting sys >>>> process, etc) >>>> would make it so knoboo won't work immediately on google app engine. >>>> There are other solutions out there that suit running an online code >>>> notebook >>>> much better, i.e. a cheap VPS. Nothing is totally free in all senses >>>> of the word ;) >>> >>> I installed knoboo with sympy on my VPS here: >>> >>> http://knoboo.sympy.org/ >>> >>> Anyone feel free to create an account and play with it. I.e. create a >>> new notebook and do: >> Cool! There are still several outstanding bugs that can crop up, >> but the general 'feel' is there. We are making improvements all >> the time, so hopefully we can get you to do 'svn update' again soon :) > > I reported all bugs I found so far here: > > http://groups.google.com/group/knoboo-devel/browse_thread/thread/d8858f0e0d329a8f Yes, thanks for starting this!
> >> >>> >>> In[1]: from sympy.interactive import * >>> In[2]: sin(x).series(x, 0, 5) >>> Out[2]: x - 1/6*x**3 + O(x**5) >>> >>> to get a feeling how it looks like. >>> >>> However, when 2000+ users create an account and start using it, it >>> will be as slow (actually slower) than sagenb.org. So that's not the >>> way to go. >>> >>> So how hard do you think it will be to get it running on the google app >>> server? >> Fairly hard (?). google app engine is perfect for a huge set of >> website/web applications, >> but they are some down sides. For example, if you want to have a >> database in your app, >> you have to code your app to BigTable (the google database), which >> borders on verdor lock-in IMHO. > > That's a good argument. > >> >> Also, running an online programming notebook like Knoboo has many >> needed features >> like handing system process; being able to stop, stop, interrupt these >> running process, >> and this is another thing that is fundamental in knoboo, but >> disallowed in google app engine. > > Google kills everything after 10s. That's good imho for basic playing. > >> >> Anyways, I really think that handling 2000+ notebook users is a really >> awesome >> problem that I would love to solve, but unfortunately on my servers I dont >> have >> 2000+ users yet, so trying to solve the problem of lots of users without lots >> of users would be premature optimization, and we all know what the >> root of that is :) > > sagenb.org does. How would you suggest to solve that problem? You may > argument that it's not your problem, Actually, I would love to work on this problem for Sage. Maybe sometime in the near future, when Knoboo is a bit more stable, William or Michael might let me run a Sage notebook with Knoboo on sagenb.org, but surely only after I have sufficiently shown that I might improve things. Here are some things we already have in Knoboo, for the sole purpose being a fast and scalable online code notebook: * the 'jscompile.py' script found in $KNOBOO/scripts/ . If you use this script, together with a fast static webserver (i.e. Nginx, Apache), to serve the resulting compressed js files (and all other static files under "/static") and have this static file server set "expires" headers and possibly "gzip" all content, you will see a *significant* improvement in load times, and it will take some strain off you application server (i.e. the Twisted webserver). The above methods makes a *big* difference (you will feel it immediately if you implement it), see: http://developer.yahoo.com/performance/rules.html for more details, especially the #1 rule: "Minimize HTTP Requests" I also just committed some docs starting to describe this in more detail: see $KNOBOO/docs/optimizing.txt if you update to the latest trunk. * another (excellent) optimization feature, recently added by Dorian Raymer to Knoboo, is much more intelligent 'caching' of a user "resource" tree that is associated with a user session. The same old (and not optimized) session resource code (first written by me almost 2 years ago) still exists in the Sage notebook, and could be adding an extra strain on the Sage notebook. * a scalability feature that we are continuing to work on is a robust data model using SQLAlchemy. This is already helping produce fast and intelligent data accessing queries, and as the number of features in Knoboo (settings, sharing of notebooks, etc) gets larger, we will not be bogged down by non-relational data access methods (filesystem + text files). We truly want to produce the best possible online code notebook that we can. I hope the above speaks for that, and there are more improvement to come. Thanks, Alex but nevertheless it's still a > problem. > >> >> That said, I would love to work on this problem. So I have a proposition: >> You continue to run knoboo, have lots of user some, see how it breaks >> (doesnt' scale) >> and I will work on optimizing those parts. Sound good ? > > Well, maybe it's a subjective feeling, but I think even know with no > users, knoboo.sympy.org could still be made a little faster. But ok, > the current speed is ok. When we get more users, it will get worse > though, so I'd like to know at least some strategy that you want to > use to fix the problem, because I don't know any solution besides > using more servers. And the only way (so far) that I can easily get > more servers, is Google. > > Ondrej > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sympy?hl=en -~----------~----~----~----~------~----~------~--~---
