Posted: October 14, 2019 at 6:53 am
|
I got this warning when I started making an event where I have around 15 datetimes for 9 ticket bundles. I ignored the warning and finished up setting up I made a second similar event. I got the same warnings. I started testing the registration and the site started slowing down. Would you have an idea if the events that I created hard to execute or should I look into my server for errors? Any insights? |
Hi Raffy, The notice is telling you that the value for
So, in short, if you’re getting that notice you have more inputs on the page than your server allows and you need to increase the max_input_vars setting.
As soon as you go over the max_input_vars value, EE will throw that warning.
What is slowing down on your site?
Do you need that number of datetimes within a single event? Ideally, you would break the event down some so you don’t have so many datetimes/tickets in a single event. Can you link me to the event in question so I can take a look? |
|
|
https://incognitus.ph/macquarierun-internal/macquarie-charity-fun-run-2020-3k-5k-10k-pairs/ I am not sure why the site slowed down. I have not quantified the slow down. But coincidentally, my site started timing out. The event is a fun run that requires us to produce a race kit that will go through packing and delivery. After the run, the participants will be checked-in through a maximum of 10 stations. The check-in will help us track if a person already availed. We are trying to use the event app to
|
I can’t see any slowdown on the site? Each page load is rather snappy and I didn’t see any issues during the registration. |
|
|
Hi, Tony. Yes. It seems to have improved. The thing about it is I don’t know why the slowdown and why it picked up again. I’ll monitor. I suppose it was just coincidental then. That said, what are your thoughts on the way intend to use the app and how it might impact performance on event day? We expect 2000 participants, using the app and hence the website within 3-hour window. Any tips, warnings. If I were to temporarily bump up my VPS service, what should I get more CPUs or more memory or both? Something else? |
15 datetimes and 9 tickets are not huge numbers it’s just getting a little high for a ‘normal’ event that can often be managed a little better. So nothing right now is jumping out to me to say you would have a problem, the apps use the REST API and only pull in the specific date they need/use so those requests are a little more efficient than say loading the event page. What recourse do you have available on your VPS now? Is this the first event you’ve run with this setup? Will you likely be running more?
It’s your database that is going to to be doing most of the heavy lifting here (as usual), personally I’d go for both and monitor to see if it was needed. If this is your first event, use it as a test and monitor the server during peak usage, your betting having more resources and paying slightly more during your test than having the site go down due to lack of memory for example and you scramble to fix it in that peak time, make sense? If you see that the requests hardly made a dent in the server, you know for the next similar setup you don’t need as many resources and so on. |
|
|
I just upgraded my plan from 1 vCPU to 2 vCPU and 2GB to 4GB Memory This is the first time I am running this setup. I usually have 3 tickets, 1 datetime each If I can make the multiple station check-in work both on EE4, our Internet connection, and actual event flow, yes I will have more events on EE4 like this. I am currently on Ubuntu NGINX, PHP, MariaDB. I do have to upgrade all of them. So I am working on setting up a new server and start fresh on another VPS on Linode and migrating my site there. I read that OpenLiteSpeed is even better than NGINX. So I am trying that on DigitalOcean with another domain. What are your thoughts on EE4 running on OpenLiteSpeed? Thanks for all the advise. |
|
The system started hanging each time we tried downloading reports. When we tried downloading 1-3 filtered reports the system would hang. We would reboot the server and it would hang again when we downloaded reports for our 15 date time per ticket event. The reports we got to downloads have date times that were all zero despite having information assigned to them in the event. I want to share that we resolved this by using an ee4-snippet from Github that allows us to exclude certain fields/column. As soon as we removed the datetimes we could “stress-test” the system by downloading 15 reports consecutively. |
I’m not a sysadmin and don’t have much experience with it, so I can’t give you any useful comments here.
There’s a loop for each registration for datetimes, so each of your registrations will be pulling those 15 datetimes and then looping over them to get the datetime values, sounds like your server is failing with that loop. Are you using the batch export? Meaning when you click to export it shows something like this: |
|
|
Yes, we are using the batch report. It usually hangs for the filtered batch report. Oh and just now, we just experienced a 414 Request-URI Too Large error. I tried to replicate the 414, I just end up hanging the WP when I do the batch report even with the excluded columns plugin. When I filter I get this in the URI
And this when I download a filtered report
What info do you need to help figure this one out and where should I look for it? |
|
Should I edit the link the next time and not share the whole URL? 😉 |
It shouldn’t matter, but I’ve edited the post anyway.
Just from Googling the above error on NGINX: |
|
|
Thank you, Tony. |
The support post ‘max_input_vars warning & lower site perf. after 15 datetimes 9 bundle events’ is closed to new replies.
Have a question about this support post? Create a new support post in our support forums and include a link to this existing support post so we can help you.