6
$\begingroup$

I have participated on many Stack sites, and several beta sites, and this is the first time, things seem much slower.

I noticed that some of the common stuff that normally updates faster on production sites seems slower. Like Gravatars initially (perhaps those are just trickling in, as they seem to be showing up now several days later).

But also stats updates between various components (My profile view, vs User search) 'feel' slower to me, than on other sites. I concede I cannot quantify a number.

$\endgroup$

2 Answers 2

Reset to default
12
$\begingroup$

We don't artificially throttle things, if that is what you mean. We use a multi-tenancy architecture, so this site is running in exactly the same process, on exactly the same hardware, as every other site. There is some slight biasing, mainly for balancing in-memory cache for things like stackoverflow (basically, requests heading towards stackoverflow go to a particular set of nodes) - and at the database level obviously some databases are on different servers, but: your beta site here is treated no different to, say, physics.SE, programmers.SE, etc.

In terms of things like gravatars: that's nothing to do with us : ask your browser and gravatar why that is taking longer.

One interesting thing to note is that cache basically spreads pain over multiple users. If a piece of data is good, say, for 1 minute - and that site is getting used 100 times a minute, then that is 99 requests (99%) who don't see any latency. However, if it is getting used twice a minute, then 50% of the requests will actually need to do work. This will be exacerbated by things like database data loading: if the data happens to already be in memory, access is faster. If the site is used lots, it is more likely to be in memory. So quiet sites could indeed require more physical data access (rather than in-memory). OK, we use SSDs, but there's still time.

Finally, some actions are themselves triggered by ambient activity; this means that on a very quiet site you might see things one request later than you would on a busy site. For example, if you reload the questions page, and you are the only user, it might give you the stale version, even though it knows it is a little old. Then because it saw usage it will do the work to rebuild the lists in the background - so next time you refresh (etc) it may display the shiny new data.

However! For most things: less data means less things for the system to sift through; so you can actually get faster performance on a brand new site. Obviously, though, we don't specifically optimize for that case.

Does that cover most things?

$\endgroup$
6
  • $\begingroup$ That helps, thanks! $\endgroup$
    – geoffc
    Jul 19, 2013 at 19:37
  • $\begingroup$ Is even the /questions/newest/ page cached? $\endgroup$
    – Undo
    Jul 19, 2013 at 19:53
  • 1
    $\begingroup$ @Undo let me rephrase that so that you can self-answer: "is one of the highest throughput pages on the network cached?" - what do you reckon... ;p Actually, that uses our custom "tag engine" (basically, an in-memory crazy optimized question cache) - and falls heavily into the "driven by user activity" bracket. $\endgroup$
    – Marc Gravell
    Jul 19, 2013 at 21:26
  • $\begingroup$ @MarcGravell - Just a quick question since you're here, is cache invalidation mostly event driven, or time based? Or a bit of both, with certain events (new question posted, put on-hold,...) triggering cache invalidation on all related pages, while some other, less important events (question edited without a change to the title or tags, change on votes,...) might only trigger cache invalidation for directly related pages, while others are set to expire with a timeout? $\endgroup$
    – TildalWave
    Jul 19, 2013 at 23:13
  • $\begingroup$ @TildalWave "yes" / "a bit of both"; we certainly have time-driven based expiration, and explicit event-based "broadcast" expiration. We also have activity-driven with "stale" data; which is to say: a user visits a page, they get the old version (because that is cheap), but they cause a new version to be generated, even though they don't see it unless they refresh $\endgroup$
    – Marc Gravell
    Jul 19, 2013 at 23:20
  • $\begingroup$ @MarcGravell - Thanks for explaining! Yes, I can certainly understand the need for all this complexity, I'm using something quite similar myself, but was honestly curious how you're handling it here. Thanks again! $\endgroup$
    – TildalWave
    Jul 19, 2013 at 23:21
3
$\begingroup$

I agree that private betas feel slower (I haven't noticed the Gravatar thing), but we don't need a bunch of resources.

Of course, the devs are watching all the statistics and will do what they need to do to keep everything nice and fast.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .