Giters

kwhitley / apicache

Simple API-caching middleware for Express/Node.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Recentry added cache performance track is causing high memory usage

julianpoma opened this issue · comments

commented

With the recently added cache performance tracking, we are experiencing very high memory usage on our apps, which run on T2 Micro on AWS.

This option should be enabled globally with an option.

BTW, the cache index is also being stored on memory when using redis.. This is inconvenient when using a load balancer.

commented

I just rolled back to using version 1.4.0 and the memory issues disappeared

commented

@julianpoma I'd welcome a PR on the redis cache-index issue, as that's not my focus (nor my addition)... at least until I can get the time to work on v2 (which will allow for any store via a shared promise-based interface).

Re. the pressing issue of perf. tracking impact on production: In order to maintain constant backwards compatibility, I'll need to add a flag (default true) to enable tracking. You'd need to disable to clear the error - that's backwards from how I'd like, but prevents a major rev requirement for anyone that's already implemented this feature.

Something like:

{ trackPerformance: true }

Sound ok?

commented

Hey @kwhitley, thanks for the comments. I will see if I have time to work on the index issue using redis.

Regarding the tracking memory problems, we think this option should be disabled by default. But we understand the implications with backward compatibility.

We also think it's required to add a warning on the documentation about the problems that this option could cause on system memory allocation.

@fernandolguevara already openened a PR solving this issue. Please see #175

commented

Thanks all for working on this... @svozza @killdash9 anyone want to weigh in here?

Options Foward

  1. set { trackPerformance: false } as default to prevent automatically (and negatively) impacting others as they update their deps. This is technically a breaking change, only for those few that have implemented features around performance tracking already (very new feature, so probably only a few)... but while semantically correct to do so, I'd prefer to not to major version bump (because of the impact of new versions, the fact that there are real milestones slated for v2, etc). Thoughts on doing this approach?
  2. set { trackPerformance: true } to maintain complete compatibility with previous release. This avoids breaking semver, but could negatively impact a huge number of users...

For the record, I'm leaning towards option 1. Conversely, what I could do is to turn trackPerformance to true whenever getPerformance() method is called. This would drop some initial unlogged performance before the request, but ensure that anyone that's actually using it at least gets it turned on automatically somehow.

commented

I'd say make performance tracking disabled by default. I'm sure very few are using this feature currently.

commented

Alright guys, thanks for your patience and understanding on this, and thanks @fernandolguevara for the quick fix! This is patched as of 1.5.2 with default behavior of { trackPerformance: false }. Tests have been updated to reflect, including testing performance tracking when turned on.

  • Sidenote: Also released in 1.5.2 are fixes for the deprecation notices regarding Buffer and response._headers