Product load speed still too slow on Stroudco shopfront on UK production (stage 1)

[NickWeir63]

As part of the next stage of our migration from Stroudco to OFN (very exciting!) and have invited all 700+ shoppers to login and play. The feedback is very good apart from lots of complaints about the load speed - it still takes just under 2 minutes to load products when you select Stroudco from the screen below . Is there anything we can do about this? thanks Nick

[Rocksj]

This is the only negative feedback we have had at Tamar as well, especially when people have used Internet Explorer 9

[NickWeir63]

@pmackay deployed the latest OFN to UK staging today and it made a big improvement to the load speed (reducing it to 32 seconds). Big thatnks to Paul and the brilliant Aus team for improving the speed (although we wonder if pagination would improve it still more?) we would like to deploy to production but before we noticed that the new deployment caused a slight anomaly to the text on the login screen on staging - see screenshot. Does anyone know what caused this? Should we delay in deploying to production? thanks N

[pmackay]

At a hunch I suspect this is because there are new strings that have been localised but they need adding to the en-GB translation files.

[NickWeir63]

Thanks @pmackay - is this something we can do or do wee need to ask @kirstenalarsen for some help from the Aus team?

[pmackay]

I can try to do it tomorrow. Have found that is the problem, lots of new translation strings missing from en-GB file. Will update soon.

[NickWeir63]

great thanks very much. If that works please can you do the same update to UK production? I have done various test on UK staging and apart for those weird labels everything seems to be working OK.

Really appreciate your help with this

[NickWeir63]

With big thanks to the Aus team and Paul we now have the latest version on UK production and the load speed is down to 34 seconds which is great. Thanks to all involved.

However the general feeling at Stroudco is that it would be good to reduce this load speed further. Please can we have a look at Paul's pagination idea?

Thanks very much

[kirstenalarsen]

also check server and whether it needs a zap / upgrade

[pmackay]

Can you expand on what “zap” might involve? :)

Also I think the specs are the same as yours, so not sure if upgrade involving more cost is worth it? 

However there must be some reason for a difference if yous is much faster. Do you have a link to a shop on the Aus OFN with a similar number of products that loads faster?

[pmackay]

@kirstenalarsen @RohanM a separate comment on Discourse suggested that your servers might be a higher spec now. Is the recommended server spec documented somewhere? If not, could it be please?

[daniellemoorhead]

@RohanM how did you go today with this? The UK team are super keen to hear how it's going, knowing that we'll be determining next week how much time will be required to spend on it. :)

[daniellemoorhead]

@NickWeir63, @RohanM spent some time looking into the work we can do to improve the speed, here's what he came up with. Let's chat about this in our catch up on Thursday and make sure you're happy for us to proceed with this ~50hrs of work (or a subset) :)

Phase 0 - design and estimation (work to date) - 7.5 hours Phase 1 - things are fast! - 26 hours Phase 2 - smooth over some rough edges - 18 hours

The rough edges to be smoothed over are:

• The speed improvements will slightly increase the chance that a customer will see out of date information. For example, for ~30 seconds after someone buys the last of an item, the item will still remain in the store. If another customer tries to buy this now out of stock item, it's not very pretty. The smoothing here will inform the customer what happened in a friendly manner.
• In a similar vein, when admins make changes to products or order cycles, their changes won't show up in the shop for ~30 seconds. I'd like to inform them of this delay so that they can have confidence that their change will take effect.
• Updates to the shopfront will be performed by a background job worker. If something goes wrong with this worker, updates will stop applying, and frustration and confusion could ensue. I'd like to add some debugging information to the admin dashboard so that if something does go wrong, it's more obvious what the cause of the problem is.

[NickWeir63]

Thanks @daniellemoorhead - this looks good to me and I would be happy to go ahead. I will check with @sararock and @lin-d-hop and the Stroudco team and give you the final go ahead tomorrow. thanks again.

[pmackay]

@daniellemoorhead have you discussed with @RohanM about the server requirements I asked about above?

Also is there any intent to use pagination or are the improvements related to improved caching, etc?

[lin-d-hop]

Yeah I think we should go ahead with this @daniellemoorhead and @NickWeir63. Sounds long term scalable as our projects grow... so sounds like good work to benefit everyone :-)

Nice one Rohan! Thanks for this!

[daniellemoorhead]

@pmackay I won't have access to @RohanM till next week, he's away at a festival at the moment. Though @oeoeaio and @mkllnk may know what our current AU server specs are, and what's recommended. I'll add a card on our backlog on getting those specs onto Discourse.

[NickWeir63]

thanks @RohanM for taking this on. We agreed at the UK team meeting just now that this is our highest priority. Here are a couple of thoughts we wanted to add to the process:
1) @pmackay suggests that maybe pagination would help speed up the loading - so that we load just one page at a time and the first page displays while the others are loading 2) Oliver (the Stroudco manager) suggests that we start the shop front with a list of categories (taxons). And then show them one at a time. I hope this helps thanks again Nick

[daniellemoorhead]

@pmackay I spoke with @mkllnk about server recommendations - he'll be in touch to let you know what the AU current specs are but we've also added to our backlog to put some info around recommendations on the deployment wiki in GitHub with a linked topic on discourse to let everyone know it's been added.

[mkllnk]

I documented our current server specs in the deployment wiki: https://github.com/openfoodfoundation/ofn_deployment/wiki/Server-Specifications

You are welcome to discuss the specs and post your own at the forum: http://community.openfoodnetwork.org/t/server-specifications/488

[daniellemoorhead]

@RohanM can you please give us an update on here on how you're doing? And also respond to @NickWeir63's two items a couple of comments up the chain. Ta!

[RohanM]

Hi everyone!

I'm working on caching products at the moment. This means that the products list will be generated (and kept current) before any customers reach the site. When a customer does visit the shopfront, sending them the list of products would take less than a second, for just about any shopfront.

I'm about a third of the way through the first stage of this project, and we should have an initial version up for testing in a week's time.

With the caching solution, we shouldn't need to use pagination to speed up the request from the server. But we might end up using it on the client side if rendering the products in the DOM ends up being a bottleneck.

Likewise with starting with a list of categories, with the caching solution we should be able to get a fast enough page load to not need this approach. But let me know if you're thinking of this as an improvement to user experience rather than a potential speed improvement, as that would be a separate discussion.

[daniellemoorhead]

Breakdown of tasks within this issue:

• Extract page generation to lib + job [done]
• Trigger cache refresh [doing]
• Add sanity checking job, with schedule
• Serve cached products
• Smarter job queueing
• Make add out-of-stock item to cart experience nicer
• Add refresh time notices to admin flash messages
• Add DJ info to admin dashboard
• Test thoroughly on staging, fix any issues

[NickWeir63]

Thanks @RohanM that sounds great. We are looking forward to this a lot!

Starting with a list of categories is an improvement to user experience that Oliver, the Stroudco manager would like to see but he has agreed that we should open a separate issue in UK backlog for this and not delay your work on loadspeed

Thanks

[daniellemoorhead]

Latest update on status:

Stage 1

• Extract page generation to lib + job [done]
• Trigger cache refresh [doing]
• Add sanity checking job, with schedule [done]
• Serve cached products [done]
• Smarter job queueing [done]
• Test thoroughly on staging, fix any issues

Stage 2

• Make add out-of-stock item to cart experience nicer
• Add refresh time notices to admin flash messages
• Add DJ info to admin dashboard

[NickWeir63]

Thanks Danni - great to have an update Please can you give us an estimate of when we can have these improvements to test Thank you all

[RohanM]

Hi @NickWeir63,

We should have stage 1 ready for initial testing (by Aus) by the end of next week, and something ready for testing on the UK server by the end of the month. I anticipate that the stage 2 features will arrive early March.

At this stage I'm about a day's work over estimate, because some of the work has been more complex than I anticipated. That part is mostly finished, and the remainder of the work should be more straight forward. I'll keep you posted on my progress.

[NickWeir63]

great - thanks for the update

[daniellemoorhead]

@RohanM and @NickWeir63 I've split this work into 2 issues - this one is stage 1 and #828 is stage 2.

Rohan, Nick would like an update as to whether it would be possible to be testing what you've done next week, alongside of your own testing? Can you let him know a timeline, Stroudco aren't going to go live until this work is done so as you can imagine they're pretty keen to get their hands on it ASAP.

Also, it's worth considering whether the improvements made in stage 1 will be enough that Stroudco can go live once they're in production, rather than having to wait till stage 2 is complete. Food for thought :)

[RohanM]

Hi @daniellemoorhead, @NickWeir63,

Stroudco could certainly go live without the stage 2 improvements. They mostly address usability issues that although annoying, are not critical in the short term. Unfortunately some high priority security issues have come up that I'm working through, so I've been delayed in finishing the last parts before testing. I'll get something up asap and work out the fastest way we can get it tested and ready to go.

[daniellemoorhead]

Hi @NickWeir63, have just done some planning with @RohanM around timings for the completion of this and also #828 (fitting in with the other work he does outside of OFN, we have about a day a week of his time). The plan is to have stage 1 to you next week for testing, and it will be part of release 1.6. Then stage 2 (#828) will be done at a conservative estimate by April 15, which makes it part of release 1.7.

Let's chat about this further during our dev catch up next week :)

[NickWeir63]

great - big thanks to you all for this - we will make time to test it next week

[NickWeir63]

Thanks for this email from @pmackay ..... From: Paul Mackay [mailto:paul@folklabs.com] Sent: 03 March 2016 08:38 To: nick@openfoodnetwork.org.uk Cc: Lynne Davis Subject: Re: v1.5 on staging

Maikel updated UK prod last night as well when testing this other URL issue (which is now fixed!). So you could test on prod now :)

So i tried opening the Stroudco shopfront on UK production and it still took 37 seconds to open. Am i missing something? thanks

[pmackay]

@NickWeir63 are you thinking the update to 1.5 will help speed? Based on comment above, next improvement will come in v1.6.

[NickWeir63]

OK sorry - so what should i be testing?!

[pmackay]

Any other features in v1.5 that you want to test. If you’ve checked them all before, maybe there’s nothing to do! :)

[NickWeir63]

Hi @pmackay - Danni said that the Aussies would get this ready to test by yesterday. If it is ready please can you deploy it to UK staging so that I can test it and maybe get it onto production before i go away Weds? thanks very much

[pmackay]

@daniellemoorhead @RohanM please could you give the branch this feature is being developed on? Or is some of it merged to master already?

[lin-d-hop]

@NickWeir63 This is now on UK staging ready for testing. You won't be able to test large order cycles with 500+ products (as this seems to hang on 2gig memory on our staging server) however you will be able to test existing functionality for StroudCo works as expected. See http://community.openfoodnetwork.org/t/testing-products-caching/525 for what needs to be tested. @sstead has done quite a bit already by the looks.

[NickWeir63]

thanks Lynne will do

[NickWeir63]

This is all looking very good to me. Thanks @RohanM - this is so much faster - it will make a lot of Stroudco shoppers very happy (impatient buggers)! @oliver is going to look at this and see if he is happy with it but unless you hear from him I am happy for this to be deployed to UK production as soon as @pmackay has time Thanks everyone

[RohanM]

Right at this moment there are a couple of outstanding bugs - when products are shown or hidden in the inventory, the change is not reflected in the shopfront. I should have a fix for these today.

[lin-d-hop]

@NickWeir63 Just a note that UK production deployment will need to wait a bit longer than just when paul has time :-) This branch will be merged in v1.6 and we will be able to deploy after that.

[RohanM]

The first stage is done and in Aus production now. Ready to go for 1.6 :)