webserver Archives - developed.be

  • Published:November 4th, 2013
  • Category:nginx

We wanted these redirections:

  • project.example.com => www.example.com/project (without changing the url)
  • project.example.com/whatever => www.example.com/whatever (with changing the url)

In other words:

  • I wanted a subdomain that was nothing more than a page on the main site (or a subdirectory). But, the user shouldn’t know that.
  • Every link that on the subdomain should visibly redirect to the main site.

Turns out easy in Apache, but hard to accomplish with Nginx.

This is how you do it

Continue reading “Nginx: redirect a subdomain to a subdirectory without changing the url”…

When installing the combo php5-fpm together with Nginx or Apache, you might run into this error:

[error] 4942#0: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: example.com, request: “GET /phpinfo.php HTTP/1.1”, upstream: “fastcgi://127.0.0.1:9000”, host: “example.com:80”

This is actually not an nginx error but a php-error. Nginx tries to contact php5-fpm, but fails in doing so. This is because it’s probably not running, or because the configuration is wrong.

Check if it’s running

To troubleshoot this, test if fpm listens on 9000. You can do this with telnet.

telnet 127.0.0.1 9000

Alternatively:

sudo netstat -tlpn | grep :9000

Telnet should return “Connected to 127.0.0.1”

Netstat should return a line starting with “tcp” and ending with “LISTEN”

Troubleshoot

If it doesn’t return anything or if it returns an error, it’s because fpm is not listening on port 9000. To solve this:

sudo gedit /etc/php5/fpm/pool.d edit

edit the line that says “listen = ” to:

listen = 9000

Then restart fpm:

sudo /etc/init.d/php5-fpm restart

You don’t even have to restart apache or nginx. It should work right away.

This concerns an error in Bamboo-Invoice. When I wanted to print a pdf, I got the following error in Apache:

[notice] child pid 16395 exit signal Segmentation fault (11)

(16395 could be any number)

The cause of any “Segmentation fault” is probably PHP related. It could be because of a bad php-code compilation, or because of PHP code-error that couldn’t be caught like it would normally.

The reason here was obviously a bug in Bamboo-invoice. You can define your own corporate logo in /img/logo/logo.jpg but since I don’t have a logo at the moment I removed the file (as written in the manual). This caused the error.

Putting the image back (or any other image) resolved the error.

In case you’ve installed Varnish but not Pressflow (for Drupal 6), following scenario may happen:

  1. User A logs is, gets sessionid A
  2. User A changes something and loads a new page
  3. While loading the new page, a js or css-file is being downloaded from Varnish (example: /sites/default/files/js/js_79eb17289b3a88ec931b6f4bdb728282.js)
  4. The next file that is being downloaded is a jpg. This file doesn’t come from the Varnish cache and gives a new sessionid to the user (sessionid B)
  5. The requested page is being served correctly because it was requested with sessionid A. The user is unaware that he has a new sessionid because it happened during the loading of the page elements.
  6. The user clicks on another page and sends a new request with sessionid B.
  7. Drupal checks sessionid B and sees that it the session belongs to an anonymous user. Result: the user gets an “Access Denied” and is logged out.

Solution: install Pressflow. It will stop giving sessionids to the client.

(this post only applies if you have installed Varnish)

Bambooinvoice is supposed to work with Apache, althoug it can also run on nginx.

These are the rewriterules:

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

Let’s face it: Drupal can be a snail. When you attract lots of visitors, or have a lot of content, you performance will go down. To speed up Drupal, you need to install other software on your server that will make it appear like Drupal goes faster (but in fact stays as slow).

You can do any of these or a combination of these:

  1. Use memcache. Memcache replaces the classic cache-database-tables and puts the cache in the RAM (instead of in the database). This is the fastest way of getting your data.
  2. Use nginx instead of Apache. Nginx is a lightweight webserver that can handle more traffic than Apache. While it will not make your site magically faster, it can surely help up.
  3. Code-improvements in Drupal:
    • Disable menu_rebuild every time a view is saved. Run menu_rebuild only when cache clear is explicitly asked. (this is in fact core hacking, which is wildly disapproved, but it clearly helps)
    • Rewrite heavy queries generated by Views. Views don’t make the nicest queries. Certainly complex views can be made faster when you edit the query yourself. You can do this with a module that hooks into the view.
    • Check for node_load() calls everywhere. These functions eat up memory and should be replaced where possible (a custom query could do). You wouldn’t believe what happens when you call node_load().
    • Cron:
      • inspect all the cron hooks in your Drupal installation. Decide if the tasks are really necessary, and/or edit them. You’ll notice that the cron spends most of its time with indexing the search words.
      • Use visitorstats (like Google Analytics) to see when traffic peeks. If your website peeks at noon, edit the crontab and disable cron around that time. At least all cpu will go to your visitors. (make sure there are no real important tasks to be done). Cron should run “just enough”. I set my cron to run every hour from 11PM to 7AM.
      • Drupal calls home once a day to see if there updates for modules (with fread). This action consumes cpu. I think that once a week is more than enough. Even every forthnight. You can always check for new modules manually.
    • * In order to do find bottlenecks:
      • Use the Devel module. It displays all queries that are made to the database.
      • Use XHProf. A free php-profiler developed by Facebook to find slow components. It displays function calls and generates a graph (also install Dot for that). My article on how to install XHProf.
      • If you have the possibility, use New Relic, a tool similar to XHProf, but more advanced.
  4. Boost: Boost is a Drupal module that caches entire  webpages as static html files for anonymous users. You wouldn’t believe what a boost that gives. However: take in consideration that websites with a lot of content changes will need to refresh this cache a lot. It’ll take some time to configure. Still, it doesn’t speed-up the admin-environment in any way. This article explains how to install Boost with Nginx [mysqlperformancetuning.com].
  5. Varnish: A similar, but better, approach to Boost is Varnish. Varnish also caches pages, but puts them in the RAM, while Boost uses the hard discs (and creates amounts of files). A downside of Varnish is that it’s complex to set up (you have to put it in front of your webserver) and is difficult to config. With Varnish Drupal can’t use anonymous cookies, so you have to patch your entire Drupal setup, and use “Pressflow” as Drupal core instead of the regular Drupal releases (this is just for Drupal 6). Any module that uses sessions will have to be patched. Varnish however promises what it delivers and gives a serious boost to your website and is far more advanced than Boost. My article on how to install Varnish.
  6. If you can afford it, use a seperate (database) server. Drupal generates a lot of cpu-pressure. This makes the database on the server getting less cpu. Some queries take x50 times as much time as on a non busy site. By taking the heath of the database, this should give a performance boost.

attrack

This articles covers the installation and configuration of Nginx+Varnish+Drupal6(Pressflow) and also about the Purge module.

This article assumes:

  • you are no Drupal newbie
  • you know about the default Drupal caching
  • you have some experience with Nginx (if you have Apache as webserver, this tutorial might help you too.)
  • you know what Varnish is.

Note: I’m still updating this post. It’s a bit messy right now.

Install Varnish (the easy part)

1)

curl http://repo.varnish-cache.org/debian/GPG-key.txt | apt-key add

2)

sudo su

(enter password)

3)

echo "deb http://repo.varnish-cache.org/ubuntu/ lucid varnish-2.1" >> /etc/apt/sources.list 

Note: I installed 2.1, The latest version is 3.0. You can install 3.0 by altering the above line.

(see: https://www.varnish-cache.org/installation/ubuntu )

Continue reading “Install Varnish (with Drupal and Nginx)”…