Not signed in (Sign In)

Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories accessible adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry beauty bundles calculus categories category category-theory chern-weil-theory cohesion cohesive-homotopy-theory cohesive-homotopy-type-theory cohomology colimits combinatorics comma complex-geometry computable-mathematics computer-science constructive constructive-mathematics cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry differential-topology digraphs duality education elliptic-cohomology enriched fibration finite foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry goodwillie-calculus graph graphs gravity grothendieck group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration-theory k-theory lie-theory limit limits linear linear-algebra locale localization logic mathematics measure-theory modal-logic model model-category-theory monad monoidal monoidal-category-theory morphism motives motivic-cohomology newpage noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf simplicial space spin-geometry stable-homotopy-theory stack string string-theory subobject superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topological topology topos topos-theory type type-theory universal variational-calculus

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome to nForum
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).
    • CommentRowNumber1.
    • CommentAuthorRichard Williamson
    • CommentTimeMar 12th 2018
    • (edited Mar 12th 2018)

    A propos of the problems we continue to see with very large pages, as described most recently today here, and as promised in that thread, I have tried to make some kind of example to illustrate how the nLab would benefit from having a ’frontend’ that is more or less static (just serves HTML/CSS/Javascript, without any server-side programming or database layer).

    You can see an example at https://ncatlab.org/experimental-frontend/18645.html. The key point is that this page loads more or less immediately (MathJax takes a while to run on it afterwards, but ignore that for the moment). On the nLab currently, this page takes a long time to appear, and this may be behind the problems we saw earlier today (and in any case, is clearly highly undesirable).

    So what does the example do? Well, it is just a tiny (codewise) server (20 lines, to be precise), written in Go, which serves html pages to be found on the nLab server (exactly those which are copied to the nlab-content-html git repository), using the same CSS as the nLab. These html pages represent the ’fully generated’ nLab page, i.e. the Markdown has been parsed, links have been created, etc.

    The purpose of the example is to illustrate a few points:

    1) There is something terribly slow in Instiki’s page rendering. I have not isolated exactly where it is slow, but there is quite a bit of stuff going on before the page actually appears. There should be no need for any programming at all, it should be perfectly possible for the content to be static once a page has been made/edited.

    2) There is nothing really significantly wrong with the Markdown generation aspect of the nLab.

    3) We are not that far away from being able to change things for the better. It took me about 10 minutes to write the server (I have done it before, but still…), which is of ’production quality’, which is jargon for: it can easily handle the full load of nLab traffic, indeed many times more. I have done absolutely nothing to the HTML files, or indeed anything at all, except write the server and tweak the nginx config.

    And now a few notes.

    1) To show a page, you need to use https://ncatlab.org/experimental-frontend/m.html, replacing m by the number of some page. If there’s a particular page that you would like to see, you can ask me to try to find the number for you, or you can search in the git repository I mentioned.

    2) No links or anything else will work.

    3) Some of the Javascript does not work (numbering of theorems, etc). I deliberately wished to touch absolutely nothing, so that we know exactly where we are.

    Where to go from here? Well, I’d be interested in your feedback. It would probably be quite easy to make this actually usable, i.e. getting correct links and making the Javascript work. Once we’re happy with it, we could actually switch nlab/show (which all pages are prefixed with in the URL when one loads them, as opposed to editing them or looking at revision history, etc) to point to the static site, if people wished (and if the nlab-content-html directory is updated immediately when a page is edited; I’m not sure whether or not that is the case yet, but we could enforce it if it isn’t). The remainder of the site could be as before, and we could then gradually swap out that bit too.

    I’d also like to experiment speeding up the MathJax. I think the only way is to render it server side. This appears to be possible; I have not done it before, but I will give it a go as soon as I get the chance.

    If people like these ideas, there could be lots of small tasks if people would like to contribute. Everything will be able to be built locally, so one wouldn’t need access to the nLab server, one could just make and test the change locally and push it to github, and then I/Adeel can review it and merge it.

    • CommentRowNumber2.
    • CommentAuthorDavidRoberts
    • CommentTimeMar 13th 2018

    I suppose you are aware of this? (Via Dmitri P on meta.MO, Martin Sleziak pointed to here on meta.SE)

  1. Thanks David, yes, MathJax node is what I plan to try. I’ve tried it a bit on my own machine, it looks promising. Basically what would happen is that when one creates/edits a page, we run it through MathJax node to create the HTML or SVG, and then we just load the result statically, like is done in the ’experimental frontend’.

    • CommentRowNumber4.
    • CommentAuthoradeelkh
    • CommentTimeMar 13th 2018

    Awesome! A static frontend is something I’ve thought about for a long time, but never actually got around to implementing. Needless to say I definitely support the idea. One question: why not just use Nginx’s built-in static server, surely that must be even faster than additionally going through your Go server?

    • CommentRowNumber5.
    • CommentAuthorMike Shulman
    • CommentTimeMar 13th 2018

    Interesting! Thanks for trying this out. For me, https://ncatlab.org/experimental-frontend/18645.html takes about 11.5 seconds to load, compared to about 15 seconds for geometry of physics – A first idea of quantum field theory – a significant difference, certainly, but not what I would call “more or less immediately”. How long does it take for you?

    • CommentRowNumber6.
    • CommentAuthorMike Shulman
    • CommentTimeMar 13th 2018

    That was in Firefox BTW. In Chrome, the times are 6 and 9 seconds respectively, faster but about the same ratio. (But then, as you say, Chrome takes forever to render the MathJax, whereas Firefox renders the MathML instantly. Please don’t do anything to change that!)

    • CommentRowNumber7.
    • CommentAuthorRichard Williamson
    • CommentTimeMar 13th 2018
    • (edited Mar 13th 2018)

    Re #4: Thanks very much for your thoughts, Adeel! Really great that you support the idea! It goes without saying that I will of course under no circumstances make any substantial change like this live, i.e. non-experimental, without consulting you :-).

    One question: why not just use Nginx’s built-in static server, surely that must be even faster than additionally going through your Go server?

    Good question! Quite simply, it had not occurred to me! One thought I did have was that I might in the end need the additional flexibility that the Go server would give, but I certainly agree that nginx would be even faster. Let’s give it a try!

    Re #5 and #6: Thanks very much, Mike, this is extremely useful feedback. I see similar numbers today. Yesterday, what happened was that it took over a minute before anything appeared on the screen when trying to load geometry of physics – A first idea of quantum field theory, whereas the same behaviour as today occurred for the experimental server, maybe even slightly faster: one got a more or less loaded page within a few seconds. Maybe more or less immediately was stretching the point a bit! But the experience is at least reasonable for the user.

    The difference between today and yesterday is that yesterday there was no cache of the page, and today there was. Actually, it seems that Firefox (or doing a GET request via curl, which is probably the best way to do it, to avoid any browser overhead) loads the page quickly enough to trigger a cache, whereas this does not occur in Chromium (or the webkit browser I am using, ’qutebrowser’, whose behaviour is typically similar to Chromium). If I remove the cache and try in qutebrowser/Chromium, I get the same behaviour as yesterday; I do not typically use Firefox, so did not generate the cache myself yesterday.

    So this shows that the following was in fact wrong.

    1) There is something terribly slow in Instiki’s page rendering. I have not isolated exactly where it is slow, but there is quite a bit of stuff going on before the page actually appears. There should be no need for any programming at all, it should be perfectly possible for the content to be static once a page has been made/edited.

    2) There is nothing really significantly wrong with the Markdown generation aspect of the nLab

    We see now, as Adeel has suspected before, that 2) is wrong. There is nothing significantly wrong with the HTML that is produced, but there is something significantly wrong with the production of it. There is still truth in 1), in that Instiki’s page rendering is a bit slow and the programming layer is unnecessary, but ’terribly slow’ seems inaccurate: ’mildly slow’ would be better.

    We should note though that it is not only performance reasons that might lead us to have a static frontend, it is also infrastructurally a bit more robust and modular (in particular, easier to test and isolate where problems actually are). But performance is the most obvious thing we need to improve.

    (But then, as you say, Chrome takes forever to render the MathJax, whereas Firefox renders the MathML instantly. Please don’t do anything to change that!)

    Absolutely. The reason I would like to do gradual ’experiments’ is exactly to gather feedback so that we can make a good decision. Please keep the feedback coming! We’ll have to see how Firefox handles the HTML/SVG produced by MathJax node. Hopefully the performance will be as good as before. If not, we’ll have to make an exception for Firefox.

    • CommentRowNumber8.
    • CommentAuthorRichard Williamson
    • CommentTimeMar 13th 2018
    • (edited Mar 13th 2018)

    I’ve now added nginx’s built in static server, as suggested by Adeel in #4, as an example, at https://ncatlab.org/nginx-experimental-frontend/18645.html. It does seem very snappy for me at the moment, indeed it really does seem more or less immediate in qutebrowser/Chromium (not completely loaded, but something appears on the screen which appears to be more or less completely loaded pretty much immediately; complete loading (minus MathJax) comes a couple of seconds later).

    One is never going to beat nginx for speed, but I think the Go server would be only slightly slower (indeed, it is lightning fast on my own machine) if it were requested directly; but since the request comes to nginx first and then is relayed to the Go server, we definitely lose time.

    Would be great to get feedback from Mike and others on the speed of the nginx static server compared to the others.

    • CommentRowNumber9.
    • CommentAuthorMike Shulman
    • CommentTimeMar 13th 2018

    More later, but I’m a bit confused, can you say exactly what you mean by “trigger a cache”? We’re talking about server-side caches, right? Can you explain why the speed of the request makes a difference? I don’t know much about the internals of how web servers and HTTP works.

    • CommentRowNumber10.
    • CommentAuthorRichard Williamson
    • CommentTimeMar 13th 2018
    • (edited Mar 13th 2018)

    My apologies for not being clear.

    can you say exactly what you mean by “trigger a cache”?

    At the moment, I have not gone deeply enough into this aspect of Instiki’s codebase to know exactly what happens, so I am going off observations of what happens on the server. Here are the things I know.

    1) There is a ’cache’ folder on the nLab server where certain ’.cache’ files are stored. These are very similar to those in nlab-content-html. If present, these .cache files are basically served by Instiki when one loads a page (i.e. issues a GET request), though there is some programming going on, it is not just a straightforward ’shove the cache in the response body’.

    2) If I wipe the cache (i.e. remove all files), which I sometimes need to do when making a change in Instiki, the .cache files are soon re-generated by Instiki. This roughly involves the markdown and tex that is stored in the database being parsed, and a HTML page being generated. This appears to be according to use, i.e. the first time a page is requested, and presumably after it has been edited, the .cache file seems to be generated. Since we have sites crawling the entire nLab, in practise it seems the entire cache is soon regenerated. This is what I meant by ’trigger a cache’, i.e. the first time a page is requested, it seems to lead to generation of a ’.cache’ file.

    3) This generation of the .cache file does not happen when I load geometry of physics – A first idea of quantum field theory in qutebrowser or Chromium if it were not there before. I presume it is because the load itself, which will involve the parsing of Markdown and tex source to HTML, takes too long. But I have not looked deeply enough into it to know the precise details. For some reason, presumably because the load is a bit faster in the case that there is no .cache file, the .cache file is generated if I load the page in Firefox, and also if I curl the page (i.e. do a GET request from the command line, outside of a browser).

    Let me know if things are still unclear on this point.

    We’re talking about server-side caches, right?

    Correct.

    Can you explain why the speed of the request makes a difference? I don’t know much about the internals of how web servers and HTTP works.

    Sorry for not being clearer. If you were referring to why using nginx directly is faster than nginx + Go, it is just because the ’transport’ layer (i.e. literally sending the bytes from one server to another, as TCP packets) is relatively slow, so any additional transports will affect response time. The key word, here, though, is ’relatively’: usually the difference is trivial compared to the time it takes for other things to take place, and it is entirely usual for many servers to be involved behind a website. In the case of this page, though, there are several MB being shipped around, because of the picture, so I expect it makes a small difference (though I have not measured it) in addition to nginx itself being slightly quicker than the Go server.

    • CommentRowNumber11.
    • CommentAuthorRodMcGuire
    • CommentTimeMar 13th 2018
    • (edited Mar 13th 2018)
    (But then, as you say, Chrome takes forever to render the MathJax, whereas Firefox renders the MathML instantly. Please don’t do anything to change that!)
    

    We’ll have to see how Firefox handles the HTML/SVG produced by MathJax node. Hopefully the performance will be as good as before. If not, we’ll have to make an exception for Firefox.

    Please never drop MathMl output. The other formats are opaque if you try to inspect and debug them. There are ongoing efforts (mainly by Frédéric Wang) to support MathMl in Chrome and they seem to have it working in WebKit (though I don’t know if it has made it to an official Safari release.)

    • CommentRowNumber12.
    • CommentAuthorRichard Williamson
    • CommentTimeMar 13th 2018
    • (edited Mar 13th 2018)

    Please never drop MathMl output.

    Thanks for the feedback. Of course we will not do anything without consensus.

    Personally, I am not convinced by the advantages of MathML over the following.

    The other formats are opaque if you try to inspect and debug them

    My focus for now is mainly a pragmatic one, of obtaining a performant and robust nLab. In this vein, my present thoughts are that I would happily sacrifice MathML if the performance is as good and it means that we avoid the added complexity of having to do something browser-dependent.

    I do understand that MathML has significant semantic advantages, e.g. for search engines, so I would happily adopt it if all conditions are met. But if we use it, I would suggest that we need to have good tools to produce it, and we need to have good performance across all browsers. Currently we have neither of these (Adeel and I agree that itex2MML is a major piece of ’technical debt’, as the jargon goes).

    Of course, MathJax can produce MathML, so it is not a purely either-or situation, it is more a question of simplicity and consistency.

  2. Just a note for the curious that I have begun working on a simple parser which will pass tex into mathjax-node-cli, handle Definition/Theorem/etc environments, and otherwise use a fast existing parser for converting Markdown to HTML. The use of mathjax-node-cli is working fine, and the results look good and load instantaneously in the browser; it is now just a question of going through the markdown source to extract tex snippets and feed them in. It should be possible to do this and handle Definition/Theorem environments and numbering in one pass through the file, so I expect that the parser should be speedy. Will update when I have an example ready. In the meantime, please continue with any thoughts about the examples so far.

    • CommentRowNumber14.
    • CommentAuthorMike Shulman
    • CommentTimeMar 14th 2018

    Thanks for the clarification. I still don’t quite understand why the speed of request would influence whether the cache is filled, but I’ll take your word for it.

    Can mathjax-node produce mathml server-side?

    One complication with caching/static files, which I’m sure you’re aware of, is that with the current setup, editing one page (e.g. by adding or removing redirects) can cause other pages to need to be regenerated. But that could be eliminated by making all redirects happen at request time rather than actually having the link in the generated html point to the redirected page. Of course in any case the static webserver needs to be “aware” of the redirects somehow.

    • CommentRowNumber15.
    • CommentAuthorUrs
    • CommentTimeMar 14th 2018
    • (edited Mar 14th 2018)

    I still don’t quite understand why the speed of request would influence whether the cache is filled,

    It seems to me Richard said that there may be an independent timeout for chaching pages: The caching agent requests a page in order to save it in cache, but the reply takes forever and so the caching agent gives up.

  3. Re #15: exactly, thanks! I cannot confirm this without going more deeply into the codebase, but what you describe is indeed exactly what I suspect.

  4. Can mathjax-node produce mathml server-side?

    Yes. What I envision is that we make the design as flexible as possible. Even if we do not use MathML on the main nLab, it should be possible to simply pass a parameter when calling the backend API for converting source into HTML so that it outputs MathML instead of SVG. This will allow tools which really need MathML (Bas has brought to my attention one such project for example) to still make use of the data in the nLab. If we ever wanted to change to MathML on the main lab, it would again just be the case that we add one parameter when calling the backend from the frontend. This is the kind of thing I mean by a ’robust’ and more modular nLab.

    editing one page (e.g. by adding or removing redirects) can cause other pages to need to be regenerated.

    Did you perhaps mean ’includes’ rather than redirects? As you say, we would indeed need to handle this, and it is important we remember to do so, thanks! I do have it in mind, and have at least one solution in mind; let’s discuss that once we’ve got the basics working (no time today to do much).

    • CommentRowNumber18.
    • CommentAuthorMike Shulman
    • CommentTimeMar 14th 2018

    I really did mean redirects, but of course includes also have that issue.

    I also really want the main nLab to remain MathML for browsers that support it.

    • CommentRowNumber19.
    • CommentAuthorDavidRoberts
    • CommentTimeMar 15th 2018

    I second Mike’s call for MathML. to remain in place for those that use the browser(s) that support it.

  5. I really did mean redirects

    Thanks for clarifying! I see what you mean now; yes, as you say, the same kind of thing needs to be done as for includes.

    Regarding MathML, thank you both for your thoughts. Again, we will of course not implement anything without consensus, so it looks like we will do what you suggest. Let us wait until we have examples of the different kinds to look at, though, before making a final decision.

    Also, it would be great if you could both elaborate a bit as to your reasons, again, to help us all make a good, informed decision. For browser detection comes with its own downsides, and we need to balance those downsides against the things in favour of MathML.

    • CommentRowNumber21.
    • CommentAuthorMike Shulman
    • CommentTimeMar 15th 2018

    Certainly, I am potentially open to being convinced to drop MathML; I just want to be sure that we don’t drop it without at least an approximate consensus (so thanks for the reassurance). Some of the reasons I want to keep it include:

    • It’s faster than anything else I’ve seen, and way faster than client-side mathjax. It could be that server-side HTML+SVG is as fast.
    • By rendering immediately as part of the web page, it doesn’t disrupt anchor locations. Client-side mathjax changes the height of lines dynamically after the page has loaded, which means that when I get linked to an anchor in the middle of the page, the anchor then scrolls away from me as all the math loads.
    • It looks better than many other options. Other options are often off-baseline, off-size, off-font, etc.
    • It scales correctly when I zoom the page in and out. Images either fail to scale or look ugly when scaled. I don’t know how SVG scales.
    • As Rod says, MathML carries semantic information that could be used by search engines. It’s also more accessible to e.g. screenreaders.
    • It’s a better design in principle. Even if we could produce some other option that solves all the above issues more or less satisfactory, I still think it would be a Good Thing, for the future of mathematics on the web, to do our (small) part to encourage people to choose browsers that support MathML and thereby encourage browser programmers to support MathML.
  6. Thanks very much, Mike, this is very helpful! As you suggest, let’s see, when I have some examples ready, how the first four of your points look for MathML compared to the other options. If MathML is clearly superior, there is no argument. If the options are more or less comparable on these four points, or maybe even other options are better in certain cases, then we can weigh the last two of your points against the downsides.