If you are sure about the visits being an issue, just disable code that fires up past encounters tab whenever $pid is changed. When we did, users haven’t missed it. They use the shortcut to open that tab if they ever need it.
You can even make the tab opening optional at user level with system default of not opening the tab.
nice workaround @mdsupport, but if poor performance is occurring here then will pop out other places too, an extra 4 GB of ram can’t be more than $50.
Cumulative cost of every extra mS users spend waiting for response is always ignored. Then there are folks taking pride in running emr on raspberry just because it can or it should !!!
hah, no, everyone wants a snappy responsive emr 
Ok, that sounds great. Where is that code for the other people reading this thread? (AND me too =^)8 )
It’s always fun chatting with you guys!
It has been years but I think it may be in left nav (yes, it lives on) related knockout code. Maybe something like proxy.js where current patient is set?
This is just one of the several ajax actions going on. So not a magic bullet.
Hi @juggernautsei, This will give an idea of how detailed you can get with the profiling you’re working on.
I use QCacheGrind and don’t recall why not KCacheGrind. Still anyone interested, profiling and trace is very effective for this type of issue. I no longer have a database populated enough to see the issue however, I will soon for stress testing so if not solved by then, I’ll profile OpenEMR again as we did for sessions.
Here is one of my profiles. I still trying to figure out what I am looking at and to be able to run another profile.
cachegrind.out.8788 (2.5 KB)
So, I got profile a new profile to run.
https://drive.google.com/file/d/1hN49c88e-krcMN50q177vfRpWxjAG-I-/view?usp=sharing
This tells nothing. Start profiling when you load a patient then stop after it loads and settles.
email the profile.
This is from the time that the calendar appointment showing the patients appointment is selected to the patient is loaded.
Its all Greek to me =^) Is it tell you anything?
@juggernautsei How many logging options are turned on? Try turning off logging and I bet you’ll see at least a 50% increase in performance.
I’m not saying this is a solution however, you may have logging turned on you don’t need. One biggy is make sure Audit Logging SELECT Query was not turned on.
btw: you’re missing some profiling files because the two you sent does not show any patient loading and times are short. If you note the extension on file, it is the process id for that segment of profile. You may get many files for one session. e.g each script that gets called will be another profile file.
You can also change php.ini for xdebug.profiler_output_name = "cachegrind.out.%p" to say
xdebug.profiler_output_name = "cachegrind.out.%s" for the script name the profile refers to.
Post me a screenshot of how you saw that please. Turning off the logging brought the system to normal operations. I have not changed anything else in the system and the longest running page pops up now.
They had all the logging turned on in the system.
@juggernautsei
Logging is pronounced in this snapshot. Note that graphic shows the select audit logger. If I had more profiling files this would be much clearer and we could show the exact timing in various scripts.
Anyway Sherwin, glad we got it figured out but still, after revisiting profiling openemr, I can see we need to once again visit with breaking up globals.
Knowledge is best shared.
I like doing these kinds of threads with conclusions and solutions to a problem. I think it enhances the self service model. It would be nice if more people would post back conclusion and solutions to issues to make it a little easier for new comers to fix things that may seem broken.
