Nifty

Hi Murali,

Thank you for your continued support and the information, we appreciate it. ??

That all sounds promising. We will have a look at it and see if it’s better suited for our use.

Thanks again.

Hi Murali,

Thank you. Our users frequently use it like a live chat. What would you advise we do in this situation (apart from scheduling notifications)? We’d like the notifications for new messages to come through in a timely manner to encourage user engagement with our app. Would OneSignal be better in this case from your point of view?

Thanks.

Hi Murali,

Thank you for the update. We really can’t identify why v1.69 has worked well for us, but other versions haven’t.

However, we have found that this issue is predominantly for users with a large number of different device tokens, (e.g. 12+, although we have some test users that have over 50+ tokens, where the issue becomes even more prominent). If we manually delete old tokens, then private message speeds improve significantly and server load decreases. i.e. the more tokens a user has, the slower private messaging becomes, and it increases server load. When a user has a large number of different device tokens, is there a way the process can be improved to prevent the significant impact on performance?

Are you able to test the issue by sending message replies in an existing thread using the BuddyPress REST API, to a user who has a large number of different device tokens (e.g. 20), and then manually removing most of these tokens? Each time we’ve repeated this test, we’ve noticed a significant difference in performance.

This would be doing POST /wp-json/buddypress/v1/messages

If needed, please see the reference handbook for arguments here: https://developer.buddypress.org/bp-rest-api/reference/private-messaging/#start-a-new-messages-thread-or-reply-to-an-existing-one

Thanks.

Hi @murali-indiacitys

Do you have any updates on this?

Thanks.

Hi Murali,

Thanks for your quick response.

We’re only using private messages; we’re not using other options, such as activity, friendship requests, comments, etc.

The user receiving the private message will still get a notification, but the requests are significantly slower when using version 1.89, compared to version 1.69 of PNFPB. We’ve done some rollback testing today to try and identify the version where the issue of slow request times started. From this testing, it appears that the issue first started in version 1.76.

Please see the below screenshots from Postman when replying to an existing message thread using the BuddyPress REST API endpoint: /wp-json/buddypress/v1/messages
Both of these screenshots were taken after approx. 50 messages were sent in the thread, to simulate two users chatting (this is a regular scenario we encounter).

PNFPB version 1.89 using HTTP v1 Firebase
Requests take a significant amount of time. If the server load is higher, requests will take longer and can occasionally timeout. We saw similar slow request times when testing versions 1.76, 1.80 and 1.87, for example.

PNFPB version 1.69 using HTTP v1 Firebase
The request time is significantly quicker with this setup, compared to using PNFPB version 1.89. We saw similar request times when testing versions 1.70 – 1.75.

From our testing, there does not appear to be an issue with either versions 1.69 or 1.89 using Legacy Firebase (i.e. request times are consistently less than 1 second).

Thanks.

Hi Murali,

Thanks so much for looking into this and sending out an update; this seems to have resolved the issue. We’ll get back in touch if needed. ??

Thank you.

Hi Murali,

Thank you for your reply and the extra information. We have tried your suggestions and have got it to successfully upload now. We will carry on with our setup. ??

Thanks again.

Hi Murali,

We don’t have any caching or CDN running, and don’t see any errors in our browser console. Would you be able to test it on a clean install of WordPress with the PNFPB plugin?

Thanks for your help.

Hi Murali,

Unfortunately, we are not having any luck. To test further, we have created a new installation of WordPress with only the PNFPB v1.77 plugin running, but we are still seeing no success.

Thanks.
 

Hi Murali,

We’ve tried this on our test site, and version 1.66 seems to have fixed the issue. Thank you very much for looking into this and getting back to us so quickly. We appreciate all of your help. ??

Thanks again.

Thanks for looking into this, Murali. ??

Yes, we are using the legacy API, and notifications for our mobile app are only for private messages between two users.

We’ve done some further testing today:

• User logs into mobile app on tablet = receives notifications on tablet.
• User later logs into mobile app on phone, but remains logged in on tablet = only receives notifications on phone (i.e. the device which has most recently registered token).
• On the backend, admins can see that the user has multiple tokens (one for tablet, and one for phone).
• Admin deletes phone’s token (i.e. the most recently registered token) = user will again start receiving notifications on their tablet.

We’ve encountered this situation only on mobile devices through the REST API. Are you able to test this through just the REST API for private messages, such as with two phones?

Thanks.

Hi Murali,

Just to add to our above comment; we upgraded to version 1.65, and we’re only using the PNFPB REST API for notifications.

Thanks.

Hi Murali,

Thanks for keeping us updated; we appreciate all of the ongoing work you’re doing. We’re currently using legacy API, but will move over to the latest version of Firebase API before the deadline.

We’ve updated PNFPB today, and noted that if a user has multiple tokens, because they’re currently logged on to multiple devices, they will only receive notifications for the most recently registered token. For example, if a user logs into our app on their tablet, they’ll receive notifications on their tablet. If they later log into our app on their phone, and remain logged in on their tablet, they’ll only receive notifications on their phone. Both tokens are still visible in the backend of PNFPB.

We were previously using version 1.51 of PNFPB, and with that version, users would receive notifications on all devices that had registered tokens.

Do you know why this would be?

Thanks.

Hi Murali,

We believe we’ve found the problem. The JWT plugin we had was an older version where the Firebase files were not updated. Once we update the JWT plugin to a newer version and to your plugin’s latest version, everything seems to be OK.

We’ll let you know if we still encounter issues when we upgrade our live site. Sorry for the trouble.

Thanks.

Hi Murali,

Regarding our original post in this ticket; all issues seem to have been resolved with the most recent updates.

The only thing we noted was that when you edit the background colour of the dialog box from the backend, the colour change doesn’t apply/save. We’re not concerned by this, but thought you’d appreciate knowing. ??

Thanks again for your ongoing work with the PNFPB plugin.