Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Pressed0024

  1. Let's say I already have full page cache caching the html page, APC doing the 2 segment 64mb opcode caching and mysql query caching 512mb of queries. What is there actually left for the server to do that is taking that 1-2 sec for html to load on my browser?
  2. Stablehost enterprise hosting. Its considered Shared but offers 100% of 2 cores shared. In other words, its not VPS and I dont have root.
  3. Apologize if my previous statement was kinda rude. Was typing in a hurry. I was actually hoping that someone have identified some codes changes to default prestashop which is universal to all stores that makes a huge impact on the query time and further optimized the default presta. Also, I'm allocated 2 cores for my hosting plan. Would getting more cores vs high frequency cpu help in the mysql queries? I have a lot of SELECT queries for some reasons.
  4. Everyone knows Prestashop speeds a lot of time doing mysql queries. There are way too many SELECT done by prestashop. Assuming we have done CDN, full page caching, and CCC compile. What else can we do to speed up the site during mysql database queries? How can we reduce the queries? How to better cache them?
  5. The proposed change does not impact all USPS users like you said. It only impacts overseas packages into USA. I doubt any sane merchant who care for customer experience would accept that "Origin Post is Preparing shipment" appear after "Despatched to overseas". How can a despatched package be preparing shipment again? You might throw the blame at USPS or say "Oh, it's USPS' problem. That's how they word their status.". But at the end of the day, it's YOUR application that is being used by thousands of customers. Confused customers waiting for their package too long would head straight for that chargeback or Paypal dispute button (some don't bother to contact you). The idea of waiting for more user feedback before implementing change is flawed. You need to have enough users who ships from "outside USA" into USA to experience this problem. Of those merchants, how many actually cared and noticed this? They would just see it as a 'bunch of shipment updates'. But who really sees it? The customers. Some may report to merchant, some may not. Only you, Andrew, have information on which Aftership account is doing "outside USA" into USA shipments. I had say, if you are so persistent in getting feedback to acknowledge the need for change, you can drop them an email. If they reply and specifically said this doesn't bother them, then maybe I'm the only crazy one who gets bothered about the issue. The thing is that, you already acknowledge this is a problem and you understand it. Making this change has no impact to users except for the way the initial update is being displayed (cosmetic). It also does not affect Premium Notification since Origin will also be the first to show updates and trigger InfoReceived. Either way, the Notification will still be triggered at the same time it used to be. I don't see how there is a negative side effect to implement this fix to the misleading shipment status. I'm worried about getting more chargebacks and item-not-received Paypal disputes in days to come for those late shipments due to the fact that shipments that have yet to clear US customs will still show "Origin Post is Preparing shipment". This can last for 20-30 days for late shipments taking longer time to clear customs. It could be prevented with better communication to customer through clear info at the tracking links that the package was shipped as the last update.
  6. I just reported over 3-4 different problems with the Aftership tracking. Shipment data order of display are mixed up for random shipments Aftership sometimes misses out and skips information on some shipment updates from postal website Aftership sometimes stop tracking certain shipments (eg. Postal site shows as Delivered but Aftership is still showing package has not even cleared customs) Origin Post is Preparing Shipment displayed after Despatched to Overseas problem for shipments entering USA. Confusing customers and induces payment chargebacks from customers. (don't see why this still needs to wait for more votes when it's a problem right at your face with potential financial loss from confused customers) The app still isn't stable and they are constantly still patching up shipment issues here and there. I spend most of my time going through EACH shipment in my account because I can't trust the app to correctly set the status right and report correct info to customer. I'm still not sure if the app saves me time or makes me spend more time managing shipments.
  7. There is nothing wrong with USPS. It's to do with how you display this piece of information to users which you have control over. I would suggest stripping away the timestamp for "Origin Post is Preparing shipment" and put it BEFORE the "Despatched to overseas". USPS also does not report timestamp for "Origin Post is Preparing shipment" and Aftership should also NOT. This makes it simple and clear cut for customer.
  8. Crap, bad idea. My store turned blank white when I swap the apc values from /home/username/php.ini to /home/username/public_html/ It didn't specify much on multiple store in different domains.
  9. I had mine like that: Should i keep apc.mmap_file_mask value the same or I would need to define them differently for each domain store?
  10. My cpanel structure is as such: /home/username/public_html/ (my main store) /home/username/abc.com/ (my other store) /home/username/php.ini (where I declare my APC values) Should I instead be declaring APC values in /public_html/php.ini AND /abc.com/php.ini if I want APC values to be applied to both stores?
  11. After installing Date of Delivery module, it does not show at the checkout page. How should I position it?
  12. Just received my first Item not Received Chargeback dispute from customer. Shipments from Singapore to United States have a very weird way of being displayed. Order was already despatched to overseas on November 26 but on November 28, status show Origin Post is Preparing Shipment. This confuses customers making them think the package have not been shipped out yet! (the actual reason this is happening is because Aftership tracks both Singpost and USPS and USPS is merely updating data on November 28). I'm expecting more chargebacks if this does not get fixed. Problem is critical because it's confusing customers. I propose to: Remove timestamp for Origin Post is Preparing Shipment and Add a note below that status telling customers that "Physical package may have been shipped out and this status is merely USPS receiving data from Singpost".
  13. Using 3 pull zones will saturate your browser concurrent download as much as possible.
  14. This is an interesting work around that I wasn't aware of. Let me try and get back
  15. I have had customers sending emails asking to have their shipping upgraded before we had the chance to pack their order. It's simple to have order refunded and customer reorder but some customers who paid via credit/debit cards may not have the refunded funds back into their accounts immediately. This causes problem to the reordering process. It would be great to have a module that handles such shipping upgrade request. Something in BO with a button when clicked would send customer an email that generates a link to pay for the difference for a shipping upgrade. This saves a lot of billing hassle. Any ideas?
  16. When Best sales page is set to not cache, disabled block still resides in the Top Seller block.
  17. Worth a try. Throw the "safe" js to the footer and most people should have an issue. Let most of the theme's specific js load first. Throw the js to footer and hand pick those needed to be loaded at header.
  18. I actually tried doing this before coming here to post but it didn't work. The block still contains the disabled product.
  19. Since this module is supposed to boost speed, if there is a feature to cache html where critical js scripts are loaded last, this could significantly boost page render speed. The problem with delaying js at footer is some modules have issue when loaded at footer but if you could make only "safe" prestashop default modules load last, this module can significantly reduce page load speed and is a must get for anyone who wants speed boost. There is a free running project here: http://www.prestashop.com/forums/topic/282343-free-module-move-java-script-to-footer/
  20. How to refresh the cache for the top-seller block? I have a top seller product that is discontinued and have disabled it but top seller block is still displaying that product.
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More