Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
With the indirect help of Urs, Jacques and I have identified a place where a bit of Instiki takes longer than it should. When a page is saved, then various caches need to be cleared. The “cache bug” that has been referred to from time to time occurs when a page is renamed but the old one remains in the cache. Jacques had some code to sort that out which meant that every time a page was saved, all the pages referring to it also got cleared out of the cache. While this is a reasonable solution, it couldn’t cope with the sheer number of links that Urs puts on pages! In the logs, I was seeing thousands of cached items getting cleared! (Each page has several views and each of those needs clearing, so it’s not necessarily thousands of pages.) Although each item doesn’t take long, add them all up and it’s significant.
But all that isn’t necessary if the page name doesn’t change. So now Jacques has recoded it so that the general sweep only occurs for a new page or a name change. So for saves that don’t change the name, things should now be a bit quicker - at least for pages that have lots of referring pages. I’d be interested in whether or not this is detectable for anyone … not looking at anyone in particular!
Hi Andrew,
thanks!! And thanks to Jacques!!
I’d be interested in whether or not this is detectable for anyone … not looking at anyone in particular!
Okay, I’ll collect impressions and then let you know.
The “cache bug” that has been referred to from time to time occurs when a page is renamed but the old one remains in the cache. Jacques had some code to sort that out which meant that every time a page was saved, all the pages referring to it also got cleared out of the cache.
Any hope of clearing this up by actually removing the old name from the cache?
As far as I understand it, this should be fixed sine the old name gets expired at page save. What also needs to be cleared are any pages referring to that old name as they should either point to the new name (if the redirect is in place) or have a “non existing wikilink” type link.
Is the cache bug still in existence, then?
I’m pretty sure that I saw it recently, maybe a week ago. I’ll report here the next time that I see it for sure.
After writing that, I encountered one on my course wiki where I wanted to rename a page but since I wanted to use the original page name again, I removed the automatic redirect. The original page remained in the cache. I’ve reported it to Jacques.
I sometimes do that, I mean remove the automatic redirect when I think that a “bad” trial name did not stick to use yet. So in past I had created the cache bug maybe more often than others did.
The bug appears to be more subtle than I thought. I can’t recreate it, and nor can Jacques, so please report all instances of the cache bug!
(In fact, I’ll make a separate discussion for that.)
Link to separate discussion: http://www.math.ntnu.no/~stacey/Mathforge/nForum/comments.php?DiscussionID=3168
I can’t know if the first part of the next sentence is causally related to the second part, but it is nevertheless noteworthy:
Since yesterday I am in the US and since yesterday the Lab experience that I have is uncomparably better to what I usually have: it’s quick and nice.
Is it possible that there is a causal relation here? What’s going on?
Could be, Urs – I rarely have problems with the nLab, or at least nothing like what you report.
Where in the US are you?
Could be, Urs – I rarely have problems with the nLab, or at least nothing like what you report.
Okay, interesting. All this is also consistent with two other comments in the other thread.
Tom had reported that the Lab often seems slow to him.
Toby had reported that the Lab never seems slow to him.
So that is beginning to explain something. I need to think if this maybe points to some way that I could solve the problem for me (short of moving to the US entirely just for Lab edits :-).
Where in the US are you?
I am once again visiting Hisham. Since he is now in Pittsburgh, I am in Pittsburgh. Just arrived last night.
The Lab is often a bit sluggish from Ireland too, although I don't tend to get the very long delays that you describe when saving a page. Maybe that has something to do with the pages I typically edit, though, such as their size or number of wiki-links.
This is weird. Isn’t the server in Europe?
No! It’s in the US.
Okay, great.
(I mean, not that it is in the US, but that we have figured out how this relates to the discussion we’ve been having. :-)
So then here is a second observation, which might be noteworthy in this context:
my experience is that the Lab responsiveness drops more than linearly with connection quality.
More in detail: I go by train a lot and use my cell-phone connection to connect to the internet when on the train. This works, but the connection rate is generally much lower as long as the train moves.
Now I notice the following frequently: when the connection is bad, all web pages build up correspondingly more slowly, of course. But the Lab reacts slower than the average other page when the connection is bad. Moreover, there is a point at which random pages still build up, albeit very slowly (so the connection has not completely broken down yet) but no Lab page comes through at all anymore.
Does this ring a bell with anyone? Is this maybe a hint for some effect that one could in principle try to fix?
I have a very bad mobile connection, but no correlation between slowness of the Lab and the quality of the connection at the time, as long as the response time is not on the boundary of allowed by the browser setting (the time for response too long and then it gives up). Is it possible that if certain time expires for your browser that your browser starts reloading page from the beginning – maybe you have that kind of setup. If so then there is a source of “nonlinearity”…
Is it all pages that have this effect, or is it a particular type (eg saving pages, or viewing pages that you’ve just saved)?
Today afternoon the Lab is slowlier than any time in last few weeks, in my experience.
Yes, I noticed that.
On the other hand, I’ve been doing a fair bit of heavy stuff with the nJournal so that might be a cause of some of the slowness.
heavy stuff
Isn’t it just the usual slowness due to the fact that there is a long page with lots of links? I am glad that we now have such a page that is not regarded as “just one of those weird pages that Urs produces” ;-)
I'm sure there was a conversation once about relative speeds of the Café in Europe and the USA. My own experience for years has been that when I submit a comment, there's a long wait between (i) clicking the "submit" button (or is it called "post"?) in the popup comment window, and (ii) the popup window refreshing to indicate that the process has finished. By "long" I guess I mean something like 30-60 seconds, on a fast wired broadband connection where even long Café posts with lots of comments load much more quickly than that. And previewing a comment can also take a while.
I believe that in this previous conversation, the evidence from various users suggested that this problem existed in Europe and not the USA.
(I'm aware that these are not the only parts of the world.)
I have the same problem as Tom when posting to the cafe.
Isn’t it just the usual slowness due to the fact that there is a long page with lots of links?
If you’d said “lots of maths” then I’d’ve agreed with you. A short while ago Jacques did some profiling and identified that it is maruku (the Markdown processor) that is the slowest part.
It takes a while for me to post a comment to the Café too (that is, waiting for the popup window to finish doing what it does after hitting ’Post’). Instead of waiting, I usually exit the popup window and just refresh the Café page that I’m commenting on, where the comment appears essentially immediately after I post.
If you’d said “lots of maths”
I have no experience with long Lab pages that don’t have lots of math in them.
It just seems to me that when I edit “Leinster2011” the sluggishness that I experience is the same as when I edit, say, my pages on cohesion etc.
22, 23, and 25: Same here (from California). It’s basically always been that way at the Cafe.
I agree with Mike about the Café (from Nebraska, and from California back when I was last there over a year and a half ago).
Oh, OK. Maybe I misremembered.
Maybe I misremembered.
What you remember is me noticing a speedup with Lab pages when I went from Europe to Pittsburgh a few weeks back.
This has nothing to do with the Café. I think it’s clear that the bug there that makes comment preview windows not disappear earlier (because the comment itself appears much earlier! You don’t have to wait.) is hardly related to what makes the Lab slow. But then, who knows.
No, it was a conversation from a couple of years back that I remembered, not your comment a few weeks ago in the thread above. (I don't think I'd seen this thread until a couple of days ago.) It was because of this comment of yours that I wrote what I wrote about the Café. I thought there might just be some connection. But I guess not.
Yes, I know the comment appears long before the popup refreshes, thanks. I often do what Todd does.
Ah, okay, I didn’t know that.
Although, for some reason on the Cafe, sometimes when I do wait for the popup window to refresh, my comment doesn’t appear on the refresh! I have to manually reload the page again to make it show up.
Yes, I also get Mike #33. So really, forget the popup window (once you’ve waited long enough for an error) and refresh the original.
Today I have persistently save problem: upon save the page loads for a while and returns bad gateway page. Upon reinspecting in show it is seen that the page correctly saved though the browser did not get such an information. Is there some systematic change with the behavious of save operation going on ?
1 to 35 of 35