tmccormi wrote on Friday, March 09, 2012:
This overview has some very interesting things to say. Worth a look…
http://www.slideshare.net/techdude/how-to-kill-mysql-performance
-Tony
tmccormi wrote on Friday, March 09, 2012:
This overview has some very interesting things to say. Worth a look…
http://www.slideshare.net/techdude/how-to-kill-mysql-performance
-Tony
yehster wrote on Friday, March 09, 2012:
The two biggest offenses we commit with OpenEMR are
#12: Not being a join-fu master
#15 Not Profiling or Benchmarking
xl, even when using English with empty translation tables uses a bunch of time
audit_log is pretty bad as well
mcaloon wrote on Monday, August 13, 2012:
Hello there,
Perusing the net today and found this about partitioning for those of you out there with high cardinality. This approach to tuning take a little knowledge about the data in the openEMR tables but can reap high benefits. I’ll post whatever findings I discover.
http://dev.mysql.com/tech-resources/articles/partitioning.html
Mac
tmccormi wrote on Thursday, August 16, 2012:
This is something we need bad, in general. The current “reports” drag the system to it’s knees on anything with a large +5000 patient DB. This is really bad when the “system” is a shared host, so one practice can drag a whole group of customers down just by running a report if the all are sharing a single instance of mysql (separate DBs).
-Tony