|
Richard Duncan
|
January 11, 2017 at 8:16 pm
Hello,
We have been experiencing poor performance on Pagely and their support team suggests the following as a primary cause:
Can anyone provide an insights or suggestions?
Thanks,
Phil D
******************************
From a search it appears that event espresso is starting a php session which is causing the front-end to bypass our cache as php sessions do with most advanced caching mechanisms.
Here are the results from grep:
wp-content/plugins/event-espresso-requirements-check (trunk) copy/espresso_requirements_check.php:21: session_start();
wp-content/plugins/event-espresso-requirements-check (trunk) copy/espresso_requirements_check.php:30: session_start();
wp-content/plugins/event-espresso/espresso.php:55: session_start();
wp-content/plugins/event-espresso/includes/functions/main.php:87:function event_espresso_session_start() {
wp-content/plugins/event-espresso/gateways/eway_rapid3/includes/EWayRapid3Client.class.php:3: session_start();
wp-content/plugins/event-espresso/gateways/worldpay/worldpay_ipn.php:24:// session_start();
I was able to remove the PHP session by commenting the session_start() from this file:
plugins/event-espresso-requirements-check (trunk) copy/espresso_requirements_check.php
The Cache is now being hit and page load times have increased since the last time. This issue has nothing to do with server config/setup. Its just a matter of website optimization and taking advantage of all the features offered like cache/cdn.
The page is loading decently for me but I notice that caching is being missed again. It seems these cookies are preventing cache from working properly:
Set-Cookie: mc_session_ids[default]=7a7514426021ae396c598d0bbf4ebeea2eceb4ee; expires=Thu, 03-Dec-2015 21:15:44 GMT; Max-Age=300; path=/; domain=.comedyguys.com; httponly
Set-Cookie: mc_session_ids[multi][0]=1f98d8643fa645b9cbb8547d0416f0a59a834e28; expires=Thu, 03-Dec-2015 21:15:44 GMT; Max-Age=300; path=/; domain=.comedyguys.com
Set-Cookie: mc_session_ids[multi][1]=f8b486d5ebf0070e5a6d450a2c07084b4b204ed9; expires=Thu, 03-Dec-2015 21:15:44 GMT; Max-Age=300; path=/; domain=.comedyguys.com
Set-Cookie: mc_session_ids[multi][2]=a3f8a6023e0856e7f444b67cb563c399ca6ae37f; expires=Thu, 03-Dec-2015 21:15:44 GMT; Max-Age=300; path=/; domain=.comedyguys.com
Set-Cookie: mc_session_ids[multi][3]=12527bf592af5510e0c5004d06ba1bcae69b2ef1; expires=Thu, 03-Dec-2015 21:15:44 GMT; Max-Age=300; path=/; domain=.comedyguys.com
Set-Cookie: mc_session_ids[multi][4]=55dfa19deb45e6bed1726aeecb0dc6d076d09008; expires=Thu, 03-Dec-2015 21:15:44 GMT; Max-Age=300; path=/; domain=.comedyguys.com
The first thing you need to do is make sure the site is hitting cache properly which it currently is not due to a php session. I’m afraid that even adding more hardware is not going to fix this unless the site is hitting the cache.
Please understand that by missing the cache this causes multiple issues especially when there are concurrent visitors to the site. Workers will time out causing php errors, http requests can bottleneck and cause timeouts.
****************************************************
|
|
Josh
|
January 12, 2017 at 7:02 am
That search they did seems irrelevant, unless you actually have the requirements plugin activated (which you shouldn’t, that’s a plugin that you run once, check the report, then remove). Also, do you actually have the Worldpay gateway and the Eway Rapid 3 gateway activated?
|
|
Richard Duncan
|
January 12, 2017 at 11:41 am
We do not have the requirements plugin active nor either of the gateways you asked about.
I am trying to understand how to eliminate the things they claim are causing our site to bypass their cache since they claim that is the root cause of the poor page load speed issues.
|
|
Josh
|
January 12, 2017 at 12:03 pm
I figured you weren’t using any of those. The reality is it cannot be expected to use caching on e-commerce routes. It gets tricky beyond that too, because you might have a page on your site that handles something related to e-commerce via a short code .
If you update to EE4, you can add this code to your site:
add_filter( 'FHEE__EE_Front_Controller____construct__set_test_cookie', '__return_false' );
which should make the folks at Pagely happy.
|
|
Richard Duncan
|
January 12, 2017 at 12:28 pm
Hi Josh,
Thanks for the advice.
Question: We have a production site running EE3. What is involved in changeover to EE4?
What are the steps?
What may break, etc.., etc.?
I have EE4 on a Dev site for testing, but have not had time to go through the differences and things I need to be cautious about.
Any guidance will be appreciated.
Thanks!
|
|
Josh
|
January 12, 2017 at 12:31 pm
There’s a migration guide for planning a migration from EE3 to EE4 here:
https://eventespresso.com/wiki/how-to-upgrade-event-espresso/#plan-a-migration
and a comparison chart here:
https://eventespresso.com/differences-ee4-ee3/
|
|
Richard Duncan
|
January 12, 2017 at 2:58 pm
Hi Josh,
Thanks for the guide. Very helpful.
One thing that is unclear to me is whether or not site visitors can initiate the event registration process from the calendar in EE$ like they can in EE3.
The EE#/EE4 comparison chart seems to suggest NOT while the EE4 calendar description page does not seem speak to that function.
If it is not possible for site visitors to initiate registration from the calendar, then we’ll have to stay with EE3.
Can you please clarify?
Thanks,
Phil D
|
|
Josh
|
January 12, 2017 at 4:30 pm
The EE3 calendar really doesn’t initiate the registration process. The EE3 calendar, like the EE4 calendar, displays the events in a calendar view and includes links to each event’s page, and that’s where the registration process starts.
|
|
Richard Duncan
|
January 12, 2017 at 6:38 pm
Hi Josh,
Thanks for the clarification.
that said, why does the comparison table seem to suggest the calendar feature is different?
Is it because it was moved into an extension rather than the base plugin?
If thats the case, then I’d suggest adding a notation to the comparison chart so the EE4 does not appear as if it does not support the same calendar feature as EE3.
Thanks,
Phil D
|
|
Josh
|
January 13, 2017 at 7:22 am
No that’s not correct, and there isn’t any notation necessary because the EE3 calendar and the EE4 calendar are for the most part identical.
In the case of EE3, the calendar was added by a plugin, and the same is true about the EE4 calendar. It’s also another plugin you install.
The important thing to know is that the EE3 calendar is not compatible with EE4. So if you have a EE3 calendar plugin installed on your site, you’ll need to remove that and install the EE4 calendar when you upgrade to EE4.
|
|
Richard Duncan
|
January 13, 2017 at 12:15 pm
Hi Josh,
Understood.
Thanks
|
