Somehow my touchpad caused all this. So I had to disable it entirely in Ubuntu. It's really easy to do so:

If one of the lines mentions a touchpad or glidepoint (perhaps also "Synaptics" or "ALPS"), your touchpad has been detected. For me that is ID 13. On the command line, as the user who's logged into X-windows you do:

And the touchpad is disabled, this works right away. My problem was gone, and my TouchPad too, I don't used it anyway.

This article is a prequel to another one, which will be storing those uploaded binary files into CouchDB backend. These files reside on remote machines and will be uploaded to the target server which will stock, create a CRC code and use that to store them in uniquely in a CouchDB database. I was about to post one big article when I realised that finding how to upload files with a PHP Curl client program isn't really easy to find and deserves it's own post.

Enable file uploads for PHP

I'm using nginx (of course), so this means I have php-fpm running. Hence any change that I have to make to PHP will NOT be in the cli nor the apache2 subdirectories on the Debian family of supreme operating systems.

As you can see: it's in the fpm subdirectory. How handy is that! If that doesn't work for you for some weird reason you should try the cgi one next. Search for a section called File Uploads in the php.ini file in that subdir. Check if the parameters allow you to upload a file of the size you will be trying AND check if the target temp directory exists, is writable by the nginx user (www-data) and is filled out in the config. Glance over the other settings too.

You will also want to protect that directory a bit since it is under the webroot, depending on your level of protections, you can set these in nginx.conf inside a server section :

If that is all ok , restart php-fpm and now you are ready to create a script that will accept those files. When I test stuff I always try to not customize too much with subdirs and other things that might screw my work up forcing me to focus on tangent instead of my actual goal. Later on, I think about deploying it decently. Good code is easy to throw around.

So, just navigate to the nginx-default webroot and create the scripts we use here and directories in there (incoming / uploaded ) etc.:

Pay attention for file permissions too.

Create php code to accept the files

I want to make one thing clear first, I do NOT support putting make-up into code at all. In fact what we are doing here is create an API between couchDB and a client. The API here will be in PHP, the client too since I will be using PHP Curl. This is not needed, most people should know that the client can be anything. I'm just working on some things that require this, so this approach will be used in real life although with more detailed proper coding.

The reason there's HTML inside my PHP file this time is for reasons of debugging. The upload mechanism inside PHP is kinda strange to comprehend for a newbee. But even an experienced programmer that never focussed on this before will probably raise some eyebrow figuring out where in the hell that uploaded file went. Also, if you haven't actually written that curl client, you can't test with it yet. So at first, we will be using our browser to create the backend script first, once we know that works, we will dig into the client. And in the last phase once the files are able to arrive at the destination we will introduce these into couchDB. That sure sounds like a plan, perhaps not how others would to it, but having a plan is a good thing. If you fail to plan, your plan will fail.

So let's create this backend. We will call it upload.php since we feel so inspired today. Since this is no pre-school class, I'm not going to explain this line per line but I will point out later where you need to pay attention to.

If you happen to see an error like this you have a permission problem or you are trying to move a file from outside the webserver, make sure you keep the directories involved in the document root and not below. This is very hard to figure out if you don't. Ownership of the directories should be the same as the one running nginx, by default www-data.

Once that is all set up the backend should work and we can start creating the curl client. This one is actually really easy. Notice the @ before the filename, that one is golden as that will make it send the file content.

By now this should already work now, send it 2 files to test this. My uploads are working at this point.

$_FILES is flawed

Another thing you need to be aware of, when using square brackets in your input name form attributes to group the properties of your object you are screwed. $_FILES then creates an array where the properties of your uploaded files become properties of your named object and the properties you were expecting become properties of the uploaded file properties.

Like this:

will create a $_FILES array in the receiving php script as

It doesn't take a genius to figure out that this is screwed and totally non-logical to do so. We would rather have:

The function fix_files_superglobal() is created for that, I've seen ton's of difficult approaches handling this conversion but my solution is more bullet-proof than most. I wasn't satisfied with what I could use from others so I wrote this.

I hope this was helpful for someone.

In order to get MariaDB 5.2 to work with restoring partitioned files you will need a whole lot of open files available. When you see this in the logs:

If you have a quite some partitioned tables (with a few hundred per table ), you are going to need a lot of open files. Mysqld crashes with a signal 6 if it hits the limit. To bring order to chaos, you need to set some limits. I've had success with these:

In fact, if you have that first option set, you're gonna need a whole lot of files. You'll waste diskspace too but in my experience you gain quite some performance and avoid locks. These work fine for me (with a 8GB VPS).

Also, set the general file limit high enough, for me at the moment, this is about 4 times the amount of open files with a loaded DB.

I also switch off the following engines for memory and stability issues:

pbxt saves me a good chunk of memory, I found that using partitioned archive tables is really unstable so I switch them off for now (I do like archive being read-only but I cannot use those for now).

For finetuning my installation I do some tweaks, I'm on a VPS with write-back cache on the disks.

and than specifically for XtraDB (One more reason to take MariaDB over stock Mysql).

This about does it for me, I'm still playing with the memory sizes and the innodb buffer cache.

im trying :

Moderately busy runtime table stopped working

- Problem turned out to be a DB error.
- ERROR 130 (HY000): Incorrect file format
- Worked fine for weeks. No reports of corruption in Error logs so far on these.

Platform

- running 5.2.8-MariaDB-mariadb102 - debian-linux-gnu on i486
- 32bit (mem/64bit upgrade in process of waiting for hardware)
- Signal 11 problem we have since MySql 5.1. Coredumps not configured in kernel so we can only guess at this point.
- Not very busy (cpu use is very low on average)

Symptoms of the problem

- The tables seem to stop functioning all the sudden, repair doesn't work.
- show create doesn't work but truncate table does recreate it correctly(?)
- happened twice in 2 days (among a pack of ~ 150 similar tables in design and functionality)
- lots of updates
- few inserts
- about 40 records per table on average
- Problem only apeared after switching over to MariaDB 5.2
- Last time the database came down with Signal 11 when hitting it hard with repairs.

Schema

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

CREATE TABLE `LastSeen_h` (   `imei` bigint(20) NOT NULL,   `lastComms` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,   `eventDate` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',   `eventState` int(10) UNSIGNED DEFAULT NULL,   `eventLon` int(10) UNSIGNED NOT NULL,   `eventLat` int(10) UNSIGNED NOT NULL,   `eventDelta` time NOT NULL,   `eventRecordid` int(10) UNSIGNED DEFAULT NULL,   `eventIO` int(10) UNSIGNED DEFAULT NULL,   `eventSwitch` int(10) UNSIGNED DEFAULT NULL,   `lastDate` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',   `lastState` int(10) UNSIGNED DEFAULT NULL,   `lastLon` int(10) UNSIGNED NOT NULL,   `lastLat` int(10) UNSIGNED NOT NULL,   `lastRecordid` int(10) UNSIGNED DEFAULT NULL,   `lastIO` int(10) UNSIGNED DEFAULT NULL,   `lastSwitch` int(10) UNSIGNED DEFAULT NULL,   PRIMARY KEY (`imei`),   KEY `Index_date1` (`imei`,`lastComms`),   KEY `Index_date2` (`imei`,`eventDate`) ) ENGINE=Aria DEFAULT CHARSET=latin1 PAGE_CHECKSUM=1

Solution (none so far)

- We have no real solution so far but to drop/create the table. We are lucky as this data is being cached in sqlite so we just reimport and the customers are back online. We do not have this happen on tables that do a lot of inserts. We have other aria tables that are very important to us with severely processed data (takes a lot of time to recreate those).
- truncate works too but I find this weird since 'show create table' doesn't. I prefer to drop it first (which works too) and create it again.

Anyone else have this since using MariaDB 5.2?

- We only had this happen twice but my gut feeling is that something is up with Aria. (I've upgraded this server from MariaDB 5.1). This went fine at the time. Since then we have restored this DB from backups except 'mysql' database which we ended up fixing and cleaning first but those are Isam so I don't think they matter.
- I love to hear if anyone has the same experience.

One of the things MySQL forced me into is looking for serious alternatives. Finding MariaDB was an amazing relief. But it's still not all cake and cookies yet. I experiment a lot with OpenStreetMaps lately, a great project everyone of all makes should look into seeing what it can do for you and vice versa. This is where we step into the PostgreSQL realm. Almost all about OSM is backed by PostgreSQL
I've built Tile and Gazetteer services to provide maps an geocoding features. This put me in the spot I had to get to know PostgreSQL.
Like a lot of early hour MySQL fans I kept far to the left side of PostgreSQL for as long as I can remember. I didn't need it, it was for strange, weird techies. Even more than me. As if admitting I L.O.V.E working with vi(m) is not enough.

But now we are probably all on an awesome inspiring path, ready to choose our next idol. With the rising of new sort of mainstream technologies(=what lots of people can use instead of a few) that perform, it's exiting to see that PostgreSQL is so stable and useful. Not only do we have stuff like Cassandra, CouchDB and Nginx ready for production for some time. There's a place for old school solid stuff.

Anyway, so after a few weeks I'm loving the damn thing. I need to get used to it a bit more. Specifically those shorthand commands. But it's so fast if you do everything right. I'm actually able to tune it now running fast with not-so-smart options set and I actually NOTICED the results of it for a change.

I had a power failure on one of the machine I was building a giant DB on and re-indexing gazetteer fails now, so trying to repair postgresql DB is just an awesome way into getting to know the inner workings.
I'm very pleased with it, I will sure use it more. The PostGIS stuff is kick-ass. Even the crash was predicted by the manual and the fact that I have some nasty corruption preventing me from completing the gazetteer indexing. I'm still trying to make the best from it, it's not THAT critical so I want to cease the opportunity to look at some of the nastiest error messages in postgreSQL

So, here's a few things I learned along the way

- Dig into VACUUM FULL VERBOSE ANALYSE. It's a cornerstone of fixing/keeping the DB.
- REINDEX TABLE. Same here, it's a lifesaver.
- Depending on YOUR version (do the google thing), set this: zero_damaged_pages = true , if it isn't set yet and you want to fix stuff you need this in your postgresql.conf

Doing it for all tables

I really love this oneliner too:

Or

That last one comes from the Gazetteer install wiki page for ubuntu.

Very exiting times, head over to nginx.org for the heads-up. I think this is a great move for the future of NGINX. Corporate Doubters, now there's no more reason to not consider this elegant, fast webserver.

Our primary goals are improving support and communication for our users, streamlining the development process, revamping the documentation, integrating and speeding up pending bugfixes and patches, introducing long-requested functionality and more.

See the full statement at nginx.org.

This post describes my experiences with the W3 Total Cache (w3tc) plugin in relation to my nginx install. I have bumped against a few hiccups along the way that I want to share. It all started when I took up ab, the apache benchmark tool. I wanted to see how this nginx powered website performed with the spawn-fci and mariaDB setup. Along the way I wanted to exploit the amazing ability of nginx to deliver static files. It's just really good at that so I wanted to start caching the thing after seeing very poor performance due to the regular load of php cgi,  I had a mission all the sudden.

My slick nginx powered wordpress is slow

Some simple benchmarks taken at various points, I tried 3 different cache plugins, W3TC as the third and it's still running now (although I reinstalled it once).   The first benchmark below, is the 'before cache' one, no improvements yet done, besides running on mariaDB tables instead of innodb,  switching off revisions in wordpress and running on nginx.  Notice the number of failed ones...

Before the makeover

This is just plain insulting, 3.2/s is crap!  Admittedly  I'm on the Linode 768 plan but still, these guys are great at what they do so I believe I can do better here with their/my resources.

I tried SuperCache plugin with static pages.  Configuring this for nginx proved to be a pain in the butt.  I took a benchmark with static file caching right before un-installing this.  I didn't like the way it worked for me. No nginx support.   Still, the performance was about the same as with W3TC.

With SuperCache plugin

I'm not going to mention the other cache plugin, it was total crap, let's not waste our time on it.  So time to move to WT3C.  After installation, switching the page cache with disk advanced mode to on.

With wt3c plugin

As you can see here, there is not too much difference between the two, but we aren't done yet.  When logging into the WP Admin page I see a Performance section at the left bottom under Settings.  That is new.  I like seeing everything belonging to a single goal in the same place.  I've had a big issue in getting this page to load by the way but that is food for later.  Once I put a workaround in place for this issue I could use it.

I see lot's of support for goodies I like.   For example memcached support.  For this small site using memcached seems like a done deal, I have memory left over I can put to use.  So I decided I want object/query caching done in memcached, I'll select that, put some bigger values in the caching (5 minutes=300sec) and Deploy it.  Let's pimp the tests up a bit ...

With more threads

Caching on for objects/queries with memcached

Professionally, I have had issues with memcached with trying to store larger values that what most typical uses would.  I've used it outside the web context for years now but I've seen some issues with it along the way.  Still, I don't expect any problems when using it here, for what it was intended for in the first place, which is beefing up sites like they are Duke Nukem's on steroids.  I'm at 50/s now using Page + Object + Query caching.

From a faster connection with tuning/bugfixes

Much better!

That looks really good there, 100/s!!!  Does everyone agree that this benchmark is totally not complete nor do I claim it is.  It's just that.... erm.   The difference is overwhelming.  It's a factor 50 faster than before the makover....  Even the worst benchmarks get some of it right.

Now about those bugs I fixed along the way

The timout problem

A hanging Performance tab, only on nginx.  When I clicked anything in that new Performance tab, the whole thing would hang for a while and then time out.   I've investigated this at the mysql level,  at the php-cgi level and the nginx level.  With the latter two I have strace 'd those processes. If you have this issue after installing the plugin you need to put this workaround in the following file : wp-content/plugins/w3-total-cache/lib/W3/Plugin/TotalCache.php

Find this line (for me at line 1781), and change this to

You don't want to have it call $this->test_rewrite_pgcache() . It made things time-out and I don't know why.  What it do know is that it makes a special call to the nginx webserver that looks like this GET /w3tc_rewrite_test. It's a test.

In the nginx access log file I see :

This is where it get's interesting, I noticed that right after that call to nginx it goes south. (you  see the 504 there).  When I call this from my browser or with wget, it works perfectly(as per status 200).  All it does is return 'OK', which sounds really easy to handle.  But for some reason that whole thing doesn't get back.  So it just doesn't work when W3TC requests it coming from PHP, it does work on every other occasion, by hand this time.  As stated previously, it's just a test, a check to see if you have the rewrite rules in place on nginx.  The request matches the following rewrite rule from the nginx config:

      # BEGIN W3TC Page Cache core
      rewrite ^(.*\/)?w3tc_rewrite_test$ $1?w3tc_rewrite_test=1 last;
 

So now it knows you have that rule there.  What it concludes from there on is too much trouble to find out and boring too once I fixed this call anyway.  The panel loaded in a blink of an eye after that. I have an example php-cgi strace dump here for the curious. Check out what happens after this line:

send(7, "GET /w3tc_rewrite_test HTTP/1.1\r"..., 107, MSG_NOSIGNAL) = 107
 

Anyway, I managed to get the rules written to the config before that panel started locking up (you can run it once before you switch page caching on). But I'm pretty confident I have every needed rule in my nginx.conf already now. I just wanted that panel to work so I can configure the rest of the cache.  Thus,  I switched off that test by changing those particular lines.

Memcache md5 problem

Another issue I noticed, and this one is I think a bug is the definition of the memcached instance key, basically to make your key = value pair unique.   Take a look at this code from wp-content/plugins/w3-total-cache/lib/W3/Cache.php. This is what happens when you implode a nested array. Implode doesn't handle them as per php documentation.  Now it becomes unpredictable, and it sure looks like it needs to be predictable.

You get this error if you try:

So I replaced this with json_encode , perfectly designed to handle this kind of an Array

I've tried to find if there is any other place in the code that would generate this and one other file popped up: /usr/share/wordpress/wp-content/plugins/w3-total-cache/lib/W3/Cdn.php. You should fix this issue in there too. Another warning message will be gone which spawn-fcgi doesn't like here.

Other fixes

I also fixed all calls to deprecated functions in lots of plugins I have running.  I've also fixed a bug in the Raindrop template I'm currently using as well that made my permalinks to "/tag/%s/"  URL locations to be wrongfully generated due to a wrong function call to an non-existing function.   And lastly I also fixed an issue in PiWik, the analytics software I'm using that threw a warning on every hit.  In the plugin wp-content/plugins/piwik-analytics/piwikanalytics.php line: 256

Since $wp_siteid_takes_precedence is nowhere to be found in the code it arrives there uninitialised and throws a warning.  Finding from where that variable should come and why it's unknown at that point in the code is going to take me too much time so I commented it out, which looks like the right choice. Bit off topic but while we are at it we might as well dump all.

Lots like these :

and those

Although I don't think the last one is related to this plugin. It was part of a bunch of fixes.

The rewrite rules for nginx

W3TC Page Cache

      # BEGIN W3TC Page Cache cache
      location ~ /wp-content/w3tc/pgcache.*html$ {
         add_header X-Powered-By "W3 Total Cache/0.9.2.3";
         add_header Vary "Accept-Encoding, Cookie";
      }
 
      location ~ /wp-content/w3tc/pgcache.*gzip$ {
         gzip off;
         types {}
         default_type text/html;
         add_header X-Powered-By "W3 Total Cache/0.9.2.3";
         add_header Vary "Accept-Encoding, Cookie";
         add_header Content-Encoding gzip;
      }
      # END W3TC Page Cache cache
 

W3TC Browser Cache

      # BEGIN W3TC Browser Cache
      gzip on;
      gzip_types text/css application/x-javascript text/richtext image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon;
      location ~ \.(css|js)$ {
            add_header X-Powered-By "W3 Total Cache/0.9.2.3";
      }
      location ~ \.(html|htm|rtf|rtx|svg|svgz|txt|xsd|xsl|xml)$ {
            add_header X-Powered-By "W3 Total Cache/0.9.2.3";
      }
      location ~ \.(asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|odb|odc|odf|odg|odp|ods|odt|ogg|pdf|png|pot|pps|ppt|pptx|ra|ram|swf|tar|tif|tiff|wav|wma|wri|xla|xls|xlsx|xlt|xlw|zip)$ {
            add_header X-Powered-By "W3 Total Cache/0.9.2.3";
      }
      # END W3TC Browser Cache
 

W3TC Page Cache core

      # BEGIN W3TC Page Cache core
      rewrite ^(.*\/)?w3tc_rewrite_test$ $1?w3tc_rewrite_test=1 last;
      set $w3tc_rewrite 1;
      if ($request_method = POST) {
            set $w3tc_rewrite 0;
      }
      if ($query_string != "") {
            set $w3tc_rewrite 0;
      }
      set $w3tc_rewrite2 1;
      if ($request_uri !~ \/$) {
            set $w3tc_rewrite2 0;
      }
      if ($request_uri ~* "(sitemap\.xml(\.gz)?)") {
         set $w3tc_rewrite2 1;
      }
      if ($w3tc_rewrite2 != 1) {
         set $w3tc_rewrite 0;
      }
      set $w3tc_rewrite3 1;
      if ($request_uri ~* "(\/wp-admin\/|\/xmlrpc.php|\/wp-(app|cron|login|register|mail)\.php|wp-.*\.php|index\.php)") {
         set $w3tc_rewrite3 0;
      }
      if ($request_uri ~* "(wp\-comments\-popup\.php|wp\-links\-opml\.php|wp\-locations\.php)") {
         set $w3tc_rewrite3 1;
      }
      if ($w3tc_rewrite3 != 1) {
         set $w3tc_rewrite 0;
      }
      if ($http_cookie ~* "(comment_author|wp\-postpass|wordpress_\[a\-f0\-9\]\+|wordpress_logged_in)") {
         set $w3tc_rewrite 0;
      }
      if ($http_user_agent ~* "(W3\ Total\ Cache/0\.9\.2\.3)") {
         set $w3tc_rewrite 0;
      }
      set $w3tc_ua "";
      if ($http_user_agent ~* "(2\.0\ mmp|240x320|alcatel|amoi|asus|au\-mic|audiovox|avantgo|benq|bird|blackberry|blazer|cdm|cellphone|danger|ddipocket|docomo|dopod|elaine/3\.0|ericsson|eudoraweb|fly|haier|hiptop|hp\.ipaq|htc|huawei|i\-mobile|iemobile|j\-phone|kddi|konka|kwc|kyocera/wx310k|lenovo|lg|lg/u990|lge\ vx|midp|midp\-2\.0|mmef20|mmp|mobilephone|mot\-v|motorola|netfront|newgen|newt|nintendo\ ds|nintendo\ wii|nitro|nokia|novarra|o2|openweb|opera\ mobi|opera\.mobi|palm|panasonic|pantech|pdxgw|pg|philips|phone|playstation\ portable|portalmmm|\bppc\b|proxinet|psp|qtek|sagem|samsung|sanyo|sch|sec|sendo|sgh|sharp|sharp\-tq\-gx10|small|smartphone|softbank|sonyericsson|sph|symbian|symbian\ os|symbianos|toshiba|treo|ts21i\-10|up\.browser|up\.link|uts|vertu|vodafone|wap|willcome|windows\ ce|windows\.ce|winwap|xda|zte)") {
         set $w3tc_ua _low;
      }
      if ($http_user_agent ~* "(acer\ s100|android|archos5|blackberry9500|blackberry9530|blackberry9550|blackberry\ 9800|cupcake|docomo\ ht\-03a|dream|htc\ hero|htc\ magic|htc_dream|htc_magic|incognito|ipad|iphone|ipod|kindle|lg\-gw620|liquid\ build|maemo|mot\-mb200|mot\-mb300|nexus\ one|opera\ mini|samsung\-s8000|series60.*webkit|series60/5\.0|sonyericssone10|sonyericssonu20|sonyericssonx10|t\-mobile\ mytouch\ 3g|t\-mobile\ opal|tattoo|webmate|webos)") {
         set $w3tc_ua _high;
      }
      set $w3tc_ref "";
      if ($http_cookie ~* "w3tc_referrer=.*(google\.com|yahoo\.com|bing\.com|ask\.com|msn\.com)") {
         set $w3tc_ref _search_engines;
      }
      set $w3tc_ssl "";
      if ($scheme = https) {
         set $w3tc_ssl _ssl;
      }
      set $w3tc_enc "";
      if ($http_accept_encoding ~ gzip) {
         set $w3tc_enc .gzip;
      }
      if (!-f "$document_root/wp-content/w3tc/pgcache/$request_uri/_index$w3tc_ua$w3tc_ref$w3tc_ssl.html$w3tc_enc") {
         set $w3tc_rewrite 0;
      }
      if ($w3tc_rewrite = 1) {
         rewrite .* "/wp-content/w3tc/pgcache/$request_uri/_index$w3tc_ua$w3tc_ref$w3tc_ssl.html$w3tc_enc" last;
      }
      # END W3TC Page Cache core
 

What it does well for me

• Static page caching is really good.  I like the pre-zipped support, doing page caching is the main gain of every cache plugin, this is why I chose it since it creates static files which nginx serves well in the webserver realm.
• Object + DB query caching using memcached.  Stats of memcached prove it's useful.

These don't really tell us anything on cache efficiency as with a 5 minute limit on the caching of subsequent data, it all depends on the expiration of those items from the cache. What it does tell is is what would have gone to the backends in case it wasn't there at all. You will want to balance site dynamism vs caching efficiency.

What it doesn't do well for me

• That Preview/Deploy thing, there is something about it that I find irritating.  It doesn't seem to notice that the deployed and the previewed config are the same so it keeps on displaying that you need to Deploy. Even after you have just deployed.  Aargh,  It's irritating, I don't really test-drive it either, I just apply and test the whole site.  I like the Deploy facility to apply all my changes at once though.  But I want to just activate and test the lot.
• I have my issues with the Browser caching functionality, I create php applications for a living and I know for a fact that getting all those browsers to respect caching directives (Headers) is hard work.  I took a look under the hood using Web developer plugin to see what kind of expiration tricks they do and I saw some strange stuff going on that I switched this part off for now.  I haven't investigated this in depth yet.  Once I do I will make this more complete. I can just say that if you want the browser to cache the pages, you cannot send a no-cache header. that's the opposite of browser caching, more on it later I hope.

Conclusion of my experiences

nginx isn't hard to configure, with the aid and support of plugin developpers.  This plugin gets extra points for nginx support, translating these .htaccess rules/files from apache to nginx would be troublesome for most people, myself included, these are a lot of rules as we have seen here.  I list them up per module as they are written in the nginx config by this plugin, I didn't invent those.  These people understand that making it as low-entry as possible is good marketing.

As a PHP developer or even as a troubleshooter,  try to just use E_ALL for a change when running php code.  Switch every  error / trace / log warning in the php.ini file to on you can find,  you will be amazed on how much crap gets left behind.  I've noticed of small issues that are a nobrainer to fix in the code so I guess a lot of people turn their PHP warnings off .... even when creating nice wordpress plugin's.

Future of nginx

I've seen lots of people talking about speeding up their Apache driven wordpress blogs by using nginx in front of it. Although nginx does that well too, I believe it's so wrong that setup. Honestly. Just get rid of Apache right now. It's over, it earned it's place in history, that's where it belongs now. Replace it with nginx.

I'm going to predict that if nginx keeps up like it's doing now, it will replace Apache as a default web-server in some distributions just as mariaDB will be replacing mysql in the near future. It's inevitable. GPL is at work here. Better stuff just survives. Evolution works.

On the subject, make sure you check out the benchmarks mentioned before, they are unreal if you glance at the G-WAN ones.
It confirms a few things for me, there's always a new kid on the block, G-WAN is insane by the looks of it, I'm not sure I want to use it into production environments at this stage or if I can get it to work with php, in fact, it's new to me too.   This also confirms that Apache is on it's way out for sure.  More exciting things are about to come.

Some sources I visited to feed my hunger

http://wp-performance.com/2010/10/nginx-reverse-proxy-cache-wordpress-apache/
http://tentblogger.com/w3-total-cache/
http://wordpress.org/extend/plugins/w3-total-cache/
http://nbonvin.wordpress.com/