Event taking too long to deploy/undeploy

We’ve been working with events on couchbase server 6.5. We noticed it is taking long times to deploy/undeploy events in a development environment with very little data. We’ve tested with both: “everything” and “from now” with the same result. Also, we noticed that using the command line, events deploy/undeploy with acceptable performance. Any clues?

Hi @luciane.araujo,

The status in the UI is shown “Deploying” until it has opened a stream from each of the 1024 vBuckets. The time to deploy/undeploy should not impact overall performance. From command line, it doesn’t wait and hence it appears faster. It is is safe to ignore the deployment/undeployment time if it’s in dozens of minutes range as long as otherwise, the handlers are functionally proper. If this is causing a specific issue, please let me know here and I can help by looking at the log files in a bit more detail.

Thanks,
Siri

Hi @Siri,

Thank you for your answer. The deployment/undeployment time is in the dozen of minutes range (so, it is working as expected). Our issue is related to development of a sort of heavy event (we’re migrating views to events). What happens is that whenever I deploy, I have to wait the deploy to fininsh to, for example, debug the event. Or, if by any means I find an issue in the event I just published, I have to wait until deploy/undeploy finished pause, update and redeploy. So, I guess that my question is how to make event development less painfull due to long waitings in the UI? What are the recomendations?

Kind regards,

Lu Araujo

Hi @luciane.araujo,

I do understand the difficulty in development cycle. We’re planning to add a simulator that allows running a doc via eventing without doing a deployment in the future. I’m surprised it takes so long when you deploy “From Now” as it has nothing to process. Are your handlers very heavy and take several dozen seconds to run?

The other thing I find myself doing sometimes is to fire up nodejs and write plain JavaScript code there (no “require” statements), and once it works well, bring it into Eventing. That way, I can play around in a less constrained environment. As both NodeJS and Eventing are based on the same core - Google V8, code generally behaves the same in both places, as long as you restrict to subset that Eventing supports.

Thanks,
Siri

Hi @Siri,

Thank you for the tips. I’ll let my developers know. One thing, that makes me believe that there is something else we’re missing is that even the simplest of events takes around 10 - 12 min to deploy/undeploy. I’m not sure what to look for.

Kind regards,

Lu Araujo

Yes @luciane.araujo - I created a default handler (which logs the document id) and ran it on travel-sample bucket (that comes with server) having about ~30k items and ran it on all docs, and it took about 20 seconds to deploy and undeploy. So if the handler is simple and it takes so long, I’d like to look at the log files.

Would it be possible to upload logs? You can do so via the UI, in the “Collect Logs & Diagnostic Information” screen (please select “All Nodes” and “Upload to Couchbase” option). Please ping me when it’s uploaded and I’ll take a look to see if I can diagnose further.

Thanks,
Siri

Hi Luciane,

Building upon what Siri has told you 10-12 minutes sounds excessive. I will address

I have a few idea on what could be happening to this end I would like to know:

a) How many nodes and what Couchbase services are they running.
b) How many Eventing Functions you have (visible in the UI whether deployed or undeployed)
c) How many buckets do you have in your system.

You say you have acceptable performance on the command line but not in the UI,

I believe in 6.5.1 all the issues you are seeing will be rectified as per recent work specifically:

  1. https://issues.couchbase.com/browse/MB-37378
    Everytime you enter and exit the eventing page in the UI an additional zombie request thread is started - you mitigate this via hitting refresh on the browser

  2. https://issues.couchbase.com/browse/MB-32437
    The actual status fetch via HTTP api/v1/status taking long time- only corrected in 6.5.1 and beyond.
    Optimize the calls that checks UI status which slow down exponentially with increases buckets and increasing functions - only corrected in 6.5.1 and beyond.

Note 6.5 has a best case deploy of 80 seconds and undeploy of about 75 seconds (and a worse case of deploy of 12 minutes on systems with a lot of Buckets and about five [5] Eventing Handlers)

Definitely use try 6.5.1 (when released) - Eventing with the above updates will typically allow 18 seconds deploys and 17 second undeploys per Functions regardless of the number of buckets or number of Eventing functions. Believe me this speed up (especially on large systems) really makes Eventing development less painful. If you contact Siri or my self directly we might be able to provide a pre-release preview of the 6.5.1.

Thank you, for the information @jon.strabala. We currently are busy dealing with repercussions fo covid-19 on our project timelines. As soon as all is settled I get in contact with you guys.

Kind Regards,

Lu Araujo