Category Archives: nginx

nginx

deflate & gzip: I was wrong

March 28, 2012 – 12:03 AM

UPDATE: I was wrong about being wrong! In the comments section below, Billy Hoffman has pointed out that gzip compression is still incredibly useful, and that I should do better research. ;)

 

Today I had to rethink how I serve data to my users.

According to an answer posted on StackOverflow,  gzip or deflate compression should be avoided when serving text-based files.

While compressing data to decrease bandwidth and download times generally seems like a great idea, there are a number of problems which have surfaced during the evolution of on-the-fly compression over the wire. After reading the article Lose the wait, I thought more of why I had implemented used mod_gzip in the past and started to realize that the benefits aren’t particularly worth the effort or expense.

  • Internet Explorer has a history of issues with receiving compressed payloads — so much history that all gzip/deflate HOWTOs have a line disabling compression for IE, based upon user agent evaluation.
  • Uses extra CPU cycles to compress data on each request.
  • Requires another module to be loaded into memory (mod_gzip, mod_deflate, etc)
  • SSL (HTTPS) connections cannot be compressed.

A better approach is to combine technologies like browser caching and local storage mechanisms, server-side expires tags, and code “minification” to mitigate the need for on-the-fly compression by addressing the underlying issue: management of client-to-server requests.

All that said, compressed http payloads still have a place on the web. For example, Reddit, Digg, Slashdot, or any high-traffic, predominantly text-based site with a large volume of traffic from modern, non-IE web browsers.

Permalink | Comments (3)
How To nginx

phpMyAdmin installation errors

April 6, 2011 – 2:20 PM

When installing phpMyAdmin 3.3.10 on my Nginx 0.8.76, PHP-FPM 5.3.6 (w/ APC + memcached) & MySQL 5.5.9 setup, I first encountered this problem:


2011/04/06 14:17:36 [error] 32174#0: *9366 FastCGI sent in stderr: "PHP Warning: Unknown: Unable to allocate memory for pool. in Unknown on line 0
PHP Warning: require_once(): Unable to allocate memory for pool. in /PATH/TO/MYSITE/phpmyadmin/index.php on line 35
PHP Warning: require_once(): Unable to allocate memory for pool. in /PATH/TO/MYSITE/phpmyadmin/libraries/common.inc.php on line 53
PHP Warning: require_once(): Unable to allocate memory for pool. in /PATH/TO/MYSITE/phpmyadmin/libraries/Error_Handler.class.php on line 13
PHP Warning: require_once(): Unable to allocate memory for pool. in /PATH/TO/MYSITE/phpmyadmin/libraries/Error.class.php on line 13" while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: www.example.com, request: "GET /phpmyadmin/ HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.example.com"

I corrected this by editing /etc/php.d/apc.ini and setting apc.shm_size=64M.

Next, I encountered the following error:


011/04/06 16:54:35 [error] 7399#0: *492 FastCGI sent in stderr: "PHP Fatal error: Class 'PMA_Message' not found in /PATH/TO/MYSITE/phpmyadmin/libraries/Message.class.php on line 732" while reading upstream, client: xxx.xxx.xxx.xxx, server: www.example.org, request: "GET /phpmyadmin/phpmyadmin.css.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.example.org"

I found a hint to fix the problem, and discovered that PHP packages installed by the IUS Community Project store sessions into /var/lib/php/session, which is owned by apache:apache. Since I don’t use apache, I had changed both the PHP-FPM pool user and group to “nginx”, and that change removed PHP-FPM’s ability to write to sessions.

Lessons learned:

  • PHP packages installed via the IUS Community Project attempt to save sessions to /var/lib/php/session, which is owned by apache:apache. Keep this in mind when modifying permissions or the accounts under which the services run.
Permalink | Comments (5)