Performance and express-cache-on-demand

18 views
Skip to first unread message

Matthew Crider

unread,
Jun 27, 2016, 10:53:58 AM6/27/16
to apostrophenow
Hi guys,

I'm consistently getting a 2 second time-till-first-byte delay whenever i hit my Apostrophe site, and having a heck of a time tracking down the issue other than the fact that i have a complex page with lots of modules.  

My best bet is that a big factor to the delay is due to using the JS bson extension rather than the C++, but I can't fix this for the life of me (I even tracked down https://github.com/mongodb/js-bson/issues/58 which Tom weighs in on, but couldn't get any of the guidance on that page to fix my issue).  I'm also not entirely sure I'd get that much of a performance gain from this -- is this worth spending more time on or in your experience is the JS bson extension not that much slower?

The other thing that i'd like to get going is some level of generic page caching. Is this possible with https://github.com/punkave/express-cache-on-demand with some tweaks?  Or is that really not what its intended for? I'd love apostrophe to always send a cached html file over the wire and bust the cache whenever someone makes any sort of update (since a module update in one place can affect some other page).

Thanks,
Matt

Tom Boutell

unread,
Jun 28, 2016, 10:35:24 AM6/28/16
to apostr...@googlegroups.com
Hmm. In my experience it is not dramatically slower in practice. It's still a win though and having the compiler/developer tools installed properly from your OS package manager ought to be enough to make it work on the next npm install of the project.

Two seconds is pretty slow I'd agree. You can experiment with the trace feature:

TRACE=1 node app

You'll get A LOT of output, but sorting through it you can find out how long various parts of the loading process are taking.

A common culprit: joins that fetch other documents that contain widgets which fetch other documents, and so on, fetching more than you need. We usually address this by limiting the data returned by a join:

_places: {
  type: 'joinByArray',
  idsField: 'placeIds',
  label: 'Places',
  getOptions: {
    fields: {
      slug: 1,
      title: 1
    }
  }
}



--
You received this message because you are subscribed to the Google Groups "apostrophenow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apostropheno...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--


THOMAS BOUTELL, SUPPORT LEAD
P'UNK AVENUE | (215) 755-1330  |  punkave.com

Matthew Crider

unread,
Jun 28, 2016, 3:46:19 PM6/28/16
to apostrophenow
Thanks, that definitely helped.  I have a lot of schema-widgets with joins and specifying the fields to grab is definitely a thing I should've done. I'm down to 1.5s TTFB.  Gonna double down now and try to get the native bson extension working.

I gotta admit I can't make heads or tails out of the TRACE output :)

Anything else you guys have looked at as far as performance in the past?
Reply all
Reply to author
Forward
0 new messages