The server is on AWS T3 Medium 4GB RAM, 60GB SSD.
The upgrade is completed but the calendar is slow loading every time.
I went through the database and updated it from utf8_general_ci to uft8mb4_0900_ai_ci.
I can’t find any instructions on the web to figure out if the database is indexing the data.
Yes, all of the defaults are configured in the PHP.INI file. Max_vars set to 6000. This is a really small database.
How can I figure out if the data is being indexed?
Make any recurrent appts less than 2 years long?
One, how many providers and facilities?
Two, do you have PhpStorm? If so, now’s a good a time as any to learn how to profile. Ya can set up to do on remote which I already know you do remote now.
For grins, clear your smarty cache.
Have you notice an issue with recurrent appts Ray?
Only that you need an end date for recurrent appointments for the calendar to work properly. Setting them to 2 years out works for me. I only use these when setting up the base template for a provider.
Wow, wonder if that is long for most. If you’ve notice issue using end dates less than two years then, i’ll look into when addressing another users different issue with calendar.
3 providers. Yes, I have PhpStorm.
Guess what I finally saw?
What’s wrong with this calendar?
All of the times are OUT. No IN OFFICE
It’s purple!
Beats me. No schedule!
?? In the past the recurrent appointments did not work and slowed the calendar. Your comment is, well I don’t know. Kinda ridiculous really. I would just say that if he still had the recurrent appointments that were not limited, try limiting. Turns out he had recurrent appointments that were all Provider Outs. So the recurrents were the issue, just there was no Provider In. Please pause and think before making such comments.
I was commenting on you having recurrent appointments going out two years if that was common.
I saw what Sherwin issue was.
So how about you think before picking a fight with me.
My guess is a provider really wanted a lot of time off for a nice vacation 
I have finally figure out what is wrong with the upgrade. The pagination on the encounter page is broken.
It takes a lot of time to load 200+ encounters to a page.
I am trying to figure out why is it broke where and fix it.
I was wrong, the pagination is not broken. The issue the the amount of documents that are stored in each patients chart.
This is a real screenshot. There are 159 past encounters. How many past encounters need to be listed here? 5? 10? 25?
Thought they were paginated?
@stephenwaite that drop down is not paginated. That is what I am referring to. Not the page that displays the past encounters. That part is paginated.
Just looked back and see 4GB RAM, should at least double that, server must be swapping.
@stephenwaite I respect your opinion. My concern before just adding resources is that I have a larger system with 6 times the data running on the same type server with out any slowness. How is that possible?
It is a mystery I am trying to solve. They both have data that was converted from v4. One has 1.2GB of data (phpmyadmin stats). The other has 6.7GB of data in the database. But the one with 6GB of data runs faster than the one with 1.2GB of data.
We did test the 1.2GB system and when we put in a new patient the patient chart pops up faster than some of the existing patients charts. So, it is about the data contained within the charts. In the 1.2GB system they store lots of EOB files in the chart. I don’t know what effect that has on the system. When I say a lot, there could be over 30 -50 EOB files in the chart.
I am going to keep digging.
I did limit the past encounter drop down to 15 most resent past encounters. But the system still take up to 30 sec to load that client that has 159 past encounters. I have limited the document display in the encounter tab to the 5. The chart still takes 30 to load.
@juggernautsei, Recurring appointments pointed out by @ophthal are a serious issue with older installations. For grins, suggest putting a return null and short circuit the recurring check to rule out the issue.
Slow load of newly selected patient is a completely different can of worms due to overload of “widgets”.
I have updated the title of this thread. Since I have learned it is not the calendar that moves slowly. It is opening a patient’s chart with 159 visits and 300 documents attached to it that takes 30+ seconds to open. Thanks @mdsupport
