|
Matt Shane
|
January 11, 2023 at 9:37 pm
Hi Tony –
So we have been having an issue of slow response times. It gets so bad that it is affecting our registrations where people report the spinning gear on registration never stops and they abandon the transaction. The site is extremely slow to respond when trying to work on the backend also. It takes 16-20 seconds of waiting to respond before anything loads.
On troubleshooting, when I disable EE and the associated EE add ons then the response time is back to 2-3 seconds.
I see the is a scheduled EE job that fails in the Event Scheduler so not sure if that is the problem.
Can you please help?
Thanks!
Matt
|
|
Tony
|
January 12, 2023 at 7:28 am
Hi Matt,
What type of hosting are you using?
How many events and registrations?
I see the is a scheduled EE job that fails in the Event Scheduler so not sure if that is the problem.
Can you add more details on this please, which job?
Can you post a screenshot of the page showing it?
https://eventespresso.com/wiki/troubleshooting-checklist/#screenshots
|
|
Matt Shane
|
January 12, 2023 at 9:02 am
This reply has been marked as private.
|
|
Tony
|
January 12, 2023 at 9:29 am
Had same hosting since 2018 and its been fine.
How long you’ve been running on a host unfortunately isn’t a good indication of well it’s working (I wish it was!)
Have you checked your control panel to see what the CPU, memory and disc usage is?
—
Your application takes up about 30% of installed plugins – others are standard – Yoast, gravity forms, WP Classic Editor, Mail log etc…
Please take those reports with a pinch of salt, I appreciate it shows EE as the most resource-intensive plugin… which is because it has to be, it does a lot more than most other plugins do and we can’t cache the requests because they are all unique to the visitor.
Happy to provide credentials so you can log in and see the behavior for yourself when active and not.
Sure, I’ll take a quick look but I’m not sure if it will help point to the issue to be honest.
You can send temp login details over using this form:
https://eventespresso.com/send-login-details/
|
|
Matt Shane
|
January 12, 2023 at 9:31 am
sending over login details.
just need to resolve this because it is impacting registrations. Always keep the plugin up to date. And we havent grown the site at all. Its simply for workshop registrations throughout the year.
thanks!
|
|
Matt Shane
|
January 12, 2023 at 9:37 am
This reply has been marked as private.
|
|
Tony
|
January 13, 2023 at 5:12 am
Hmm, strange.
So, I can’t tell you why that is happening here currently.
What I did was time the requests to load the ‘Pages’ section of the admin (not related to Event Espresso).
With Event Espresso activated fully, it takes around 28 seconds.
With Event Espresso in full maintenance mode, 18 seconds (still a relatively long time)
Maintenance mode means it doesn’t run any queries on the database relating to Event Espresso other than those required to actually function, so no queries events, registrations, in short about 95% of the queries from Event Espresso are disabled etc. So with that enabled and still having long load times it means its not related to the amount of data loading within EE (you don’t have enough for that to be an issue anyway).
With Event Espresso fully de-activated, 5 seconds.
So I see what you mean but I can’t see why it’s happening.
What I would recommend next is installing a plugin such as Query monitor:
https://en-gb.wordpress.org/plugins/query-monitor/
Disclaimer here because Query Monitor will actually slow the site DOWN whilst it is enabled, because of what it’s doing, but it may help identify what is causing the load times.
—-
When I run GT metrix it shows the site at 90% or above in regards to performance so it has to be something running or trying to run and timing out in EE would be my assumption since it functions fine when EE is deactivated.
I assume you are referring to running that on the front end of the site?
The results get skewed on hosting like GoDaddy Managed WordPress because they heavily cache the front end of the site. All pages on GoDaddy Managed WordPress packages have caching force by default. Generally, it will also cause issues with registrations because you can’t cache eCommerce requests like Event Espresso but seems not in your case, which is also a little confusing but that’s an issue for later.
This isn’t a timeout within EE, the delay is on the TTFB (Time to first bite) which means something is processing on the server and the request is waiting on that. It may well be something related to EE, but right no I have no idea what could be, especially with Maintenance mode not fixing it.
|
|
Matt Shane
|
January 13, 2023 at 8:42 am
This reply has been marked as private.
|
|
Tony
|
January 13, 2023 at 1:30 pm
As I said, we have been using EE on this host for years now with no problems so maybe it was related to a recent update? We only process a couple registrations a day if that – some days none. On a busy day maybe we do 7-8. But thats it.
If this was caused by an update from Event Espresso I’d expect to have many reports of this from other users but nothing so far. Right now I can’t say for sure that it’s not from an update although nothing within how Event Espresso works within core (which is what is running when in full maintenance mode) has changed in a long time now so it seems more like a conflict on the site/server currently.
I can’t reproduce anything like this on my test sites and I run sites on really cheap hosting through to premium hosting to try and replicate some of our customer site setups. Most of those sites have more registrations etc than yours (but again because it happens in full maintenance mode I don’t think this is ‘data’ issue) and none of them experience anything like this with EE active.
Have you opened a ticket with GoDaddy regarding this at all? It would be interesting to get their take on this issue.
I can send you a copy of 4.10.40.p if you’d like to re-install that one and see if it’s any different? There are no database migrations between 40 and 41 so it is safe to switch between them.
But we do need a path to resolution so I will run the Query but when you say that you have no idea what can we do from here?
I can’t give you an answer to this as I can’t reproduce it so starting with steps to try and find something which stands out, Query monitor is the first step.
But we do need a path to resolution so I will run the Query but when you say that you have no idea what can we do from here? I dont need 3 second response times but 18 is too long and that is what I am getting also – except when EE is deactivated.
I understand the response time is unacceptable but without ‘something’ to work on such as an error or some kind of area to investigate I can’t give you the answer you’re looking for here.
If you let me know when Query Monitor is active I’ll take a look over what that returns but that would need to be a weekday as we don’t work support over the weekends.
|
|
Matt Shane
|
January 14, 2023 at 10:24 am
Hi Tony –
I have installed query monitor application and let it run a few minutes. You are right – the site comes to a screeching halt. Anyway, it looks like there are some database errors related to the EE core, EE Mailchimp add on possibly… etc…
If you can take a look Monday and let me know that would be great. Feel free to turn it on when you have a few moments to login and check.
Thanks!
Matt
|
|
Tony
|
January 18, 2023 at 4:48 am
Hi there,
Just noting here I’ve looked into this and responded via email, but adding some additional details for any readers following along.
The issue here does indeed seem to be from Event Espresso, in that it is trying to update a site option used for tracking the installed versions and that is failing. However, the option EE is saving should only contain version numbers and the date the version was activated/updated but they currently have a bunch of other data within them.
So something has gone awry with those options but I can’t see what or how, I’m not reproducing anything like this on my test sites so the next step is to wipe the options out and allow EE to rebuild them ‘correctly’ to see if happens again.
|
