Thank you jerry. The installation of the processor is an amd a12, with 16 gb ddr4, mother asrock, i only use it in 2 centers, and simultaneously with no more than 2 doctors and 2 secretaries, i think the machine should not be a problem.
What do you mean by mini computer? What features do you recommend? Tomorrow i will try the innodb configuration and comment. As for xampp, would it be better to update to the latest version with php 8.2??
Thanks for your help
Hi Martin, One of my problems is I can’t test unless I setup a dataset to exercise flowboard.
Flowboard requires a lot of sequel engine hits depending on how many patients and appointments it has to filter however, I agree what you’re experiencing goes beyond machine capabilities in your case.
What happened with the environment in the interim of the upgrade. You still haven’t fully answered my questions concerning what and how did you upgrade xampp dependencies? Or reported back on memory usage from task manager.
Also what sequel engine and version are you using?
Have you looked at your browser console when you bring up flowboard for errors or clues?
What about the php error log that can be found using xampp control panel?
I’ve seen xampp do some weird things concerning performance where sometimes logging in temp directory can affect performance but my gut tells me something is going on by way of a misstep in upgrade process.
Something is bogging the system and need to find where.
Concerning mini’s they are small desktops that generally use laptop micro’s.
I currently use a mini that has 32GB memory, 1TB SSD running an i9 12th gen intel. Very fast.
I run a similar mini except a 12th generation i7 running on linux ubuntu for my family’s clinic which has maybe 4 provider at any given time.
I sell preconfigured with openemr servers but I don’t advertise it and is word of mouth.
Get back to me on my questions and depending on how much data and files you have then upgrading by installing new xampp version may be the way to go. Since you have php 8.1 installed moving ini config is easy. I’ve simply renamed current version and installed new xampp as if upgrading current then moved files and data from renamed directory. Be sure to backup database in a way that makes importing as easy as possible because I expect a sequel engine version upgrade.
Windows read and write on older drives can and will drive you crazy.
Good luck
Thanks @sjpadgett . Sorry for not having answered all the questions. Although I defend myself quite a bit on these issues, I am not a super specialist, I am a doctor and an OpenEMR user and I have it installed on two servers for use in my offices. Both under win 10 with xampp. The problem described arose after updating from openemr 6.0.0(3) in xampp with PHP 7.4 to 7.0.2 with xampp PHP 8.1.25. Although the database is very large, I don’t think it is the problem since before the update it worked very fast. Unfortunately I was not able to record the update step by step to be able to answer all the questions. I basically installed xampp with php 8.1 from scratch, copied my openemr 6 folder, configured php.ini, vitrual host, imported the database with the users and their privileges. After this there were things that did not work in version 6.0.0(3), so I updated according to the guide, first to 6.1, then to 7.0.0, then to 7.0.1 and finally to 7.0.2. From there the things that didn’t work started to work, so it was probably a PHP version issue.
As soon as I have time I will do an installation from 0, with the latest xampp, and I will document everything. The problem is that doing it with the original base of 6.0.0 the data will be outdated because even though sometimes it gets so slow that it can hardly be used, we continue using it.
I have another installation that I have done with the same procedure and it is working well, although the database has many fewer patients. In the latter, a strange error appeared, when giving an appointment, enter the departure time as when an appointment ends, which then makes the times shown on the flow board be anything.
I put the openemr 7.0.2 folder back and did the update process and it continues doing the same, the rest is working OK.
PS: I have found some problems regarding the flow board that have been there since the first versions and are reproduced in the demo, later there will be a topic to comment on that point.
thanks for your time
Okay I understand better, thanks.
Sounds like you did the same process as upgrading to xampp 8.2 so I would leave a reinstall as a last resort!
I assume you have access to phpmyadmin so you can run sql queries; I’d like to send you a query just so we can get an idea if an issue in database.
I still have like 20 emails to answer so I’ll put one up here sometime today when I get time.
Meantime the xampp version you have chosen and installed should be fine until PHP 8.1 LTS runs out.
It may be worthwhile to decide now if you want to wait til nov 2024 when PHP LTS is up to upgrade to PHP 8.2. Personally I’d wait and give us more time to shake out PHP 8.2, 8.3 and now 8.4 deprecated errors etc.
ok, I await the sql query and your instructions, I can help in any way so that openemr returns to its previous speed
regards
Sorry for the delay @stephenwaite , I was just attending the office. I tell you that I made the suggested changes before starting work.
My my.ini had this configuration:
#skip-innodb
innodb_data_home_dir=“F:/xampp/mysql/data”
innodb_data_file_path=ibdata1:10M:autoextend
innodb_log_group_home_dir=“F:/xampp/mysql/data”
#innodb_log_arch_dir = “F:/xampp/mysql/data”
innodb_buffer_pool_size=16M
innodb_log_file_size=5M
innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=1
innodb_lock_wait_timeout=50
by changing it to the suggested one:
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = “/xampp/mysql/data”
innodb_log_arch_dir = “/xampp/mysql/data”
innodb_buffer_pool_size=32M
innodb_additional_mem_pool_size=4M
innodb_log_file_size=8M
innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout=50
mysql server starts and after a few minutes it turns off, if I comment the line:
innodb_additional_mem_pool_size=4M
It works, but I haven’t noticed any changes in speed.
As I write this I see that there are other options with more buffer, I have tried them with 256 MB, and I still don’t notice any differences.
With innodb_additional_mem_pool_size added the server does not start
estoy esperando la consulta sql de martin para ver si hay algo en la base.
tambien estaba pensando en ver si puedo armar una consulta de actualizacion para modificar todos los datos sensibles de los pacientes y asi ver si le puedo pasar la base a martin para que pueda hacer las pruebas que necesite.
por otro lado, si bien casi no he entrado a las demos, la semana pasada entre para ver de reportar un problema, y tambien la note muy lenta.
I’m waiting for @sjpadgett ‘s sql query to see if there is anything in the database.
I was also thinking about seeing if I can set up an update query to modify all the patients’ sensitive data and see if I can pass the database to @sjpadgett so he can do the tests he needs.
On the other hand, although I have hardly entered the demos, last week I entered to see if I could report a problem, and I also noticed it was very slow.
Thank you all for your support
would increase this to 4G and adjust the log file size accordingly
I make this configuration:
#skip-innodb
innodb_data_home_dir=“F:/xampp/mysql/data”
innodb_data_file_path=ibdata1:10M:autoextend
innodb_log_group_home_dir=“F:/xampp/mysql/data”
#innodb_log_arch_dir = “F:/xampp/mysql/data”
innodb_buffer_pool_size=4096M
##innodb_additional_mem_pool_size=20M
innodb_log_file_size=1024M
innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=1
innodb_lock_wait_timeout=50
I’ll comment in a while.
Are there possibilities to convert the base from 7.0.2 to 6.0 again without losing patient data, to perform the update step by step again to see if there was any problem in the process and the same thing happens?
I just tried with 4g it seems that it even takes longer
Yes! I’d be happy to install your database and track for bugs. Before I did a performance profile and did some fixes back around v6 I saw several sites complain about slow load.
I haven’t yet been able to pinpoint a possible query issue but still looking for a test query to run stand alone.
I don’t have the time to build a test dataset. Wish I did.
About how many appts and patients are current being tracked on flow board load?
Is it loading for just the today date range?
I see even with no appts to track filter is slow.
My dear @stephenwaite and @sjpadgett , as is, for example my flow board today only had 10 appointments, but even with four, it takes between 10 and 15 seconds. I always use it on the current date. On the other hand, although it has nothing to do with speed, since they are looking at the flow board in depth, the statistics it shows are wrong, no matter what doctor or center filter you put, it always shows the total data of all patients who have an appointment that day, in all centers and with all doctors. Finally, not only is the flow board slowed down, to a lesser extent, but the loading of the calendar is slowed down, and other things, including entering the system after logging in.
regards
I have already done it and I have had no changes.
this statement “innodb_additional_mem_pool_size” makes mysql stop
Whenever you want, send me the query and tell me what information I have to tell you to see what’s going on.
You know it sounds like you’ve lost some table keys somewhere. I’ve seen on my database imports sometimes I lost primary key on some tables. I don’t know how and this was when I was doing ONC CCDA testing.
Check some of you main tables like patient_data, openemr_postcalendar_events and others.
My dev system is on xampp 8.2
hi @mlobo4370, pretty sure it’s your innodb settings since you’re having issues in other areas of the emr.
okay to only change innodb_buffer_pool_size to 256M and innodb_log_file_size to 64M and restart the mysql server
I’d be surprised if it was. I’d be more inclined if so to believe it a cache overflow or bad inno thread concurrency setting.
Really need to spot check indexes in tables. I have seen this on database imports on windows/xampp i.e export and import for openemr database.
At the time I didn’t check to see if the indexes didn’t export or if they were lost on import.
My gut is telling me this is going on here.
Leave these parameters as you suggest. But I never changed anything about innoDB and with PHP 7.4 version 6.0.0(3) worked perfectly
think the db has to do a lot more work in 7.0.2 with the uuids