Here’s how to Mine was around here somewhere.

File was here

sudo nano /usr/bin/php-fastcgi


Original file looked something like this.

#!/bin/bash
/usr/bin/spawn-fcgi -a 127.0.0.1 -p 10005 -u www-data -g www-data -f /usr/bin/php-cgi


Added -C argument to enforce a limit.

#!/bin/bash
/usr/bin/spawn-fcgi -C 2 -a 127.0.0.1 -p 10005 -u www-data -g www-data -f /usr/bin/php-cgi


http://forum.slicehost.com/index.php?p=/discussion/3671/limit-number-of-php-cgi-processes-nginx/p1

I just got a notice from my VPS host that my box was using too much swap and therefore impacting other users on the machine. As such, my provider did a hard reset on my instance which summarily stopped my web app (I don’t start the app on startup. I should.)

I just upgraded my server a few versions up the Ubuntu chain because of the heartbleed SSL bug so obviously it was something related to the upgrade. I’m not super savvy with figuring out which components changed so I figured if I could just cut back on the memory usage things wouldn’t go to swap. My server is running an app and a couple of old Drupal blogs that don’t get much traffic but I like to keep around for nostalgia. So, I figured I could sacrifice substantial performance on the blogs.

Things I changed to hopefully save memory:
/etc/mysql/my.cnf
* reduce max_connections to 50 from Not specified.

/etc/php/cgi/php.ini
* reduce memory_limit from 128M to 64M

/usr/bin/php5-cgi
* add “-C” flag to constrain number of processes to 3. (default was 5)

The php5-cgi change by far had the largest affect because each php5-cgi process was using 25MB per thread (~125MB, or 50% of my 256MB VPS).

Lately I have had to redo some of the HTML emails. We had an outside contractor do most of the work and he did a fantastic job. However, I was noticing that under a very specific condition, the email images were not rendering properly in desktop Gmail on Internet Explorer 10. I have no idea how many people are using GMail+IE10 but since this is our first real contact with the user, I though it would be important to ensure the best user experience possible. Broken images are not a good experience.

Here is the problem:

Old HTML

<img class="imageScale" 
style="display: block; width: 550px; height:auto;" 
width="550" height="auto" src="{{ img_url }}" 
border="0" />

New HTML

<img class="imageScale" 
style="display: block; width: 550px;" src="{{ img_url }}" 
border="0" />

Final outcome:

Why does it fix it?

I came across a couple of quirks at play in this porblem.

First, I learned that GMail automatically converts CSS height attribute to min-height with reckless abandon.

Second, the original HTML IMG tags have height:auto. With GMail’s reckles height conversion it becomes min-height:auto which essentially means 0px or 1px.

To solve, I removed height attributes on the img tags. It turns out that all of the browsers will automatically just render the image at full size of the parent container. In this case we have a series of nested tables that set maximum width of the parent to about 550 and the minimum width is 100% of screen width.

https://blog.engineyard.com/2013/developing-ios-push-notifications-nodejs

http://apnagent.qualiancy.com/