Vee-validate: Memory leaking (?) when using SSR

[jvandenaardweg]

Versions:

• VueJs: 2.1.8
• Vee-Validate: 2.0.0-beta.18

Description:

I noticed some memory leaking, i think, in my app when doing loadtests. This was solved when removing vee-validate from the server rendering. So, essentially removing Vue.use(VeeValidate) fixed the "leak".

I don't know if the term "leak" is correct here, but it seems like a leak.

I guess this is also leaking when using Vue on the client. But i don't have time to prove that.

Steps To Reproduce:

Take the Hackernews 2.0 example, i've added vee-validate in this fork:
https://github.com/jvandenaardweg/vue-hackernews-2.0

Install it, then run:
npm run build
npm start

Then, open up a new console window and do a loadtest:
npm install -g loadtest
loadtest -n 2000 http://localhost:8080/top

You'll notice in the console that the latency going up. When you remove Vue.use(VeeValidate), run npm run build, run npm start and run the loadtest again, the latency stays stable.

Using vee-validate in combination with SSR seems weird and, i guess, not needed actually. I only load vee-validate in the client now and thats all fine. But, my guess is if it happens on the server, there's a possibility it happens on the client as well.

I hope someone can investigate further, because this is an awesome library :)

[logaretm]

Thanks for reporting this, I will try to investigate it although I'm not an expert. so any help will be appreciated.

[jvandenaardweg]

Hmm using vee-validate only in the client gives problems rendering pages on the server that contains the errors logic, like errors.has('title'). It's not available there so the component errors and the server throws an error 500:

[Vue warn]: Property or method "errors" is not defined on the instance but referenced during render. Make sure to declare reactive data properties in the data option.

As soon as i enable VeeValidate again with Vue.use(VeeValidate) that error goes away. But then i have the problem described on top of this issue again.

So, using vee-validate on the server is actually needed. This is not true anymore:

Using vee-validate in combination with SSR seems weird and, i guess, not needed actually. I only load vee-validate in the client now and thats all fine.

[logaretm]

I tested few stuff, but it seems its getting up regardless. probably because either my windows machine is slow, or that the hackernews app isn't very ideal to test this.

I will try to find common mistakes that can contribute to the memory leakage, like dangling events that wasn't removed properly. or object references that linger on after the instance should be destroyed.

[jvandenaardweg]

Thanks for looking into it!

I also noticed in the Vue Chrome Extension the Validator is emitting an event every time, no matter if the plugin is used on a component/page. Which is also mentioned here: https://github.com/logaretm/vee-validate/issues/260

Maybe that has something to do with it?

Just trying to think of where the problem lies

[logaretm]

Well I got rid of the event spam in beta.19 and it doesn't emit anything in the docs now so I think we got that part covered.

[jvandenaardweg]

Well I got rid of the event spam in beta.19 and it doesn't emit anything in the docs now so I think we got that part covered.

Ah nice. I'll update my code with the latest beta version to see if there's any improvement for this issue.

I tested few stuff, but it seems its getting up regardless. probably because either my windows machine is slow, or that the hackernews app isn't very ideal to test this.

Hmm that's weird. I've run multiple tests, and even with 50000 requests it all stays stable without the vee-validate plugin installed.

I'm using node v6.9.4 btw

[jvandenaardweg]

Updating to 2.0.0-beta.21 didn't fix the problem :(

[logaretm]

Okay I investigated even some more, here is some findings:

First I tried to debug the installation process of the plugin, I managed to squeeze minor improvments because of how the plugin was being registered/retrieved, I no longer needed an Object.defineProperty call which was responsible for registering a validator object with each component. I noticed:

• Minor improvements after using beforeCreated cycle to add the validator to the instance.
• The latency was still going up tho, even though at a lower rate.

I removed the directive from the installation process, nothing improved.

I removed the mixin (adds the errors and the fields and the validator instance to the component instances) from the installation process and everything seems stable and quite fast.

So I've identified that the slow occurs when the mixin is being registered, I tried to remove the errors, validator, and fields registration from the mixin, each at a time, two at a time and all at the same time. surprisingly even registering an empty global mixin still slows things down. Tried trivial things like adding a string and still the slow occurs.

Can you please confirm? and for example try to add:

Vue.mixin({});

Instead of Vue.use(VeeValidate);

I will read more about JavaScript performance, but its not clear if its related the plugin at this point. I could be wrong though, or the test method is not ideal.

[jvandenaardweg]

Thanks for your time to look into this problem!

You mean like this?

```javascript
Vue.mixin({})
Vue.use(VeeValidate)
````

Unfortunately that doesn't help.

[jvandenaardweg]

I've tried an other form validation plugin, that seems to be working fine. Maybe you can spot something they are doing different which may point to a solution?

https://github.com/kazupon/vue-validator/tree/v3.0.0-alpha.2

[jvandenaardweg]

Good news! I've updated my code to the latest beta (2.0.0-beta.23) (came from beta.18) and it all seems fixed now. A simple SSR loadtest with VeeValidate enabled now seems stable!

I've tried untill beta.21 by plugging it in and load testing it. However, i just recently had the time to rewrite my app to work with the changes introduced in beta 19.

Still don't know what it was then.

Thanks for looking into it though. Good work with this library, love it!

(below: it would crash my app after about 1000 requests, now its stable well beyond that)

[logaretm]

Well that is very good, unexpected but good, I optimized few things since then, probably the nuxtjs optimization thing.

Thanks for following up on it.