AWS Autoloader fails when using APC with apc.stat = 0 about aws-sdk-php

[mtdowling]

I doubt that there will be anything we can do here other than add documentation, but can you give us more information about your environment?

• What platform are you using (OS, which version, what web server, PHP version, etc)?
• What version of the SDK are you using?
• Are you running in Apache and seeing this problem?
• Did this occur after recently updating?
• Did you try manually clearing the APC cache?

[tdondich]

OS: Ubuntu 12.04 LTS
Web Server: Apache 2.2.22
PHP Version: 5.3.10-1ubuntu3.5 (Suhosin Patch 0.9.10)
SDK Version: Latest Release, AWS PHP SDK 2

Yes, running Apache. No, this is an initial install of AWS SDK.
Apache restarts to manually clear the cache.

When using apc.stat=1 , everything works fine. When using apc.stat=0, things fail horribly.

I believe it has something to do with the autoloader.

[tdondich]

I've determined that with phar: archives , realpath, which is used by recent versions of APC will not resolve the path. Therefore, any configuraitons with apc.stat=0 will fail and fail hard.

I suggest providing an archive version of aws sdk php that is NOT bundled in phar with an OPTIONAL class-loader initialization (you could simply just have the file be the phar stub). Putting all Vendor and Aws top-level directories also make it easier for people to write their own class loader. This, for example, is my class loader:

spl_autoload_register(function ($class) {
    @include_once(dirname(__FILE__) . '/lib/' . str_replace('_', DIRECTORY_SEPARATOR, str_replace('\\', DIRECTORY_SEPARATOR, $class)) . '.php');
});

This classloader avoids relative paths making apc.stat=0 safe and fast.

Because the new SDK uses a lot of different php files, the stat calls add up. On high performant sites, we need to provide an alternative to make sure apc.stat=0 functions.

[mtdowling]

Thanks for digging into this. Actually though, APC does not support phar files. If you're worried about performance, you should probably use Composer with an optimized autoloader: http://getcomposer.org/doc/03-cli.md#install. I'll try to reproduce this behavior and update our documentation to reflect this.

We do actually have downloadable distributions of the SDK available if you'd like to use them instead of installing through Composer. Take a look at http://pear.amazonwebservices.com. Each version listed provides a tarball containing the phar as well as the raw source code. You'll need to register your own autoloader if you use a tarball. We follow PSR-0, so this should fit in well with whatever autloaders you are currently using.

[tdondich]

Actually, Phar's work fine with APC. The only thing that does NOT, is stat=0. By not calling this out there is a false sense that the phar can be used in full production environments (which many use stat=0). It bit me in the buttocks, and I'm sure as more people attempt to adopt v2, it'll hit them as well.

And I totally agree, the AWS directory follows PSR-0. Everything else does as well as LONG as you extract EACH of the dependencies in the correct place (of which they are not in PSR-0 state inside the phar archive. For example, vendor/symfony/event-dispatcher/Symfony/Component/EventDispatcher is not a valid PSR-0 file path for the \Symfony\Component\EventDispatcher class. So a little tweaking is required when dealing with the archive.

[mtdowling]

Yeah, phars work, but according to the author of the phar extension, APC doesn't cache them at all. We need to communicate this better in our documentation.

We currently support three distribution formats: Composer, PEAR, and a phar file. Have you considered using Composer?

[tdondich]

Sure, I could consider using Composer. As it stands right now, this is a production application with dependencies already baked in. So migrating to Composer would be a process in itself. :) I'm giving a +1 to the adding more to the documentation/installation process to help point this out for those environments which don't have the resources/plan to use Composer and already have their own autoloaders and dependency layout.

[mtdowling]

If we were to create another distribution of our SDK, then what sort of package layout are you looking for? The SDK has a dependency on Guzzle and the Symfony2 EventDispatcher. How would we add all of that to an archive in a way that would work for all project structures?

[tdondich]

./Aws
./Guzzle
./Doctrine
./Symfony
./Monolog

(The vendor src dirs have the PSR-0 ready directory there. You'd just raise them top-level).

This way you create a bundle that is not Composer dependent and doesn't rely on Phar (for those of us that use apc.stat=0). It'd just be important to create a download that includes all dependencies (at the specifically supported versions).

[jeremeamia]

@tdondich We are shipping a zip starting today. You can grab it at http://pear.amazonwebservices.com/get/aws.zip.

We will also be adding this section to the user guide: https://github.com/aws/aws-sdk-php/blob/master/docs/installation.rst#installing-via-zip