On the "Learn Computer" site there's a recent post that wonders if the web development standard of the LAMP (Linux, Apache, MySQL and PHP) stack is "still strong" and will still stand up with new technologies.

This year in tech (like almost every other year) has been filled with buzzwords. Many of them this year, however, are based around big data processing and web content: NoSQL, Hadoop, BigTable - the list goes on. With all the fuss around these new technologies, one might be tempted into thinking that these are the technologies of the future, and that from now on our servers and websites will be built upon, leaving technologies like LAMP in the dust.

They talk about some of the things the LAMP stack doesn't do well like difficulties with scalability on both the web server and database side. There's also mention of the things that it does do well, like getting things up and running quickly and with a solid structure.

That being the case, the LAMP stack is still going very strong, and it's definitely still extremely viable in small and medium-sized deployments; there are no signs of it waning in that regard, and I'd expect it to be a standard deployment for many companies and organizations for quite some time to come.

James Fuller has posted a guide to scaling your web application using the nginx web server, memcached, PHP-FPM and APC caching.

We sell an educational product that serves a predictable 15,000 requests per minute for 10+ hours/day, every day. Instead of Apache, we use nginx with PHP-FPM to handle this traffic. This is becoming a very popular setup for many companies with non-trivial traffic, but I have also found success with it in my small 256MB Ram VPS. For various reasons, nginx does a better job with memory and concurrent connection handling than Apache. In this post, I want to talk about some of the reasons you might want to go with this setup.

He talks about some of the efficiency gains that memcache and nginx can give you pretty easily and some of the common uses for nginx, including using it as a reverse proxy. He talks some about Apache's typical request handling and shows the difference between that and how nginx does its "never block, finish fast" handling. He fits in the other pieces - PHP-FPM, memcached and APC - showing how each of them offers their own types of performance gains for different areas of the application.

In the latest post to his site, Ruslan Yakushev looks at some simple ways you can debug your PHP-based applications running on a Windows Azure platform.

The need to diagnose and troubleshoot application's failures often comes up during deployment to a hosting environment. Some configuration settings in hosting server may differ from what application expects. Often it is not as easy to figure out the cause of the problem in a hosting environment as it is on a development machine. I found the following techniques useful when troubleshooting errors in PHP applications hosted in Windows Azure Web Sites.

He shares seven different tips, some pretty simple, others a bit more difficult requiring other software to be up and working:

• Using phpinfo()
• Checking the wincache settings
• Looking at your error logs
• Turning on the display_errors setting
• Turning on HTTP logging, detailed errors and failed request tracking in the control panel
• Using XDebug
• Getting the statistics for your ClearDB instance

On PHPMaster.com there's a new article that looks at running PHP on a specific environment and some of the considerations the author had to make - using PHP on IBM i.

We've talked about a lot of weird things so far on PHPMaster (well, at least I think some of them are weird), but this may take the cake. In this series I want to talk to you about PHP - and the IBM I. That's right, the IBM i, formerly known as System i and before that as the AS/400. Let's start by dispelling the myth that the i is dinosaur; it's actually a very wonderful machine, and there are lot of opportunities for brave PHP programmers who venture into this realm.

He starts off with "the truth" about the IBM i and some of the features it brings to the table - total system integration, scalability, etc. He talks some about the current GUI the system uses, functionality RPG provides, and some concepts you'll need to think about before getting into PHP on the IBM I.

The folks over at Fortrabbit.com have officially announced the opening of their cloud-based, PHP-focused hosting platform:

We do managed hosting for over 5 years - a business where reliability is one of the core values. And Platform as a Service is just a label for a modern approach of scalable hassle-free hosting solutions. This PaaS market is very young and still a changing category in the wide field of cloud hosting. Listening to customers and their needs will influence the way current services work.

They offer a "Bootstrap" service if you'd like to try it out. It supports PHP 5.4, APC, MySQL, Git integration, Composer support, SSH/SFTP access and DNS management. You can also add on memcache and SSL support if desired.

On DeveloperWorld today there's a new article talking about performance concerns and PHP application (and how your data source might be the problem).

The power of PHP and an RDBMS is the ability to nail the major features of an application with cheaply paid developers in a record amount of time. Unfortunately, the default runtime environment used by PHP is simply an unscalable mess. [...] The truth is that if you have enough servers and enough database servers, you don't have contention. [...] As it turns out, there's a modern solution to the problem: the cloud plus NoSQL. Cloud infrastructure gives us the ability to spin up enough servers, and a NoSQL database enables us to shard our data effectively.

They talk some about why they think PHP's runtine environment is "a dog" based on the non-native pooling of database connections and the lack of a thread-safe environment.

The bottom line: PHP applications are a load on the database due to the constraints of the concurrency model.

He points to the cloud architecture and NoSQL databases as solutions to the scalability problem, providing more scalable resources and flexible data sources.

On PHPBuilder.com there's a recent post looking at debugging Magento applications with some of the built-in tools the platform makes available.

Magento is the world's most popular open source e-commerce platform, relied upon by countless Fortune 500 and small business alike for selling goods and services of all types. [...] But with Magento's considerable power comes a great deal of complexity [but] it can be incredibly difficult to even identify the origin of an error let alone resolve it. You can however dramatically improve your productivity as a Magento developer by taking advantage of a few key debugging features.

They recommend using four tools built into the platform - the developer mode, logging, template path hints and viewing the raw SQL queries. They also recommend using a few other tools like FireBug and the features of Eclipse to help with code formatting and completion.

In his most recent post Brandon Savage looks at a practice that's becoming more and more common - using a REST API as a data source for a web-based application.

We were faced with an increasing number of data sources, including the coming addition of Elastic Search to the data storage system, and maintenance was becoming a problem. Thus, the decision was made to move our data layer to our REST API exclusively, removing all direct access to data storage from the web interface. This is the second such project I've been on where an external API has been used for the retrieval of all data in an application. It's a novel concept, but one that takes some getting used to to be sure.

He talks about some of the advantages of this approach including the ability to be more flexible with the actual technology used to create the API, the ability to write other applications on top of it and a glimpse into some of the process that's been going on as a part of the project.

On the "A Cloudy Place" blog there's a recent post comparing two of the more popular platform-as-a-service PHP offerings out there - PHPFog and PagodaBox.

Platform services like Heroku and AppEngine have been well-known for the last few years and many companies have been using them successfully in their business. They are more attractive to startups, due to low initial cost and smaller headaches involved in setup. 2011 was a great year for platform services, with the emergence of many platform services and a new trend for supporting multiple languages instead of supporting a single language. [...] Here, I will go through two of the PHP platform services I have experimented with: PHPFog and Pagoda Box.

He talks about each of the options and looks at several key elements of each including the deployment process, scalability, monitoring tools, offerings for caching and the database management utilities bundled with the application. Both services offer a "free instance" for you to try out their services, so give them both a try and see what you think.

Anthony Wlodarski has posted a quick example of how he shared the sessions from Zend_Auth in his Zend Framework application over with a Node.js server/application.

Recently on a project I had to make changes to a underlying portion of the sites architecture to move sessions in Zend Framework from file storage to database storage. However this affected a piece of the architecture. Node.js, which manages all our real time interaction, looked at sessions at the file level. This was quite a easy transition for the function as it was abstracted away in a function call so the theory was to just replace the function "guts" with a new component.

The post shows the code he came from (which pulled in the PHP session file and extracted the session data manually) over to a new database-based version that selects from the SESSIONS table and pulls out the data. It's based on the table having an "id" column and the Zend_Auth namespace it uses.