[gleb.goncharov]

So without the rules, will SEO work under nginx?

Without rules of SEO will not work.

[kogi]

Without rules of SEO will not work.

So, Can cscart (you guys) provide working Nginx config for SEO?

[gleb.goncharov]

Sure. Just example:

server {
    listen  80;
    server_name _;
    root /var/www/empty;
    location / {
	    return 301 $scheme://example.org$request_uri;
    }
}
server {
    listen  80;
    server_name example.org www.example.org;
    charset utf-8;
    access_log  /var/log/nginx/access.log combined;
    error_log   /var/log/nginx/error.log;
    root /var/www/html/example.org;
    gzip on;
    gzip_disable "msie6";
    gzip_comp_level 6;
    gzip_min_length  1100;
    gzip_buffers 16 8k;
    gzip_proxied any;
    gzip_types text/plain application/xml
	  application/javascript
	  text/css
	  text/js
	  text/xml
	  application/x-javascript
	  text/javascript
	  application/json
	  application/xml+rss;
    client_max_body_size		    100m;
    client_body_buffer_size		 128k;
    client_header_timeout		   3m;
    client_body_timeout			 3m;
    send_timeout				    3m;
    client_header_buffer_size	   1k;
    large_client_header_buffers	 4 16k;
    location / {
	    root /var/www/html/example.org;
	    index  index.php index.html index.htm;
	    rewrite ^/api/(.*)$ /api.php?_d=$1&ajax_custom=1&$args last;
	    try_files $uri $uri/ @fallback;
    }
    location @fallback {
	    rewrite  ^(.*)$ /index.php?$args last;
    }
    location ~* \.(jpeg|ico|jpg|gif|png|css|js|pdf|txt|tar|gz|wof|csv|zip|xml|yml) {
	    access_log off;
	    try_files $uri @statics;
	    expires 14d;
	    add_header Access-Control-Allow-Origin *;
	    add_header Cache-Control public;
	    root /var/www/html/example.org;
    }
    location @statics {
	    rewrite ^/(\w+)/(.*)$ /$2 break;
	    access_log off;
	    rewrite_log off;
	    expires 14d;
	    add_header Cache-Control public;
	    add_header Access-Control-Allow-Origin *;
	    root /var/www/html/example.org;
    }
    location ~ \.php$ {
	    root /var/www/html/example.org;
	    proxy_read_timeout 61;
	    fastcgi_read_timeout 61;
	    try_files $uri $uri/ =404;
	    fastcgi_pass unix:/var/run/php5-fpm.sock;
	    fastcgi_index index.php;
	    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
	    include fastcgi_params;
    }
    location /app/ {
	    deny all;
	    location ^~ /app/addons/rus_exim_1c/exim_1c.php {
		    allow all;
	    }
    }
    location /app/payments/ {
	    allow all;
    }
    location /design/ {
	    allow all;
	    location ~* \.([tT][pP][lL]|[pP][hH][pP].?)$ {
		    deny all;
	    }
    }
    location /images/ {
	    allow all;
	    location ~* \.([pP][hH][pP].?)$ {
		    deny all;
	    }
    }
    location /var/ {
	    deny all;
	    location ~* \.(js|css|png|jpg|gz|xml|yml)$ {
		    allow all;
		    expires 1M;
		    add_header Cache-Control public;
		    add_header Access-Control-Allow-Origin *;
	    }
    }
    location /var/database/ {
	    deny all;
    }
    location /var/skins_repository/ {
	    allow all;
	    location ~* \.([tT][pP][lL]|[pP][hH][pP].?)$ {
		    deny all;
	    }
    }
    location ~* api/ {
	    rewrite ^/api/(.*)$ /api.php?_d=$1&ajax_custom=1&$args last;
    }
    location ~ /\.ht {
	    deny  all;
    }
}

[kogi]

@goncharov

Thanks, you are the best!

[P-Pharma]

I mean on the Internet there is no independent research of performance, with the exception of tests LitespeedTech where LS wins an incorrectly configured NGINX and Apache. In my opinon, presented on the official website of the benchmarks are ridiculous and not objective. I urge people not to take their word.

I find your statements a little strange because one Google search will give you many independent benchmarks for litespeed. Here are a few from the first google page:
http://centminmod.co...d_cherokee.html
http://vbtechsupport.com/2204/
http://www.webhostin...d.php?t=1024547
http://www.vbulletin...orge-l/3929797-
http://www.beyondcod...and-plain-html/
http://www.rootusers...ance-benchmark/
http://www.rubyenter...omparisons.html

This puts the benchmarks of litespeedtech into perspective: http://openlitespeed...-benchmarks.59/
Maybe your opinion on litespeed benchmarks is based on the situation years ago? BUt since then many people have done benchmarks and it came out very good.

Basically what it boils down to is that NGINX and LSWS are pretty on par with each other in terms of performance. LSWS has the benefit that its much easier to configure and has a lot of extra functions. For a very technical webmaster NGINX can be more appealing.

Based on these independent benchmarks we became interested in litespeed years ago. To see if it would as well for us, we did our own benchmarks to see the difference between Apache and LSWS. The difference was amazing. It was one of the best decisions ever to move to LiteSpeed. It saves us a lot of money in hosting costs and our websites are much faster do to litespeed cache. Except CS-Cart that is.

[kickoff3pm]

I think bench marking is pointless if you go by other peoples results. It's like looking for one spasific pea in a can of peas. And for me setting my own bench marking is a waste of time given that even the best results won't give more then a 10% gain like for like hardware, hosting and cs-cart setting. And on any given day the 10% gain, even if you do get it, can be and will be wiped out for any number of reasons you can do nothing about.

[P-Pharma]

Its way more than a 10% gain. Its a difference of loading pages in seconds or fractions of seconds. Mind that the Nielsen has researched that customers start leaving if a page takes longer than 1 second to load. And thats what CS-Cart still does. Even after the amazing and very welcome improvement we have with 4.3.
The main speed improvement comes from litespeed cache or ESI. It also allows you to use usergroups. So that your logged in customers are treated differently than guests.

All guests get the same static cache which is refreshed every minute or so (depends on your settings) So database queries are extremely reduced. For example: if you have 1000 users online then normally they would query the database for every page load and in-page data request. So thats 1000 times the same queries. If 90% of those users are guests and it would be cached with LSWS cache then the queries of 900 of those users would be treated as 1 single user. That's a massive difference.

[kickoff3pm]

Well sorry but if that's what Nielsen say then they don't know what they are talking about. Sheer logic says that if you go shopping you at least want to look at the goods and so to suggest people wouldn't wait one second is just a daft comment. There own ISP connection could amount for far more then that. You can only affect what you can control hence my 10% comment. No web site loads at the same pace everytime all we can do is do our best.

Naturally a lot depends on the traffic your site attracts but very quickly then you move away from single server configuration and thats what I thought we were discussing here.

[gleb.goncharov]

Basically what it boils down to is that NGINX and LSWS are pretty on par with each other in terms of performance. LSWS has the benefit that its much easier to configure and has a lot of extra functions. For a very technical webmaster NGINX can be more appealing.

Based on these independent benchmarks we became interested in litespeed years ago. To see if it would as well for us, we did our own benchmarks to see the difference between Apache and LSWS. The difference was amazing. It was one of the best decisions ever to move to LiteSpeed. It saves us a lot of money in hosting costs and our websites are much faster do to litespeed cache. Except CS-Cart that is.

I'm not sure that LS performs better than NGINX. Anyway, the CS-Cart team should conduct independent tests to dispel the doubts. Probably, I'm mistaken. However, there is no point in continuing to argue about this in this thread.

[jackyboy]

Isn't speed all about the end result? These results are using nginx, and eaccelerator. Cs- 2.24

Attached Thumbnails

• 

[johnbol1]

Well sorry but if that's what Nielsen say then they don't know what they are talking about. Sheer logic says that if you go shopping you at least want to look at the goods and so to suggest people wouldn't wait one second is just a daft comment. There own ISP connection could amount for far more then that. You can only affect what you can control hence my 10% comment. No web site loads at the same pace everytime all we can do is do our best.

Naturally a lot depends on the traffic your site attracts but very quickly then you move away from single server configuration and thats what I thought we were discussing here.

agreed, too much paranoia about speed, after a certain amount minimal gains count for nothing

[kickoff3pm]

Isn't speed all about the end result? These results are using nginx, and eaccelerator. Cs- 2.24

Well if you are creating a site for people who sit on that site and produce speed reports you should be happy. In the real world they mean almost nothing. Your customers will arrive from all sorts of places, using all sorts of methods and landing mostly on inside pages. They'll also have many different intentions for doing that and for most sites it won't be their first visit so your speed testing for a very very limited target. Not saying these site don't have value but for example if one page on your site loads very slow and thats the one with the best vistor count to earnings then you'll never realise that from those reporting sites.

[kogi]

So, I did all that, with nginx. Still only got 3 seconds on the front page. I might have to turn file caching on in nginx.

[gleb.goncharov]

So, I did all that, with nginx. Still only got 3 seconds on the front page. I might have to turn file caching on in nginx.

What version of CS-Cart are you using? How many products and categories on your store? Could you provide specifications of the server (CPU, RAM, Storage)?

[kickoff3pm]

So, I did all that, with nginx. Still only got 3 seconds on the front page. I might have to turn file caching on in nginx.

I get that result without nginx or doing anything special. A:95 B:89

[kogi]

What version of CS-Cart are you using? How many products and categories on your store? Could you provide specifications of the server (CPU, RAM, Storage)?

Cscart. Latest
Vps
4cpu / 2gb ram
Demo database

[kogi]

I get that result without nginx or doing anything special. A:95 B:89

It's more about the Ttfb and pageload times. Cs demo server serves up a page in 2 seconds

[kogi]

Hey goncharov

Slight Problem with the config file, but it's got me stumped

	location /app/ {
			deny all;
			location ^~ /app/addons/rus_exim_1c/exim_1c.php {
					allow all;
			}
	}

I can still access php files in the /app/ subdirectories
Should it be?

location ^~ /app/ {

Also location /var/skins_repository/ should be /var/themes_repository/

[ghostrider]

Hey goncharov

The Watermark addon has some rules for Apache to protect the original images. How to translate it for Nginx?

[gleb.goncharov]

Hey goncharov

Slight Problem with the config file, but it's got me stumped

I refactored the configuration. Please, let me know about the errors.
Important: storefronts in the subdirectories does not work.

server {
    listen  80;
    server_name _;

    charset utf-8;
    set $root "/var/www/html";

    access_log  /var/log/nginx/access.log combined;
    error_log   /var/log/nginx/error.log;

    gzip on;
    gzip_disable "msie6";
    gzip_comp_level 6;
    gzip_min_length  1100;
    gzip_buffers 16 8k;
    gzip_proxied any;
    gzip_types text/plain application/xml
          application/javascript
          text/css
          text/js
          text/xml
          application/x-javascript
          text/javascript
          application/json
          application/xml+rss;

    client_max_body_size         100m;
    client_body_buffer_size      128k;
    client_header_timeout          3m;
    client_body_timeout            3m;
    send_timeout                   3m;
    client_header_buffer_size      1k;
    large_client_header_buffers  4 16k;

    error_page 598 = @backend;

    location @backend {
        root $root;
        proxy_read_timeout 61;
        fastcgi_read_timeout 61;
        try_files $uri $uri/ =404;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location / {
        if (-f $root/maintenance) {
            return 503;
        }
        root $root;
        index  index.php index.html index.htm;
        rewrite ^/api/(.*)$ /api.php?_d=$1&ajax_custom=1&$args last;
        try_files $uri $uri/ @fallback;
    }

    location @fallback {
        rewrite  ^(.*)$ /index.php?$args last;
    }

    location ~* \.(jpeg|ico|jpg|gif|png|css|js|pdf|txt|tar|wof|csv|zip) {
        access_log off;
        try_files $uri @statics;
        expires 14d;
        add_header Access-Control-Allow-Origin *;
        add_header Cache-Control public;
        root /var/www/html;
    }

    location @statics {
        rewrite ^/(\w+)/(.*)$ /$2 break;
        access_log off;
        rewrite_log off;
        expires 14d;
        add_header Cache-Control public;
        add_header Access-Control-Allow-Origin *;
        root /var/www/html;
    }

    location ~ /(index|admin|api).php {
        return 598;
    }

    location = /install/index.php {
        return 598;
    }

    location ^~ /app/ {
        return 404;
        location = /app/addons/rus_exim_1c/exim_1c.php {
            return 598;
        }
    }

    location ^~ /app/payments/ {
        return 404;
        location ~ \.php$ {
            return 598;
        }
    }

    location ^~ /var/database/ {
	return 404;
    }

    location ~* \.([pP][hH][pP]|[tT][pP][lL].?)$ {
        return 404;
    }

    location ~ /\.(ht|git) {
        return 404;
    }
}