This package provides a way to store your application files in Memcached pool with automatic parsing using eval() upon retrieval.
I wrote this after trolling a friend of mine how storing files in Memcached is faster than including them from disk, so while there are definite uses for this under right circumstances make sure you understand what you are doing.
First let’s look at benchmarks running in VirtualBox on MacBook Pro:
Loaded 500 files using regular include() in 0.020308017730713 Loaded 500 files using MemFS in 0.15591597557068 Loaded 500 files using MemFS (10 files at the time) 0.018874883651733 Loaded 500 files using MemFS (250 files at the time) 0.015585899353027 Loaded 500 files using MemFS (500 files at the time) 0.016402959823608
Keep in mind that the laptop in question has SSD drive.
As you can see, when compared directly one for one you might get performance degration but as you scale up and request 10+ files you will see a slight speed increase of about 0.00143313407 seconds.
Not much but this benchmark is not scientific and was performed on a empty machine with SSD drive with no I/O load. Your setup might be different and if you take 0.0014 * requests per seconds your application is processing you might see a benefit of saving 14 seconds per 10000 requests.
- Servers that host PHP based applications in a saturated or slow I/O environment. - Distributed applications that constantly update their logic, can be updated by updating memory pool with new code that they will include and evaluate. - Applications that need to load and parse more than 1 file in a consecutive order.
For optimal results, make sure server hosting cache pool is hosted on a separate server but shares the LAN with your web servers.
Depending on your load the link between the servers must be greater than 100Mbps.
Make sure to use igBinary with latest version of daemon.
If you have your own autoloader, simply update namespaces and drop the files into your frameworks library.
For people that do not have that setup, you can visit http://getcomposer.org to install composer on your system. After installation simply run `composer install` in parent directory of this distribution to generate vendor/ directory with a cross system autoloader.
You can benchmark and gauge how much benefit this optimization might bring you by running:
make sure to run it twice before reading the results so the application can cache files
You can grab the source code from my GitHub repository:https://github.com/AlekseyKorzun/memfs-php
I recently got to play around with Magento (eCommerce platform based on Zend Framework) and had to figure out default billing and shipping information for all of our current clients.
Apparently developer community build around Magento is pretty amateurish judging by technical discussions that are found on their forums.
When I looked up how to retrieve default address information, the answers would all be in a pure PHP code that utilized Magento models to retrieve data.
Thats bloated and frankly plain dumb. Not to mention that some of us do not use PHP for system specific tasks.
In my case I’m using Python so I needed a SQL query that I can run against our Magento database to retrieve required data.
Magento stores data with dozens of relations (very confusing if you are just starting out) and some of relations do not make much sense. They split out entity properties by type (datetime, int, text, etc) and associate each type separately to main entity via id.
Not to mention that address data is considered to be it’s own entity and has it’s indexing outside customers space.
First we have to grab default billing and shipping ids associated to our user accounts:
SELECT `ce`.`email`, `default_billing_id`.`value` AS `default_billing`, `default_shipping_id`.`value` AS `default_shipping` FROM `customer_entity` AS `ce` LEFT JOIN `customer_entity_int` AS `default_billing_id` ON (`default_billing_id`.`entity_id` = `ce`.`entity_id`) AND (`default_billing_id`.`attribute_id` = '14') LEFT JOIN `customer_entity_int` AS `default_shipping_id` ON (`default_shipping_id`.`entity_id` = `ce`.`entity_id`) AND (`default_shipping_id`.`attribute_id` = '13') WHERE (`ce`.`entity_type_id` = 1) AND (`ce`.`is_active` = 1)
As you can see attribute id of ‘13’ represents default shipping identifier and attribute ‘14’ represents default billing identifier.
Now we need to join across address entity to retrieve actual address information linked to default addresses the user has, in this example I will retrieve default zip code for both billing and shipping address:
SELECT `ce`.`email`, `default_billing_id`.`value` AS `default_billing`, `default_shipping_id`.`value` AS `default_shipping`, `default_billing_zipcode`.`value` AS `default_billing_zipcode`, `default_shipping_zipcode`.`value` AS `default_shipping_zipcode` FROM `customer_entity` AS `ce` LEFT JOIN `customer_entity_int` AS `default_billing_id` ON (`default_billing_id`.`entity_id` = `ce`.`entity_id`) AND (`default_billing_id`.`attribute_id` = '14') LEFT JOIN `customer_entity_int` AS `default_shipping_id` ON (`default_shipping_id`.`entity_id` = `ce`.`entity_id`) AND (`default_shipping_id`.`attribute_id` = '13') LEFT JOIN `customer_address_entity_varchar` AS `default_shipping_zipcode` ON (`default_shipping_id`.`value` = `default_shipping_zipcode`.`entity_id`) AND (`default_shipping_zipcode`.`attribute_id` = '29') LEFT JOIN `customer_address_entity_varchar` AS `default_billing_zipcode` ON (`default_billing_id`.`value` = `default_billing_zipcode`.`entity_id`) AND (`default_billing_zipcode`.`attribute_id` = '29') WHERE (`ce`.`entity_type_id` = 1) AND (`ce`.`is_active` = 1)
Note that attribute_id’s might vary in your installation. You might consider modifying this query to use attribute labels for a more portable approach.
Feel free to reach out to me if you have any questions.
If you interact with any of Amazon’s Web Services using PHP you should be using their SDK.
It’s very powerful and pretty simple to get started with.
In my case I did not want to checkout their whole repository into my frameworks namespace and decided to use .phar file they provided as
To me, using a .phar file for third party libraries kind of makes sense if I’m not planning to extend or overwrite any of the available functionality.
Plus if you have your own directory conventions and don’t want to bother re-factoring Amazon’s structure, .phar might come in handy.
The issue I ran into (not really an issue but inconsistency always bothers me as an engineer) is that if you are using namespaces and your own autoloader, requiring .phar file anywhere you need to access AWS is pretty ghetto.
The way I solved it is by using a very simple wrapper that either loads configuration (using \library\configuration as an example) containing your key/secret or takes key/secret as a constructor parameter and simply stores instance of AWS internally while routing all the calls directly to it.
You can check out this approach on my GitHub page located here: https://github.com/AlekseyKorzun/aws-sdk-wrapper
Just a quick announcement that I updated my PHP 5 client for Cloud Servers(tm) API.
Some of the major fixes include retry limiting for authentication requests, support for updated response codes (especially for server/image requests) and better examples.
Code was also updated to conform to PSR-2 and phpDocumentator 2.
Grab the latest version here: http://alekseykorzun.github.io/rackspace-open-cloud-php/
I have pretty high standards when it comes to code and felt like the current PHP 5 library that Twilio offered did not really fit well with modern frameworks.
So I decided to rewrite it, if you have your own framework and looking for a cleaner Twilio client make sure give this a try.
Find out more at: http://alekseykorzun.github.com/Twilio-PHP-5/