|
mpseminars
|
January 14, 2018 at 11:19 am
Registration checkout page is loading very very slow. When you click on register button it takes nearly 10 seconds to load the checkout page.
I have checked and looks like it’s the POST call right after you click Register button which is taking 6-10 seconds to complete.
The server has 8GB memory and PHP memory limit is set to 4096MB which is more than enough. I have checked usage logs, however, website is not even using 10% of its allocated resources.
I have also tried disabling all plugin and even tried to move MySQL database to hosted AWS database service but it didn’t work.
We are using latest 4.9.54.p version.
I noticed when I do data reset(on a test installation) from Event Espresso – Maintenance page then everything works perfectly fine. So my conclusion is that event expresso is unable to handle large dataset?
Any idea how this can be fixed?
|
|
Tony
|
January 15, 2018 at 5:42 am
Hi there,
Can you link me to an event I can use to view this?
|
|
mpseminars
|
January 15, 2018 at 8:15 am
Hi Tony, you can try this one http://markpatrickseminars.com/sp/events/gulfport-ms-mark-patrick-lose-weight-seminar-with-hypnosis-wednesday-january-17th-lm-register-now/
|
|
Josh
|
January 15, 2018 at 8:53 am
Hi Bilal,
We received your request for priority support. I suspect what’s happening is there’s an unusually high amount of bot activity happening on your site where one symptom is the bots are submitting to the ticket selector form at a rate faster than the junk/automated transactions can be deleted. I’m going to install a plugin that will allow for deleting those transactions & line items. I’ll let you know when that’s done.
|
|
Josh
|
January 15, 2018 at 1:37 pm
Hi again,
There was a higher than usual number of transactions with no submitted registration data, and they were getting submitted at a faster rate than the rate they’re deleted. I added some code to the very end of the custom function plugin on the site that changes the length of time to one day before deleting those (instead of 1 week). So there are fewer of those transactions to query through now, and there’s a noticeable speed improvement when the ticket selector form is submitted.
I can advise to re-activate the Block Bad bots plugin or better yet, use the .htaccess version which is less resource-intensive:
https://perishablepress.com/block-bad-bots/#bbb04
|
|
mpseminars
|
January 15, 2018 at 4:13 pm
Hi Josh, loading is still very very slow. It still takes about 6-8 seconds to load next page. Can you please check why it’s doing it even after your changes?
|
|
Josh
|
January 15, 2018 at 5:42 pm
I actually cannot “check why it’s doing it”, but I can open a ticket for one of the developers to make a way to limit the number of queries when the ticket selector is processed.
It will also help to reduce the number of queries if you can re-activate the Block Bad bots plugin or better yet, use the .htaccess version which is less resource-intensive:
https://perishablepress.com/block-bad-bots/#bbb04
If the bots can be blocked from hitting your site then that will free up resources for actual visitors.
|
|
mpseminars
|
January 15, 2018 at 6:00 pm
Hi Josh, I deployed the site to my local cPanel server and there are no incoming bots traffic on local server but it’s still doing the same thing.
I checked traffic logs and we are not getting much traffic on site anyway.
Can you please help us fix this asap because we are losing registrations right now.
|
|
Josh
|
January 15, 2018 at 7:03 pm
I deployed the site to my local cPanel server and there are no incoming bots traffic on local server but it’s still doing the same thing.
That would be expected because you’ll still have the same number of transactions in progress if you deployed the database from that site to another server.
I’m afraid there’s nothing more I can do to further help, especially if you’re not going to add some type of bot protection, but if you’d like you can try this branch that adds bot detection middleware:
https://github.com/eventespresso/event-espresso-core/tree/FET/11174/bot-detection-plus-request-type-context
|
|
mpseminars
|
January 16, 2018 at 8:32 am
Hi Josh,
You said that “I would have the same number of transactions in progress” – my question is: what transactions would those be? Incomplete transactions? Are you saying that if we remove the “transactions in progress” that this slow loading issue would go away?
What is an acceptable level of transactions with no submitted data?
Thank you for your help.
|
|
Josh
|
January 16, 2018 at 10:17 am
what transactions would those be? Incomplete transactions?
They’re not incomplete transactions, they are actually transactions in progress.
Are you saying that if we remove the “transactions in progress” that this slow loading issue would go away?
No and that is not a solution. Transactions in progress must not be removed if they are valid transactions. The solution will be to prevent invalid transactions from starting.
What is an acceptable level of transactions with no submitted data?
That can vary because of factors like server resources, number of events, number of tickets, number of line items per transaction.
|
|
mpseminars
|
January 16, 2018 at 2:42 pm
Hi Josh,
We are going to try the .htaccess blocking instead of the WordPress plugin. What are your thoughts on also using a service like http://www.stackpath.com ? Thanks.
|
|
Josh
|
January 16, 2018 at 2:53 pm
I’m not familiar with those, but I can advise to test on a staging site before rolling out the CDN onto production.
|
|
mpseminars
|
January 16, 2018 at 3:32 pm
Hi Josh,
They used to be MaxCDN. We were going to try their Firewall to help block bots. Are there any known incompatibilities with Event Espresso and Firewalls? Thanks.
|
|
Josh
|
January 17, 2018 at 7:09 am
The issue we’ve seen with firewalls is they need to be configured to allow the flow of information between your site and the payment processor (e.g. Authorize.net or PayPal).
|
|
mpseminars
|
January 17, 2018 at 9:23 am
Hi Josh,
OK, we don’t accept payments on the website, so I don’t think that will be an issue.
I actually cannot “check why it’s doing it”, but I can open a ticket for one of the developers to make a way to limit the number of queries when the ticket selector is processed.
Does this mean it would limit the amount of people who can register for our events at one time?
Thanks.
|
|
Josh
|
January 17, 2018 at 10:17 am
Does this mean it would limit the amount of people who can register for our events at one time?
No. It means the developer will do things like optimize the queries where possible, possibly reduce the number of queries, and where needed set a LIMIT on queries.
|
|
mpseminars
|
January 17, 2018 at 11:14 am
Please proceed and have your developer do this. How long will this take? Will these changes be overwritten if we update Event Espresso?
Note: this is a live site currently taking registrations.
Thanks Josh.
|
|
Josh
|
January 17, 2018 at 11:21 am
We’re not actually going to develop on your site. The developer is going to make changes to Event Espresso core and when they’re ready they’ll be included in an upcoming release. In between that time and now there will be a branch that you’re welcome to test on.
|
|
mpseminars
|
January 17, 2018 at 11:30 am
When do you expect that release to be ready? Thanks.
|
|
mpseminars
|
January 17, 2018 at 7:31 pm
I’m going to install a plugin that will allow for deleting those transactions & line items.
Did you do this again today? Our registration process seemed much faster after I saw the new plugin was activated (I think it was adminer) Then this evening it became slow again. Is this something we can continually do ourselves until you provide a core update?
We have tried both the bot plugin and htaccess version and we still can’t find a solution. Throughout the day, registrations will come in fine, then at other times, the page will start freezing (after clicking the “Register” button) – generating Internal Server 500 Errors.
We are losing a lot of registrations. What do you suggest?
|
|
Josh
|
January 18, 2018 at 6:36 am
Yes I did go and delete the line items where TXN_ID = 0, and I can do that again right now. What may help reduce the need to do that is add a note near the Ticket selector submit button that tells people to not refresh the page while their ticket selections are being processed. What happens is if someone selects tickets and they don’t wait, and try refreshing the page or hit the back button, their transaction record will not get saved to the database. This leads to more orphaned line items, which take a while before they’re automatically deleted from the database.
|
|
Josh
|
January 18, 2018 at 8:37 am
Update:
While I was in there deleting those line items with TXN_ID = 0, I added some indexes to a few of the columns in that esp_line_item table (at the suggestion of one of the developers). You’ll find that the registration checkout page load time is improved with that change.
|
|
jmahan
|
January 18, 2018 at 7:22 pm
I am just starting ticketing for 2018 so don’t have actual experience yet. But 2017 ticketing Checkout was too slow (got complaints from buyers). I just installed EE4 4.9.55p. When will the Registration Checkout Loading improvements be available in EE4 releases?
FYI, my experience with StackPath for another application was problematic due to having too many accesses blocked… so I deactivated StackPath… may not be a true issue but did not have time to research.
Another issue related to Checkout speed is having a small screen footprint to optimize entry and keep everything in a smaller viewset (including error messages). Will there be any EE4 changes in this area soon? THX., John
|
|
Josh
|
January 19, 2018 at 7:05 am
Hi John,
When will the Registration Checkout Loading improvements be available in EE4 releases?
I do not have a timeline.
Another issue related to Checkout speed is having a small screen footprint to optimize entry and keep everything in a smaller viewset (including error messages). Will there be any EE4 changes in this area soon?
No because that’s actually something that’s controlled by your WordPress theme. If you need assistance with your site can you please open a support topic and include a link to an event page so we can investigate? Usually we can point you in the direction of adding some CSS that will override the theme to improve the overall layout of the checkout page.
|
|
mpseminars
|
January 22, 2018 at 7:38 am
Hi Josh,
Can you show me what you did to speed up our registration process? It made the site much faster, but it’s starting to slow down again.
|
|
Josh
|
January 22, 2018 at 8:44 am
The most significant improvement involved a permanent change to the database where indexes were added to the esp_line_items table. This screenshot shows the difference in the load time after the indexes were added:
https://slack-files.com/T02SY781D-F8WHCFTRS-0a4595bff7
The other thing that can be done that may help is you delete the line items where the transaction ID is 0. You run this query on the database:
DELETE FROM wp_esp_line_item WHERE TXN_ID = 0
|
