Jump to content

Pressed0024

Members
  • Posts

    220
  • Joined

  • Last visited

Posts posted by Pressed0024

  1. The insights from Host Gator is quite useful. I;m still interested to hear if anyone can confirm if VPS will bring down First Btye Response Time. If so, what exactly did the VPS do to help?

     

    Purely CPU?

    Purely disk i/o (SSD)? 

    Ability to use APC (or other opcode)?

    Ability to use Varnish?

     

    I know this is a "your miles may vary" kinda question but had like to hear from others who are willing to share their experience.

     

    Meanwhile, here is something I use to create cached HTML. Useful if you are in Shared Hosting where you are limited to many server configs:

     

    http://www.prestashop.com/forums/topic/281654-module-page-cache-speedup-your-shop/

  2. I actually don't really recommend using a CDN for most clients. It depends on how much traffic you are getting to your site really. A good rule of thumb is if you are using shared hosting, a CDN is a waste of money. For a CDN to work properly, your files have to be accessed a lot. Places like cloudflare will not cache files that are not used a lot, so there is no benefit. Plus one thing you have to deal with using a CDN is slow DNS responses, and the added weight of the CDN cookie on the resources. 

     

    There are a lot of misconceptions about what it takes to make a site fast. I don't necessarily thing that SSD drives do the trick either, it is just another gimmick to sell you something. This site is running on my dedicated server that I set up, it is using Prestashop 1.5 and no CDN, http://screencast.com/t/XEQZ98Sa  You can't really get much faster than that. It is not running a caching module either. 

     

    Most of the server latency you get is from the disk, there is a huge benefit to running varnish over having disk's accessing a resource. 

     

    But that is on the static content part like CSS, JS and images which at the moment isn't slowing my site down.

     

    The thing that is slow is the first HTML that gets loaded. I'm assuming Varnish doesn't play a role here since it can only be useful for non PHP and HTML objects?

  3. More than likely php is not set up correctly to run any kind of caching. There is no benefit to running the caching modules in that state. 

     

    Opcode caches do not store the html in memory, you would need varnish or something similar to do that, but you are going to run into issues if you use varnish to cache anything other than static assets. 

     

     

    I actually think http://addons.prestashop.com/en/administration-tools-prestashop-modules/7939-page-cache.html would be able to replace Varnish and way easier to configure. The only benefit of Varnish is that the cached files are in RAM but the above FPC prestashop module is cached in hdd (only way to make it faster is use SSD).

     

    I saw in your blog post about using Varnish to cache static contents like images. If I already use CDN, what benefit does the Varnish still give since it won't be able to cache html? (html is the only I can't do CDN)

  4. The APC problem you are having is more than likely because you are not running PHP correctly. Which interpreter are you using? APC only works with FASTcgi or DSO php. If you are running PHP under SUexec it is not going to work because of the way that threads are handled. 

    Yes, I figured that out yesterday. I searched "APC uptime 0 minutes" and lotsa results. There is a solution here but unfortunately I'm on Shared Hosting (with SSH): http://www.brandonturner.net/blog/2009/07/fastcgi_with_php_opcode_cache/#implementation

     

    1. I decided to hop over and use Zend opCache. I use https://github.com/amnuts/opcache-gui to check the stats. It has the same issue like APC where it keeps flushing cache due to multi threads. Is there any benefit to keep opCache running on my shop despite it flushing itself every 1-5 seconds? 

     

    2. I also have Prestashop Full Page Cache module running which gives good speed by storing the compiled HTML in cache in /cache/pagecache/. But assuming I get to fix the Zend opCache/APC flushing issue, is there anyway to make the opcode cacher cache the compiled HTML from /cache/pagecache/ instead? That would make it incredibly FAST since it reads the compilied HTML from RAM! http://www.prestashop.com/forums/topic/281654-module-page-cache-speedup-your-shop/

  5. I'm using Zend opCache (it's just like APC) in my server. It caches PHP into RAM which makes the first load appear ALOT faster. Very useful for dynamic pages like the shopping cart which Prestasop Full Page Cache can't cache.

     

    I love your module and have been using it. It gives great speed! But I think it can be even faster for those Prestashop owner who run Zend opCache or APC on their server which uses the RAM to cache PHP. 

     

    Is it possible to provide guides on how to get opCache/APC to cache the cache that Prestashop Full Page Cache module has already cached in the /cache/pagecache/ folder instead of caching the individual PHP that makes up the HTML? That way, it means the the cached page by the module is read from RAM (which is super fast) and sends it out to browser.

  6. Turn off the full page cache module that is more than likely your problem. 

    1. I tried turning it off. It didn't help. I zoomed down the possibility and it has to do with choosing the caching system in Prestashop BO (memcached, APC, etc). The moment it's changed, the problem occur and I have to wait it out for the site to return to normal working state.

     

    2. Also, when I do get APC to work, somehow APC keeps flushing itself. I see the fragmentation there once APC caching system is selected but after a few refresh at apc.php, the cache flushes itself making APC useless. Hit and Miss returns to 1 and 0 respectively. The uptime always shows 0 minutes. I have checked that the timezone used in php.ini and my server timezone (via SSH date check) is the same. So there is no time difference.

     

    I followed your APC config and a few others (since yours didn't work for me). Also tried to play around with the settings, it still auto flushes itself every 2-5 secs or so:

     

    https://drupal.org/node/1777090

    http://blog.dh42.com/fastest-prestashop/

    http://www.vionblog.com/biggest-apc-configuration-mistake/

    http://www.cyberciti.biz/faq/linux-unix-php-warning-unable-to-allocate-memory-for-pool/

     

    3. I also noticed setting apc.mmap_file_mask="/var/tmp/apc.XXXXXX" creates tonnes of i/o for my hosting account. It maxed out my allowed i/o usage, making the whole site sluggish. How does this work?

     

    Anyone out there to help?

  7. There is no reason it would cause the rewrite to fail. I would try generating a new htaccess file. 

     

    The redirect issue that nils-H was talking about is because he has debug profiling enabled. 

    The weird thing is that it gets magically fixed over time. Changing the htaccess may not work since it hasn't been touched as I can see. It's the same as when it was in working condition.

     

    Could any of the APC ttl cause this? I'm not sure how.

  8. After running in staging for a while, these are the steps I have taken to (try to) improve the site speed:

     

    • - Run with FastCGI/PHP-FPM, connecting to file socket instead of tcp
    • - Add subdomain redirects to static files, and adding them as media servers, so the concurrency of the browser increases (it doesnt offload my server though)
    • - Install mod_pagespeed

     

    I think the performance is better now, although the pingdom-tool does report quite high page load speeds. I think that is related to some javascripts that run asynchronously though. The score is now 79. I did try to enable APC, but that didn't give any noticable increase in performance for me, and it also resulted in some strange redirect problems. Basically, all page loads resulted in an intedmediate "this page has been moved" page being displayed. So I have not dared enabling it in my production site.

     

    The only really big annoyance performance wise now is the incredibly slow saving of combination products, but I fear that is a core prestashop issue, not something that can be tuned.

     

    I am also getting 404 after activating APC on prestashop. Accept for the homepage, all other pages get 404. Setting APC as disabled by turning off cache also does not resolve the 404. The 404 somehow gets resolved magically over time (a few hours). I retested this several time.

     

    Any reason why APC is causing URL rewrite to fail?

  9. Found this. Did it work for everyone without issues?

     

    http://blog.dh42.com/fastest-prestashop/

    include "/usr/local/varnish/etc/varnish/cpanel.backend.vcl";
    include "/usr/local/varnish/etc/varnish/vhost.vcl";
     
    sub vcl_recv {
    set req.backend = default;
    include "/usr/local/varnish/etc/varnish/acl.vcl";
    include "/usr/local/varnish/etc/varnish/vhost.exclude.vcl";
    set req.grace = 5m;
     
       # Handle IPv6
       if (req.http.Host ~ "^ipv6.*") {
            set req.http.host = regsub(req.http.host, "^ipv6\.(.*)","www\.\1");
       }
     
        # Sanitise X-Forwarded-For...
        remove req.http.X-Forwarded-For;
        set req.http.X-Forwarded-For = client.ip;
         include "/usr/local/varnish/etc/varnish/cpanel.url.vcl"; 
        # Remove has_js and Google Analytics cookies.
        set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(__[a-z]+|has_js)=[^;]*", "");
     
        # Normalize the Accept-Encoding header
        if (req.http.Accept-Encoding) {
            if (req.url ~ "\.(jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|flv|pdf|ico)$") {
                # No point in compressing these
                remove req.http.Accept-Encoding;
            } elsif (req.http.Accept-Encoding ~ "gzip") {
                set req.http.Accept-Encoding = "gzip";
            } elsif (req.http.Accept-Encoding ~ "deflate") {
                set req.http.Accept-Encoding = "deflate";
            } else {
                # unknown algorithm
                remove req.http.Accept-Encoding;
            }
        }
     
    include "/usr/local/varnish/etc/varnish/url.exclude.vcl"; 
        # Ignore empty cookies
        if (req.http.Cookie ~ "^\s*$") {
            remove req.http.Cookie;
        }
     
              if (req.request == "PURGE") {
            if (!client.ip ~ acl127_0_0_1) {error 405 "Not permitted";}
            return (lookup);
    }
     
        if (req.request != "GET" &&
           req.request != "HEAD" &&
           req.request != "POST" &&
           req.request != "PUT" &&
           req.request != "PURGE" &&
           req.request != "DELETE" ) {
        return (pipe);    
    }
     
        if (req.request != "GET" && req.request != "HEAD") {
            /* We only deal with GET and HEAD by default, the rest get passed direct to backend */
            return (pass);
        }
     
    if (req.http.Cookie ~ "^\s*$") {
            unset req.http.Cookie;
    }
     
        if (req.http.Authorization || req.http.Cookie) {
            return (pass);
        }
     
    set req.url = regsub(req.url, "\.js\?.*", ".js");
    set req.url = regsub(req.url, "\.css\?.*", ".css");
    set req.url = regsub(req.url, "\.jpg\?.*", ".jpg");
    set req.url = regsub(req.url, "\.gif\?.*", ".gif");
    set req.url = regsub(req.url, "\.swf\?.*", ".swf");
    set req.url = regsub(req.url, "\.xml\?.*", ".xml");
     
    # Cache things with these extensions
    if (req.url ~ "\.(js|css|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|pdf)$" && ! (req.url ~ "\.(php)") ) {
        unset req.http.Cookie;
        return (lookup);
    }
     
    return (lookup);
    }
     
    sub vcl_fetch {
     
    set beresp.ttl = 45s;
    set beresp.http.Server = " - ApacheBooster";
    set beresp.http.cache-control = "max-age=90000";
    set beresp.do_gzip = true;
    set beresp.do_gunzip = false;
    set beresp.do_stream = false;
    set beresp.do_esi = false;
     
    set beresp.grace = 5m;
     
    unset beresp.http.expires;
    if (req.url ~ "\.(js|css|jpg|jpeg|png|gif|gz|tgz|bz2|tbz|mp3|ogg|swf|pdf|ico)$" && ! (req.url ~ "\.(php)") ) {
            unset beresp.http.set-cookie;
           include  "/usr/local/varnish/etc/varnish/static_file.vcl";
    }
    else {
             include  "/usr/local/varnish/etc/varnish/dynamic_file.vcl";
    }
     
    if (beresp.status == 503 || beresp.status == 500) {
            set beresp.http.X-Cacheable = "NO: beresp.status";
            set beresp.http.X-Cacheable-status = beresp.status;
            return (hit_for_pass);
    }
     
    if (beresp.status == 404) {
            set beresp.http.magicmarker = "1";
            set beresp.http.X-Cacheable = "YES";
            set beresp.ttl = 20s;
            return (deliver);
    }
     
    set beresp.http.magicmarker = "1";
    set beresp.http.X-Cacheable = "YES";
     
    }
    sub vcl_deliver {
     
    if ( obj.hits == 0 ) {
      set req.http.X-Stats-HitMiss = "miss";
     } else {
      set req.http.X-Stats-HitMiss = "hit";
     }
     
    }
    # what files to cache
    sub vcl_recv {
       if (req.url ~ "\.(png|gif|jpg|ico|txt|swf|css|js)$") {
          return(lookup);
       }
    }
     
    # strip the cookie before the image is inserted into cache
    sub vcl_fetch {
       if (req.url ~ "\.(png|gif|jpg|swf|css|js)$") {
          unset beresp.http.set-cookie;
        unset req.http.Cookie;
     remove req.http.Cookie;
       }
    }
     
    # add response header to see if document was cached
    sub vcl_deliver {
       if (obj.hits > 0) {
          set resp.http.X-Cache = "HIT";
       } else {
          set resp.http.X-Cache = "MISS";
       }
    }
    
  10. Facebook has bought over Instagram. This would have been useful if it picks up hashtags from Facebook, Instagram and Tumblr. We have customers submission via any of this 3 social media and we are manually inserting the pictures to our product pages. Can't use your module until it is made available for social media platforms that uses hashtags.

     

    If you do expand to other platforms, make sure you have a feature that detects duplicate product image and exclude it. Eg. If duplicate image, show only FB photo, etc. Because most Instagram media managers would set the pictures to auto share to Facebook which creates duplicate post to this module. This can happen for any combination of platform.

     

    Lastly, make this module cheap and affordable. You will gain more user traction. The more users are on, the more it will spread as other prestashop owners will encounter such concept and want one for themselves. Please make its white label though. Brands want to take ownership of their site.

  11. Save yourself some money, don't get any modules from Ebewe.

     

    This guy is just a hit and run. No support provided if you have any issues with module. Not even a courtesy reply. Reads the email I sent on his Win Firefox and just ignores it.

     

    If you fell for the 20% discount too bad. If you are considering to buy any of his store module, consider again because I think he has too few sales and "abandoned" the Prestashop business. 

     

    Until he replies my emails, I would not recommend.

     

    Everything has been worked out. Paul eventually got back to me after his busy schedule and we sorted everything out. I'm enjoying the Autocomplete module. You guys should try it, it's pretty smart.

  12. WOW Falgener! You are the man! Now I feel super productive! Works with even foreign characters.

     

    This module is super feature packed. For the amount of money you spend buying and what it offers, it's a no brainer. Thanks for a cheap and value for money module with fast fantastic support and free upgrades.

     

    I can't wait to see more useful modules by you.

×
×
  • Create New...

Important Information

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