On the Symfony blog there's a post covering some of the recent improvements in the framework that can help to make creating and updating Symfony projects faster via some recent changes speeding up the Composer installation.

A few years ago, we introduced the Symfony Installer as the fastest way to create new Symfony projects. While Composer took up to several minutes to create a new project, Symfony Installer did the same in less than ten seconds.

The trick was that the installer downloaded a ZIP archive with all the dependencies required by the specific Symfony version you were installing, so it was not necessary that Composer resolved the project dependencies.

However, with the release of Symfony 4 we deprecated the Symfony Installer in favor of Composer, because we wanted to use standard development tools as much as possible. Sadly this made creating new Symfony projects slower and, in some cases, it triggered "out of memory" exceptions while Composer was resolving the dependencies.

The post talks about the changes they made to the Composer installation process, mentioning the two major changes: including a composer.lock to prevent version resolution and removal of all legacy Composer tags. They also share some benchmarks for the installation both before and after the changes showing a jump of at least ten seconds post-changes.

Lorna Mitchell has a post on her site that wants to help you out when Composer reports a "lock file out of date" warning when you try to update your Composer dependencies. She provides three options to help resolve this issue.

Composer is dependency management for PHP, and it consists of two main files: [composer.json and composer.lock]. Crucially, the composer.lock also includes a hash of the current composer.json when it updates, so you can always tell if you've added a requirement to the composer.json file and forgotten to install it.

The post includes three different ways to correct the warning message:

• Option one: upgrade all of the things
• Option two: try to work out which composer.json change caused this
• Option three: do nothing, safely

The first two options are preferable to the last one (essentially overriding the error) but it could be used in cases where you think Composer is just getting things wrong.

Dayle Rees has a post to his site help to demystify the composer.lock file for the Composer users out there - what it's for, how it works and why you may or may not want to have it in version control.

Everywhere that I go, conference, the supermarket, the dentist, building sites, people always ask me about the Composer lock file. It's a mystery that seems to cause confusion all across the globe. Well, boys and girls, I'm here today to de-mystify the lock file once and for all.

He starts with a new project and some simple dependencies (three of them), two with specific versions defined and one with a wildcard. Once a composer install is run, the packages are downloaded and the composer.lock file is created. He talks about the contents of the lock file and how they relate to the version of the library Composer has installed, the exact version to be precise. He then gets to the question many wonder about the lock file - should I commit it to my version control system? He suggests that, if you need exact versions installed, then yes. This helps keep versions the same across the board of a team and ensures other people working with the library are using compatible library versions. He ends the post talking about how to use the lock file (install vs update) and what changes could be made in one versus the other.

Paul Reinheimer had a problem - when he was making asynchronous requests back to his server from his frontend (Ajax) there was a slowness he noticed when more than one connection was fired off. In this new post to his site he traces through how he found the answer and what he did to fix it.

Digging a little deeper into the queries being executed, I was expecting return times in the order of 200ms, not the several seconds I was seeing. Installing XHGui only furthered my confusion: session_start() was the culprit with incredibly high run times.

He thought first about the number of session files (stored locally) being too large and causing issues, but that turned out to be a false lead. Instead, the issue was something PHP does by default...and does correctly. When PHP executes, it locks the session file, preventing another process from writing to it. This caused the delay he saw until it was unlocked. His solution? Use session_write_close immediately after writing information to unlock the session for further use.

Ole Markus has a new post to his blog looking at a technique for working with memcached and fetching data out of the store using a binary semaphore for better performance.

A typical document takes but a few hundred milliseconds to generate when a single request for the document enters the backend. The problem is that this is a highload website. In its current form, the backend serves hundreds of pages per second. This pretty much guarantees that the backend will concurrently receive cache miss on multiple languages and at the same time also receive cache miss on the pre-translated document.

Given that he wants the translated version to be the one that's always shared, a problem can come up when the cache request is "missed" and the document starts generating from multiple places. His fix for the situation is that only the first miss generates and all others see a lock on it and wait for it to be removed before successfully fetching the result. He provides code in a "LockedMemcached" class to help make it all more useful.

In this quick post to the Purple Rock Scissors blog, there's a suggestion from Rob Zienert about how you can avoid a "cache stampede" on your site's caching tool with the help of a pseudo-lock on the record.

A cache stampede occurs when a cached item expires and multiple clients attempt to repopulate the cache at the same time. Take for example a page cache expires and a few thousand people try to refresh the generated HTML. That's a lot of instant load — hitting the database, re-saving the cache and so-on: it's a lot of extra processing that can bring a website to its knees. One of the many ways to avoid this from happening is to apply pseudo-locks to a cache (and works great with Memcache).

He includes a code snippet example showing how to create the lock using a Zend_Cache setup by looking for a URI-based lock file and setting a "locked" value to true when someone else is using it.

Benjamin Eberlei has a new post today about how you can use PHPUnit tests to ensure that database locking is working like it should. With the help of Gearman he shows you how to use some locking tests for Doctrine setups to ensure rows locked for a specific amount of time are staying that way.

Since PHP does not support process forking or threads naturally you run into a serious problem. How do you execute two database queries in parallel and verify that indeed one query is locking read access for the second one? [...] Solving this problem with Gearman provides a pretty nice "real-world" example for the Job-Server that I wanted to share.

He includes the code to make a sample "agent" to run a transaction and lock a certain set of information. On the other side, there's the worker method that loops to find the locked items until they disappear. The PHPUnit tests case combines these in a "testLockIsAcquired" with a handler for the completed test.

Andrew Johnstone, inspired by a previous post on file locking to avoid cron job overlaps, as posted his own method and give a few more examples of how it can be done.

In order for a lock to work correctly it must handle, Atomicity / Race Conditions, and Signaling. I use the following bash script to create locks for crontabs and ensure single execution of scripts.

His bash script looks at the processes currently running and checks to be sure there's not already one there. If not, it takes the script given and executes an instance. If the process has finished running but the lock file is still there, it removes it and moves on to the execute. He includes a few examples of how to use it and the code for a PHP class that makes it easy to check if something's running, locked or what the current signal/status of the process is.

In this new post from Abhinav Singh on how to use file locking to keep your cron jobs from trying to use the same resources.

Cron jobs are hidden building blocks for most of the websites. They are generally used to process/aggregate data in the background. However as a website starts to grow and there is gigabytes of data to be processed by every cron job, chances are that our cron jobs might overlap and possibly corrupt our data. In this blog post, I will demonstrate how can we avoid such overlaps by using simple locking techniques. I will also discuss a few edge cases we need to consider while using locks to avoid overlap.

He includes some sample code - both the class to create the functionality and a script showing how to make use of it (and, of course, an example of it in use).

Evert Pot has posted about a library he's creating to integrate WebDAV support with PHP and make things simpler for those needing to access the shares.

I intend to make this library as easy as possible to use, without making it a black-box-like system. Focus will not be on everything WebDAV could possibly provide, but instead on the features that are actually supported by the operating systems.

His goal is to make it as simple as making a 'File' and 'Directory' class to interface with the remote system and has two things he's deliberating on as far as features to include in the library - support for the custom properties WebDAV allows and the ability to lock files and directories.

If you'd like to check out the current progress of the library, check out its page on the Google Code site (as well as this discussion group he's set up).