Performance issues with 700 active users

[idillon-sfl]

Hello !

We currently have about 700 active users (more than 1000 in total)

e-mission-server runs on a virtual machine of 8 vCPU and 16 GB of memory. The database has 16 vCPU and 32 GB of memory. All of this seems to be more than enough. Yet, we experience performance issues.

One particularity of our app is that users get a notification to fill a survey at 9 pm. The link to the survey appears at this moment on the diary page. Our performance issues seems to arrive at that moment. We suppose many users open the app at the same time, which causes the trips of the day to be loaded. Users told us the the app gets stuck around that time on "Reading from server..."

Otherwise, it seems trips are being saved properly. Very few users told us about issues on that matter. The data analysis is also not causing any trouble.

Do you have any recommandations for us to optimise our server?

I noticed we are using an old version of e-mission-server. Can we expect to have any performance benefit by upgrading it? How risky would it be, considering we can't afford a long downtime?

[shankari]

@idillon-sfl Are you using the diary view or the label view?

The diary view has known performance issues because:

• we construct the geojson for the day on the fly, which involves reading trips, places, sections, stops and trajectory information
• we read the full trajectory for each trip, even if the trips are long

Earlier this year, we changed the label view to work with precomputed "composite trips" instead. The composite trips include the trip, the end places, and a downsampled trajectory.

See the detailed history in
#840 (comment)

You should check your own logs to verify that this is the cause of the slowness you are seeing.

If it is, I would suggest upgrading both the phone and server.

• First upgrade the server. After the server upgrade, it will automatically create missing confirmed places and composite trips.
• Then upgrade the phone. The label screen will start using the new composite trips.

If you don't want to do that, at least use the old version of the label view (end of 2022), which pulled the trips directly instead of creating geojson.

If you are already using the label view, we need to look at your logs.

[shankari]

@idillon-sfl I see that "The link to the survey appears at this moment on the diary page. "

We have discussed diary/label unification, and the reasons for the performance improvement multiple time in the monthly sessions. There's a reason for the change.

I would suggest upgrading, at least to end of 2022, and using the survey in the label view.

[shankari]

From Mon, Jan 30

As @ericafenyo pointed out, the diary page was slow because we were creating the entire geojson, including the full trajectory information, on the server and returning it one day at a time

• We have replaced this with the label screen, which pulls only the trips first, displays them, and then fills in the trajectory information later – e.g. Review Unified Label/Diary Screen PRs #779
• I am not sure that cordova is the cause for slowness per se, as much as it is an incorrect access pattern.
• We will remove the diary screen in a future PR and only support the label screen going forward

[idillon-sfl]

Thanks for the clues. I was not aware of these improvements. I'll integrate them as soon as possible.

[shankari]

Great! Since you are in an active deployment, you could do an incremental update to the end of 2022. But before you start the next data collection, you should really upgrade to the most recent versions with the composite trip.

[shankari]

Closing this; please reopen if the upgrade doesn't resolve your issues.