Any plans to "officially" support installation using Nginx?
Permalink 2 users found helpful
This page only mentions Apache and IIS:
http://www.concrete5.org/documentation/background/system_requiremen...
Do the core c5 developers plan test/document/recommend the use of Nginx?
http://www.concrete5.org/documentation/background/system_requiremen...
Do the core c5 developers plan test/document/recommend the use of Nginx?
"Nginx may not be as well-known as Apache and IIS, but it does not seem that will be the case for much longer. Its low resource, fast performance design is attracting adopters from Facebook to Dropbox."
http://www.cmswire.com/cms/web-cms/nginx-continues-its-rise-to-the-...
http://www.cmswire.com/cms/web-cms/nginx-continues-its-rise-to-the-...
Totally for competition and all, just looking at how we want to spend
the rather limited time in our day. If we wanted to spend any more of
it being server experts, you'd see us work harder to support IIS as
there's a lot of money tied up in wimblows.
Today concrete5 works on IIS, but we don't have the expertise in house
to recommend people use it in a production environment. If we're
talking business decisions, that'd be wise for us to explore.
But like I said, go for it! More platforms concrete5 works well on, the better!
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
the rather limited time in our day. If we wanted to spend any more of
it being server experts, you'd see us work harder to support IIS as
there's a lot of money tied up in wimblows.
Today concrete5 works on IIS, but we don't have the expertise in house
to recommend people use it in a production environment. If we're
talking business decisions, that'd be wise for us to explore.
But like I said, go for it! More platforms concrete5 works well on, the better!
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz
Which web servers are officially supported? Just Apache and IIS?
Why is the web server so important for Concrete5? After all it is an web application running on top of PHP. Right? Why is it so important what web server it runs on?
Why is the web server so important for Concrete5? After all it is an web application running on top of PHP. Right? Why is it so important what web server it runs on?
It's really not. You can likely run concrete5 on any webserver that
supports PHP and MySQL. You might have some issues getting Pretty URLs
to work, or other details - but there's really nothing major that
should get in your way.
I believe what is being asked is will we provide support, testing and
documentation for how to best configure it for these platforms. Will
we go through the process of making sure any new versions of concrete5
work well on platform X. That's where things get tricky for us,
there's only so much time in the day and money in the bank. That being
said, it's open source - let's make it work on whatever, together!
supports PHP and MySQL. You might have some issues getting Pretty URLs
to work, or other details - but there's really nothing major that
should get in your way.
I believe what is being asked is will we provide support, testing and
documentation for how to best configure it for these platforms. Will
we go through the process of making sure any new versions of concrete5
work well on platform X. That's where things get tricky for us,
there's only so much time in the day and money in the bank. That being
said, it's open source - let's make it work on whatever, together!
I can easily provide you a working configuration for nginx. The problem for me is that I am not a user of the CMS. I just provide it to others (if they want it) and that's all. So for me it is like a small black box. I have no clue how it is working internally. So getting it to work was ultra giga easy in nginx. But then I get complains that things don't work and deliver error 404. Just to name one:
URI: /index.php/tools/required/i18n_js/......
In reality that should go to /concrete/tools/i18n_js/......
So there I am. I am again needing to write rules for that:
Okay. That works until the user using the CMS tells me that you can overwrite everything in Concrete5 by creating your own file system structure without the /concrete/ directory. Okay. Then again I am changing configuration:
This again works until the user using the CMS is telling me that you can install things in Concrete5 by using some kind of package manager and the things are then on the file system in /packages/....
And again I need to change configuration. And this is then the moment where I ask my self: WTF is going on? Where is that special behaviour mentioned? Why do I have to write so much rewrite/try_file rules for something so simple like a CMS? Why is this CMS so special and needs so much rules on the server?
All I would like to have is a central place where I can easily and quickly read about the 'special' behaviour of Concrete5. Does something like that exist?
URI: /index.php/tools/required/i18n_js/......
In reality that should go to /concrete/tools/i18n_js/......
So there I am. I am again needing to write rules for that:
location ~ ^/index\.php/tools/required/(.+) { try_files /concrete/tools/$1 $uri; }
Okay. That works until the user using the CMS tells me that you can overwrite everything in Concrete5 by creating your own file system structure without the /concrete/ directory. Okay. Then again I am changing configuration:
location ~ ^/index\.php/tools/required/(.+) { try_files /tools/$1 /concrete/tools/$1 $uri; }
This again works until the user using the CMS is telling me that you can install things in Concrete5 by using some kind of package manager and the things are then on the file system in /packages/....
And again I need to change configuration. And this is then the moment where I ask my self: WTF is going on? Where is that special behaviour mentioned? Why do I have to write so much rewrite/try_file rules for something so simple like a CMS? Why is this CMS so special and needs so much rules on the server?
All I would like to have is a central place where I can easily and quickly read about the 'special' behaviour of Concrete5. Does something like that exist?
I think we can help each other;
1) Amend the 'System Requirements' page to say that you primarily develop/test/approve on Apache, but the system should work on any webserver supporting php. Its known to work on IIS, Nginx and others. See the below document.
2) Lets make a document (assuming it does not exist) that describes the rewrites required to make c5 work with or without pretty urls if not using Apache. This document can then be used by any systems administrator to setup c5 on any webserver (in theory).
For example the themes folder could be located in:
/themes
/packages/[theme_name?]/themes
/concrete/themes
or tools could be located in:
/tools
/packages/[tool_name?]/tools
/concrete/tools
That all sounds logical, but then I see requests to:
/index.php/tools/required/i18n_js.php
/index.php/tools/required/page_controls_menu_js.php
Arh! Where did that '/required/' come from?
Currently I'm working my way through these rewrite rules one-by-one.
Does such a document already exist?
1) Amend the 'System Requirements' page to say that you primarily develop/test/approve on Apache, but the system should work on any webserver supporting php. Its known to work on IIS, Nginx and others. See the below document.
2) Lets make a document (assuming it does not exist) that describes the rewrites required to make c5 work with or without pretty urls if not using Apache. This document can then be used by any systems administrator to setup c5 on any webserver (in theory).
For example the themes folder could be located in:
/themes
/packages/[theme_name?]/themes
/concrete/themes
or tools could be located in:
/tools
/packages/[tool_name?]/tools
/concrete/tools
That all sounds logical, but then I see requests to:
/index.php/tools/required/i18n_js.php
/index.php/tools/required/page_controls_menu_js.php
Arh! Where did that '/required/' come from?
Currently I'm working my way through these rewrite rules one-by-one.
Does such a document already exist?
This here is for sure wrong!
For example the themes folder could be located in:
/themes
/packages/[theme_name?]/themes
/concrete/themes
As far as I can tell the theme paths are (for example lets call the theme 'omega'):
/themes/omega/...
/packages/theme_omega/themes/omega/...
/concrete/themes/omega/...
Or to use your naming convention:
/themes/[theme name]/...
/packages/theme_[theme name]/themes/[theme name]/...
/concrete/themes/[theme name]/...
IMHO this is totally frustrating to find out the inner working of Concrete5 by waiting and babysitting it all the time and watching the error log for those stupid 404 issues and fix them. I hate that. My time is valuable too. I have no time to sit all day and try to magically find out what is going on.
For example the themes folder could be located in:
/themes
/packages/[theme_name?]/themes
/concrete/themes
As far as I can tell the theme paths are (for example lets call the theme 'omega'):
/themes/omega/...
/packages/theme_omega/themes/omega/...
/concrete/themes/omega/...
Or to use your naming convention:
/themes/[theme name]/...
/packages/theme_[theme name]/themes/[theme name]/...
/concrete/themes/[theme name]/...
IMHO this is totally frustrating to find out the inner working of Concrete5 by waiting and babysitting it all the time and watching the error log for those stupid 404 issues and fix them. I hate that. My time is valuable too. I have no time to sit all day and try to magically find out what is going on.
I know nothing about nginx, but it looks like you may be making life too complicated for yourself.
C5 sorts out all file overrides internally, so you don't need to have any rewrite or searching rules for it. By including such rules, I suspect you will be breaking the prioritisation that C5 sets and hence causing a cascade of errors that you are now rushing to fix.
The .htaccess in Apache is usually trivial, for example:
After that, C5 scans through a few server variables to get the request info, and again does everything else internally.
C5 sorts out all file overrides internally, so you don't need to have any rewrite or searching rules for it. By including such rules, I suspect you will be breaking the prioritisation that C5 sets and hence causing a cascade of errors that you are now rushing to fix.
The .htaccess in Apache is usually trivial, for example:
# -- concrete5 urls start -- <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME}/index.html !-f RewriteCond %{REQUEST_FILENAME}/index.php !-f RewriteRule . index.php [L] </IfModule> # -- concrete5 urls end --
After that, C5 scans through a few server variables to get the request info, and again does everything else internally.
You are funny. Do you think that I have not mirrored that trivial .htaccess functionality already? I have and it still does not work. I get those 404 and therefore I have to do the rewrites I have mentioned above.
What do you mean with 'scans through a few server variables'? What variables are they and how do they influence C5? Is there any documentation about that? Maybe providing C5 with the proper 'server variables' would be easier than writing those rewrite/try_file rules?
Are you writing about CGI variables and/or PHP variables?
What do you mean with 'scans through a few server variables'? What variables are they and how do they influence C5? Is there any documentation about that? Maybe providing C5 with the proper 'server variables' would be easier than writing those rewrite/try_file rules?
Are you writing about CGI variables and/or PHP variables?
CGI Variables (which in some cases get mapped to php variables by php)
A quick search for nginx in the C5 forums reveals plenty who have done it who have posted details of their configurations. I couldn't find any trying to replicate C5 overrides in the nginx configuration like you are. Many appear to be mapping a handful of CGI variable names from nginx variables.
A quick search for nginx in the C5 forums reveals plenty who have done it who have posted details of their configurations. I couldn't find any trying to replicate C5 overrides in the nginx configuration like you are. Many appear to be mapping a handful of CGI variable names from nginx variables.
Could you post one or two such links where people are mapping variables.
btw: I do those mappings too. Ningx has that mapping out of the box.
btw: I do those mappings too. Ningx has that mapping out of the box.
All I did was enter nginx in the search box and click in and out of the first couple of pages of results:
http://www.concrete5.org/community/forums/-/view/?sort=relevance&am...
http://www.concrete5.org/community/forums/-/view/?sort=relevance&am...
Thanks for the link. I read all the messages and none of them is helpful to me. Most of them have issues with PATH_INFO and such but I don't have that issue. I am properly having that variable assigned even without using cgi.fix_pathinfo.
Anyway... I think I can work around the problem described above by changing how PHP is called. Unfortunately I can not test it right now since I am out of office. Will however test after work and let you know if my idea worked or not.
Anyway... I think I can work around the problem described above by changing how PHP is called. Unfortunately I can not test it right now since I am out of office. Will however test after work and let you know if my idea worked or not.
Seems like we found a different way to approach the problem. it seems to be working without a gazillion rewrite rules. I'll test it over the next days and report back!
Who is "we"?
This nginx config has worked for me so far... it's possible I've just not been bitten yet but I figured I'd get the suggestion out there:
location / {
if (!-f $request_filename){
set $rule_0 a;
}
if (!-f $request_filename/index.html){
set $rule_0 b$rule_0;
}
if (!-f $request_filename/index.php){
set $rule_0 c$rule_0;
}
if ($rule_0 = "cba"){
rewrite /. /index.php last;
}
index index.html index.htm index.php;
}
Along with a pretty standard php.conf setup with php-fpm.
location / {
if (!-f $request_filename){
set $rule_0 a;
}
if (!-f $request_filename/index.html){
set $rule_0 b$rule_0;
}
if (!-f $request_filename/index.php){
set $rule_0 c$rule_0;
}
if ($rule_0 = "cba"){
rewrite /. /index.php last;
}
index index.html index.htm index.php;
}
Along with a pretty standard php.conf setup with php-fpm.
Ohhh boy. That config is crying for trouble. Those if's look like you used the automatic tool on the web that transforms Apache's .htaccess into nginx rewrite rules. It is very bad. Bad, bad, bad. Read here why ->http://wiki.nginx.org/IfIsEvil
You should use other techniques available to nginx that are way better then using if's.
Something like this here (not full config but you get the picture):
Or if you want then use named locations:
You should use other techniques available to nginx that are way better then using if's.
Something like this here (not full config but you get the picture):
location / { try_files $uri $uri/ /index.php$request_uri /index.php; } location ~ \.php { fastcgi_split_path_info ^(.+\.php(?:[3-5])?)(/.+)$; include /etc/nginx/fastcgi_params; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/path/to/unix/socket; try_files $fastcgi_script_name =404; }
Or if you want then use named locations:
location / { try_files $uri $uri/ /index.php$request_uri /index.php; } location ~ ^(?<script_name>.+\.php(?:[3-5])?)(?<path_info>/.*)?$ { include /etc/nginx/fastcgi_params; fastcgi_param PATH_INFO $path_info; fastcgi_param PATH_TRANSLATED $document_root$path_info; fastcgi_param SCRIPT_NAME $script_name; fastcgi_param SCRIPT_FILENAME $document_root$script_name; fastcgi_pass unix:/path/to/unix/socket; try_files $script_name =404; }
for the record, this .htaccess completely bvreaks the straing-out-of-the-box dev install
seehttp://www.concrete5.org/developers/bugs/5-6-1-2/pretty-urls-not-wo...
seehttp://www.concrete5.org/developers/bugs/5-6-1-2/pretty-urls-not-wo...
I've just done some load testing on this subject, and found surprising results. Bare with me, as this was only exploratory! This testing was performed on EC2 with a small RDS (separate MySQL box in AWS) backing it.
To generate the load, I threw a hugely powerful (and ruddy expensive) Windows Server instance running JMeter at a L(A/N)MP box,
The box I ran had Apache 2.4 + APC, then I replaced this with Nginx + APC (+ PHP FastCGI Process Manager) and found that there was little difference (falling, eventually to Apache's favour!). Rough stats:
- 50 Concurrent Users -
Apache: 33% CPU Usage, Avg Response 5.1s
NGinx: 31.2% CPU Usage, Avg Response 5.4s
Honestly, these aren't the results I expected or wanted to see, but Apache really cleaned up their act in their 2.4 release. I am also reading that Nginx has been accepted as slower in this scenario anyway. It comes into its own when you want to deliver static assets at lightening speeds. I wonder if Nginx can be used here? Does anyone know if there's a way to separate assets into their own subdomain (assets.website.com) for example?
Kindest Regards,
Mark
To generate the load, I threw a hugely powerful (and ruddy expensive) Windows Server instance running JMeter at a L(A/N)MP box,
The box I ran had Apache 2.4 + APC, then I replaced this with Nginx + APC (+ PHP FastCGI Process Manager) and found that there was little difference (falling, eventually to Apache's favour!). Rough stats:
- 50 Concurrent Users -
Apache: 33% CPU Usage, Avg Response 5.1s
NGinx: 31.2% CPU Usage, Avg Response 5.4s
Honestly, these aren't the results I expected or wanted to see, but Apache really cleaned up their act in their 2.4 release. I am also reading that Nginx has been accepted as slower in this scenario anyway. It comes into its own when you want to deliver static assets at lightening speeds. I wonder if Nginx can be used here? Does anyone know if there's a way to separate assets into their own subdomain (assets.website.com) for example?
Kindest Regards,
Mark
Your benchmark is just testing how well PHP is processed in Apache/nginx. This will not make nginx magically faster than Apache. For sure not with just 50 concurrent connections. Try the same thing with 1'000 concurrent connections and go up till over 10'000 concurrent connections and check the memory usage. You will see that Apache usually uses more memory than the nginx system. This is manly because Apache users often use the pre-fork MPM and together with mod_php you will end up in more memory used than in the typical nginx + php-fpm combo. Even if you use another MPM than pre-fork you will end in more memory (and indirectly more CPU power) used with mod_php.
To say it in other words: nginx usually uses +/- less resources than Apache to deliver the same result.
This does not say anything about speed. Apache 2.4 has made huge improvements regarding speed. But most users using something other than Apache usually do that because of other reasons than speed. If Apache would be so snail slow, it would never get that widely accepted as it is today.
And on top of that: You can easily use PHP over FCGI/CGI in Apache too and reduce the memory footprint of Apache. But one Apache instance will most likely use more resources than something so lean as nginx. So the more instances you run the more likely you will benefit from using nginx. Or if you run a system with very limited resources then using nginx, Cherokee, Lighttpd, etc will more likely be a better solution than using Apache.
To say it in other words: nginx usually uses +/- less resources than Apache to deliver the same result.
This does not say anything about speed. Apache 2.4 has made huge improvements regarding speed. But most users using something other than Apache usually do that because of other reasons than speed. If Apache would be so snail slow, it would never get that widely accepted as it is today.
And on top of that: You can easily use PHP over FCGI/CGI in Apache too and reduce the memory footprint of Apache. But one Apache instance will most likely use more resources than something so lean as nginx. So the more instances you run the more likely you will benefit from using nginx. Or if you run a system with very limited resources then using nginx, Cherokee, Lighttpd, etc will more likely be a better solution than using Apache.
I still have an ancient c5 version running on nginx without any problems. I stopped using it as it couldn't get much benefits from it and using a widely known webserver every employee of mine knows how to use seemed to be the better choice.
But anyways, I didn't need much magic. The following config is basically everything that I needed:
But anyways, I didn't need much magic. The following config is basically everything that I needed:
if (!-f $document_root$fastcgi_script_name) { rewrite (.*) /index.php/$1 break; }
Hoi Remo,
read my comment why that 'if' is not good and how to make it better ->http://www.concrete5.org/community/forums/chat/any-plans-to-officia...
Gruess us Züri
// Steve
read my comment why that 'if' is not good and how to make it better ->http://www.concrete5.org/community/forums/chat/any-plans-to-officia...
Gruess us Züri
// Steve
Hey Steve, I've read that post but I don't see why my configuration should be evil. The article you've linked that doesn't that you mustn't use if's, it also says that there are situations where it's actually safe to use!
You can't see it in my one line snippet but since it's the last statement I need, it basically works like "rewrite ... last" which is listed under "The only 100% safe things".
I see the point why we should avoid if's in general but I don't see why my configuration should be evil. I can also tell you that this server runs for several years without any interruption and has served more than just a few thousands page views..
You can't see it in my one line snippet but since it's the last statement I need, it basically works like "rewrite ... last" which is listed under "The only 100% safe things".
I see the point why we should avoid if's in general but I don't see why my configuration should be evil. I can also tell you that this server runs for several years without any interruption and has served more than just a few thousands page views..
Hi Remo. Where did you had that if? Enclosed in a location statement?
No, server
So you used FastCGI variables inside a server {} block without knowing if the request was a FastCGI request. Really?
Yes. Can you please be a bit more elaborate instead of just telling everyone that their configuration is bad? That would be a bit more constructive..
REMOVED!
What?
if (!-f $document_root$fastcgi_script_name) { rewrite (.*) /index.php/$1 break; }
In nginx internally the $fastcgi_script_name is set to the URI ->http://wiki.nginx.org/HttpFastcgiModule#.24fastcgi_script_name...
And later that variable gets split into $fastcgi_script_name and $fastcgi_path_info. Now if you would make a request to /index.php/my/path/whatever then the above code will in most cases look for a file named $document_root/index.php/my/path/whatever.
Better approach would be to enclose this into a location block that only handles php[3-5]? files and the do either the path splitting or work from the beginning with a regexp location and set proper PATH_INFO and SCRIPT_NAME CGI variables.
try_files is as well way more efficient than using if statements.
More info here ->http://nginx.org/en/docs/http/ngx_http_core_module.html#try_files...
All right thanks, I see what you mean! I don't think that will ever happen on my site but if we wanted to have a "best practice" solution for nginx why should certainly consider this.
I guess I'll leave it up to you to come up with the perfect nginx configuration for concrete5 as you definitely know more about nginx than I do.
Don't take it personally, but this is kind of bad advertising for nginx. I understand why they still support all kind of if's but if you have to read/know that much to properly configure nginx I'm glad I'm stuck with apache.
I guess I'll leave it up to you to come up with the perfect nginx configuration for concrete5 as you definitely know more about nginx than I do.
Don't take it personally, but this is kind of bad advertising for nginx. I understand why they still support all kind of if's but if you have to read/know that much to properly configure nginx I'm glad I'm stuck with apache.
I don't take it personally. Why should I?
Regarding nginx: The problem is that to many people out there have no clue about web servers and such and then they go on and hear that this ultra fancy giga super dupper lean web server called nginx is the next cool thing and if you want to be cool and 31337 then you have to install that beast. It is going to fly so fast that Apache and IIS and all the others have no chance to catch up. Ever!
So they install it on their server and go on and read some where on the net how to configure it. They blindly copy configuration snippets from all over the web without really knowing what they do. And then they start up their web server and do a bunch of requests and it seams to work. That is all what counts for them. They never ever are going to touch it again. They don't care if they are open for attacks or anything other. They don't care as long as they don't get officially owned by some hacker group or they don't get their php code changed to server malicious code. When that happens then they are the first to cry out loud about how bad nginx is, how bad php is, yadda, yadda, yadda.
You can not blame nginx for this. nginx is just a tool. It has some things in it that prevents you from shooting into your own foot but it is not the job of nginx to 100% be foolproof. It is pretty much like saying that C is a bad language because you can dereference a null pointer or you could do stupid things with pointers.
Regarding nginx: The problem is that to many people out there have no clue about web servers and such and then they go on and hear that this ultra fancy giga super dupper lean web server called nginx is the next cool thing and if you want to be cool and 31337 then you have to install that beast. It is going to fly so fast that Apache and IIS and all the others have no chance to catch up. Ever!
So they install it on their server and go on and read some where on the net how to configure it. They blindly copy configuration snippets from all over the web without really knowing what they do. And then they start up their web server and do a bunch of requests and it seams to work. That is all what counts for them. They never ever are going to touch it again. They don't care if they are open for attacks or anything other. They don't care as long as they don't get officially owned by some hacker group or they don't get their php code changed to server malicious code. When that happens then they are the first to cry out loud about how bad nginx is, how bad php is, yadda, yadda, yadda.
You can not blame nginx for this. nginx is just a tool. It has some things in it that prevents you from shooting into your own foot but it is not the job of nginx to 100% be foolproof. It is pretty much like saying that C is a bad language because you can dereference a null pointer or you could do stupid things with pointers.
The extra info is really appreciated.
Seems like we could really use a community consensus wrapped up in an nginx howto.
Seems like we could really use a community consensus wrapped up in an nginx howto.
url.rewrite-if-not-file = ( "^/(.*)$" => "/index.php/$1" ) }
is all what I need to have prettyURLs in lighty. :-)
Sincerely,
Gour
I'm not saying C is a bad language, but C like any other language or tool can be a bad choice depending on what you're trying to achieve.. A configuration should imho be easy and safe.
But anyways, back to the actual topic: I strongly agree with wcravens, we should have a bunch of best practice howtos for nginx, lighty, cherokee and whatever there is one might work with.
I could do some testing or even write an article about it, but I'd need some help from the community as I don't work with anything but Apache these days!
But anyways, back to the actual topic: I strongly agree with wcravens, we should have a bunch of best practice howtos for nginx, lighty, cherokee and whatever there is one might work with.
I could do some testing or even write an article about it, but I'd need some help from the community as I don't work with anything but Apache these days!
Hi Remo,
As Apache seems to be the most common web server used with Concrete5 then I suggest starting a guide for Apache first then we can use that a template for documenting the other web servers.
I think the document should be more like a "guide" of best practices rather that saying pumping your MinSpareServers 500 is what you must do to achieve ultimate performance.
With all the options and circumstances to take into account do you think its possible to create such a guide?
ie do you want to discuss the various caching options, or do you just talk about APC?
Do you want to get into php_mod vs. fast_cgi method or just stick with php_mod?
Do you want to talk about tweaking MySQL? or how to look at the ampunt of RAM or CPU being used?
How do you measure if your server needs adjusting in some way?
Maybe a best practices guide is too broad a subject to cover within a few pages?
Paul
As Apache seems to be the most common web server used with Concrete5 then I suggest starting a guide for Apache first then we can use that a template for documenting the other web servers.
I think the document should be more like a "guide" of best practices rather that saying pumping your MinSpareServers 500 is what you must do to achieve ultimate performance.
With all the options and circumstances to take into account do you think its possible to create such a guide?
ie do you want to discuss the various caching options, or do you just talk about APC?
Do you want to get into php_mod vs. fast_cgi method or just stick with php_mod?
Do you want to talk about tweaking MySQL? or how to look at the ampunt of RAM or CPU being used?
How do you measure if your server needs adjusting in some way?
Maybe a best practices guide is too broad a subject to cover within a few pages?
Paul
Hello Paul,
this thread started about how to make Concrete5 work under nginx and now you start to talk about ultimate performance (*), tweaking MySQL, using PHP accelerators, etc....
(*) IMHO there is no such thing as 'ultimate performance'. If you run a page that gets all the time on the front page of Slashdot, Reddit, etc then for sure you have other requirements (and viewpoint about performance) than a SME running your company page on Concrete5.
this thread started about how to make Concrete5 work under nginx and now you start to talk about ultimate performance (*), tweaking MySQL, using PHP accelerators, etc....
(*) IMHO there is no such thing as 'ultimate performance'. If you run a page that gets all the time on the front page of Slashdot, Reddit, etc then for sure you have other requirements (and viewpoint about performance) than a SME running your company page on Concrete5.
I agree, first we should find the proper setup for nginx. If we end up getting more configurations (in a different forum thread) we can assemble them in a guide. If we can also explain why APC does not necessarily work with concrete5 even though it's active, fine, but that's a different story..
OK, so where is the guide on getting Concrete5 to work with nginx properly? Out of the box, with a standard nginx config (no rewrite rules), I get two requests to wrong paths that 404:
The other CSS requests are correct and return 200 OK:
As sbajic else pointed out (http://www.concrete5.org/community/forums/chat/any-plans-to-officially-support-installation-using-nginx/#358325), C5 should make uniform path requests.
BTW, is there a Concrete5 wiki? I can submit a howto, but I can't improve someone else's howto.
/index.php/tools/css/themes/greek_yogurt/main.css /index.php/tools/css/themes/greek_yogurt/typography.css
The other CSS requests are correct and return 200 OK:
/concrete/themes/greek_yogurt/css/text.css /concrete/themes/greek_yogurt/css/reset.css
As sbajic else pointed out (http://www.concrete5.org/community/forums/chat/any-plans-to-officially-support-installation-using-nginx/#358325), C5 should make uniform path requests.
BTW, is there a Concrete5 wiki? I can submit a howto, but I can't improve someone else's howto.
Unfortunately I can not make it working without this rewrite:
Everything else so far works without rewrites.
location ~ ^/index\.php/tools/css/themes/([^/]+)/(.*) { try_files /packages/theme_$1/themes/$1/$2 /concrete/themes/$1/$2 $uri; }
Everything else so far works without rewrites.
Can you guys provide an example of when it breaks? E.g. what area of
the site is being accessed when it breaks?
I've been trialing C5 with nginx for about a month... and given all the
experimentation that has been going on I'd be surprised if we didn't
touch all areas of the site. But in saying that we've not ran into any
problems such as this.
Thanks,
Wes
On 7/30/2012 6:20 AM, concrete5 Community wrote:
the site is being accessed when it breaks?
I've been trialing C5 with nginx for about a month... and given all the
experimentation that has been going on I'd be surprised if we didn't
touch all areas of the site. But in saying that we've not ran into any
problems such as this.
Thanks,
Wes
On 7/30/2012 6:20 AM, concrete5 Community wrote:
Here's something that breaks:
/index.php/tools/required/page_controls_menu_js?cID=1&cvID=&btask=&ts=1343692685
I issue a 301 redirect to /concrete/tools/page_controls_menu_js.php?cID=1&cvID=&btask=&ts=1343692685
Problem is, that PHP file just echoes "Access Denied".
This causes the admin bar to not display any buttons.
/index.php/tools/required/page_controls_menu_js?cID=1&cvID=&btask=&ts=1343692685
I issue a 301 redirect to /concrete/tools/page_controls_menu_js.php?cID=1&cvID=&btask=&ts=1343692685
Problem is, that PHP file just echoes "Access Denied".
This causes the admin bar to not display any buttons.
sbajic, I reported as a bug the fact that some of these paths are inconsistent, but Mnkras replies that this is not a bug -http://www.concrete5.org/developers/bugs/5-5-2-1/inconsistent-paths...
This is correct, those are the correct paths, if you make a demo acct (using the instant setup link at the top of the page) you will see that this is correct. Do you have a nginx setup that I could possibly debug?
Mike
Mike
I'm using nithin's config fromhttp://www.concrete5.org/community/forums/installation/deploying-co...
[NB: bug in the forum, the space character that I typed in the editor between "from" and "http" above, is eaten up when the message is rendered]
It works without requiring any rewrite rules, but the two CSS files that I reported, return a 404:
[NB: bug in the forum, the space character that I typed in the editor between "from" and "http" above, is eaten up when the message is rendered]
It works without requiring any rewrite rules, but the two CSS files that I reported, return a 404:
/index.php/tools/css/themes/greek_yogurt/main.css 404 (Not Found) /index.php/tools/css/themes/greek_yogurt/typography.css 404 (Not Found)
this thread is a little bit old, but i was wasting over 1 hour to get the installation of concrete5 running on nginx. so this is what i found:
the nginx-directive:
location / {
try_files $uri $uri/ /index.php$request_uri /index.php;
}
location ~ \.php($|/) {
try_files $uri =404;
fastcgi_pass unix:/var/run/php5-fpm.sock;
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
set $script $uri;
set $path_info "";
if ($uri ~ "^(.+\.php)(/.+)") {
set $script $1;
set $path_info $2;
}
fastcgi_param URI $uri;
fastcgi_param PATH_INFO $path_info;
fastcgi_param SCRIPT_NAME $script;
fastcgi_param SCRIPT_FILENAME $document_root$script;
}
after that i restarted nginx (don´t know whether this is really necessary) with /etc/init.d/nginx restart
and what was MUCH important: my firefox (after having cleared cache) STILL told me that the PATH_INFO is not correct. so i opened a new browser with the setup and everything was OK. hope this helps someone to set up concrete5 with nginx in no time.....
the nginx-directive:
location / {
try_files $uri $uri/ /index.php$request_uri /index.php;
}
location ~ \.php($|/) {
try_files $uri =404;
fastcgi_pass unix:/var/run/php5-fpm.sock;
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
set $script $uri;
set $path_info "";
if ($uri ~ "^(.+\.php)(/.+)") {
set $script $1;
set $path_info $2;
}
fastcgi_param URI $uri;
fastcgi_param PATH_INFO $path_info;
fastcgi_param SCRIPT_NAME $script;
fastcgi_param SCRIPT_FILENAME $document_root$script;
}
after that i restarted nginx (don´t know whether this is really necessary) with /etc/init.d/nginx restart
and what was MUCH important: my firefox (after having cleared cache) STILL told me that the PATH_INFO is not correct. so i opened a new browser with the setup and everything was OK. hope this helps someone to set up concrete5 with nginx in no time.....
Here is the How-to guide for concrete5 and nginx (with php5-fpm):
http://www.concrete5.org/documentation/how-tos/developers/nginx-wit...
http://www.concrete5.org/documentation/how-tos/developers/nginx-wit...
I know it is an old post, but to help others setting concrete5 in Nginx+php-fpm, here is my settings:
server { listen 80; server_name domain.com; root /home/domain.com/public_html/; index index.html index.htm index.php; access_log /var/log/nginx/domain_com-access; error_log /var/log/nginx/domain_com-error; autoindex on; rewrite_log on; log_not_found off; real_ip_header $http_x_forwarded_for; if (!-f $document_root$fastcgi_script_name) { rewrite (.*) /index.php/$1 break; } location ~ /\. { deny all; access_log off; log_not_found off; }
Viewing 15 lines of 38 lines. View entire code block.
Old post, but first within Google results. Pasted my working Nginx Php Fpm 7.1 working virtual host
For me the issues were related with "Access denied" on dashboard and several editing blocks that were not working anymore (development has been carried on a Apache 2.4 with PHP 5.6, using mod-apache)
Focus was creating a working "location /"
try_files $uri $uri/ /index.php?q=$uri&$args;
For me the issues were related with "Access denied" on dashboard and several editing blocks that were not working anymore (development has been carried on a Apache 2.4 with PHP 5.6, using mod-apache)
Focus was creating a working "location /"
try_files $uri $uri/ /index.php?q=$uri&$args;
server { listen 80; server_name www.example.com; root /var/www/example.com/www; index index.php index.html index.htm default.html default.htm; add_header Access-Control-Allow-Origin *; #add_header X-Frame-Options "ALLOWALL"; location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off;
Viewing 15 lines of 31 lines. View entire code block.
I'm sure you can make concrete5 work on nginx, I don't see any reason
to "officially" bother with it however. ;)
best wishes
Franz Maruna
CEO - concrete5.org
http://about.me/frz