Moving from Apache to Nginx with php-fpm

In order to address performance issues we have seen, our company has been switching from apache with mod_php to nginx with php-fpm.

Given that apache httpd webserver is an older code base and does not take advantage of event driven and asyncronous technology this seems to be the future. There are numbers of differences between these two.

Nginx webserver is product that came out of Russia, it had been more obscure, though now it is the #2 webserver. Apache webserver has been an important product in web based technologies for many years, and has been the dominant webserver. Php as a technology is often used in a module in apache (mod_php) or run through a cgi type where php runs in a separate process. To improve performance of cgi type operations the php supports fastcgi. Fastcgi runs a server which keeps a number of php processes live and waiting for traffic and runs them as a server, there are numerous advantages to using this.

At high load apache has been shown to not manage memory as efficiently as possible.

Where nginx really shines is in serving static content, where it’s asynchronous technology allows it to serve more content than other webservers.

Switching to Nginx has required changes, for instance taking out use of apache specific functions like getallheaders() which provides the headers in normal http header form, not in the cgi name scheme that you find in the $_SERVER variable, for instance User-Agent vs HTTP_USER_AGENT, and switching configuration from .htacess files to nginx rewrites.

Configuration of Nginx is different from apache, and ins more scripted than the style of apache.

As far as performance, the verdict is mixed, it can take time to tune nginx and php-fpm. If you are switching thinking it will be a fast win for php applications with peformance problems, think again, you need to look at your code. If you serve a lot of static assets, this might be a boost for you.

Barnes and Noble, You Could Do Better

Let’s give Barnes and Noble some credit. The Nook color is a nice device as a reader with some tablet stuff. At the time they came out with it, the android honeycomb code base was not available, so one can see why they went with the older code base when they designed their device. The Honeycomb source has been available for a while now. Why not upgrade your device to the new Android codebase so you can run better more modern apps which can be those optimized for a tablet versus a phone. Now Barnes and Noble comes out with the Nook Tablet and they are still in the old android code base. What gives, the honeycomb code has been around for a while now. Why use an aging code base that isn’t even intended for tablet use?

Kindle Fire, Lame Decision

Amazon made a lame decision to build the kindle fire with an android 2.2 tablet and not working with the android Honeycomb class codebase, which are typically 3.2 version. The device has a limited amount of memory as well (8GB) and not 16GB or 32GB which is standard with the honeycomb tablets. the User Interface also looks like it was  borrowed from Barnes and Noble’s Nook Color device, also a android 2.2 device. One wonders what manufacturer is building these devices for them. When the honeycomb devices started to come out, Google clamped down on the rights to the code base so only well established manufacturers could get the honeycomb code base.

Built new Celebrity Astrology Tablet App

I just built a new version of my Celebrity Astrology App for Honeycomb tablets with a new design. It turned out very nice, much better than the standard phone modal designs. Using the new Fragment architecture allows multiple views to be placed on screen, each with separate code, so user isn’t switching as often to new Activities and the user flow is far more natural and easy to work with. This is a real aspect where the 2.2 android devices fall short. I am sure there are those who will try to emulate them for devices like Kindle Fire, but Honeycomb and later devices are far superior and are designed for tablets.

Problems with Early Android Tablets

A full range of tablets have been developed using the Android operating system. The new 3.x Honeycomb versions such as the Motorola Xoom (below) represented a major change for tablets. This is an operating system with many features to help provide a base for a powerful and highly interactive solutions. Initially Android was not built for tablets, only smaller devices such as phones. Eventually support for large screens was added but it was really minor changes and the Ui was not built for tablets. I have several android applications, which later I will have honeycomb specific versions which will make use of the new user interface features. In the mean time I was working on support for the older larger screen devices like the Samsung Galaxy tab (left), which is a non-standard aspect ratio 600 x 1024 dpi, people have reported problems with applications on this device. A developer can rework a layout for specific Android software versions or device features such as aspect ratio. One still is relying on the operating system scaling the layout to fill the space. Android has predefined screen sizes, which one can use and the emulator knows how to use these predefined sizes, but when device manufacturers built tablets from the older, the sizes didn’t exist. A developer dealing with this situation may say, skip the older tablets and spend the energy on the newer tablets, which may be the best solution.

More about the limitations of Mobile devices.

I had been working on an Android app that would work with a popular professional photography site Smug Mug which I have been using to promote my photography. Smug Mug has a nice REST layer with a number of different formats including json, XML, php, and other formats. It works well and is reliable. One of the biggest challenge is the limited bandwidth and power of these devices. The app is nice, allowing to browse from an account. Later I had been planing a photo uploader feature, which is definitely a good idea and could work. My account, which I was using for testing has a lot of photos, and surfaced real challenges in terms of performance. Building a persistence layer with sqlite has promise, along with background threads loading resources, but with a heavily loaded account, the devices don’t keep up. Given some of the newer devices available for instance the Droid Bionic, which will have dual cores, and making available 4G capabilities such as Verizon’s LTE and Sprint’s Wimax, and HSPA+ on T-Mobile and later on AT&T will definitely help.

Published Celebrity Astrology Android App

I have been working on an android application to work with my site. It is now in alpha and can be downloaded from the android marketplace. Built a json service into the celebrity astrology site, after doing mobile/webkit optimized version. Application works with this service to display lists and show content. I needed to downgrade the chartwheel activity to a webview until the image viewer can be perfected.

Mobile Apps from a Shareware Lens

Being involved with mobile development, including web, applications, etc and having developed and successfully sold applications  in the shareware market for many years, has given me an interesting perspective into the Android, iPod, iPhone and iPad applications market. One of the challenges with these markets has been that many applications are sold for little or no cost, nor with an expectation of payment. People used to complain about shareware that you’d never get paid, but those with successful, compelling products did develop substantial businesses, for instance WinZip. Many of those who didn’t do well, didn’t consider market issues and demand for propsed products and consider what it would take to develop a full featured product competitive with commercial products. I had always producted numbers including a shareware version, and several different commercial versions, and the strategy basically worked until the market got saturated. A saturated market is also a problem for mobile applications, consider the number of iphone applications for sale, and the typical prices. There is more space in the Android marketplace, but more challenges including different hardware and software versions. If the android user base continues to grow at a quick pace, which i suspect it will, a significant market could arise, if developers find a way to get paid for their work.

Challenges with Android Development

Been working on several applications for Android, along with supporting Crisp Wireless‘s efforts and expanding mobile advertising opportunities, have discovered a number of issues working on applications with android. First many of the devices have been highly customized, creating significant amounts of fragmentation, which is complicated by the number of active api verstions 1.1 – 2.1, and varying features, for instance input types and navigation controls. Another challenge discovered has been a bug in the browser, that makes work with layers using z-index difficult in that the browser does not respect z-index when doing hit testing, so clicking on a top most level, could wind up activating controls or links on a lower layer. Developing image related applications revealed other issues, including differences between phones such as the Motorola Droid and Emulators. For instance in work with a scrolling, dragging, image browser works fine with the emulator and allows using the application as viewport into a larger image, but the Droid support for Image Views and Scroll Views causes the view to resize to fit, regardless of the settings

SmugMug Api

I have been working on an android app to work with SmugMug and their api. Getting started with their JSON api is good and works as advertised. It’s fast and reliable. Parsing using the org.json libraries ( works well. For working on small footprint applications some changes to their api would be appreciated, particularly being able to work with a smaller result set or a paged result set from the usertree and albums interfaces would be good. In a larger footpring this isn’t a real problem.