WHAT: Symfony 2 Live Conference
WHERE: P’unk Avenue offices, 1168 E. Passyunk Ave, Philadelphia PA
WHEN: 11am Wednesday, June 23rd

Thanks to our hub status, You do not have to buy your own Symfony 2 ticket to attend at our office.

We’re looking forward to discussion and possibly busting out the Symfony 2 sandbox and experimenting after the conference.

No, not by a long shot, not any time soon. Symfony 2 will not be backwards compatible in a “super easy upgrade path” way, which is a valid choice to make improvements that would otherwise be impossible but an obvious problem for existing projects. And we have plenty of those. What’s more, Symfony 2 requires PHP 5.3.x at a minimum, and we know how tough it can be to move clients along just to PHP 5.2.x.

Fortunately, Sensio had the wisdom to make Symfony 1.4 a long-term-support release. And since Apostrophe 1.x is happily married to Symfony 1.4, that means we’re all in good shape.

Symfony 1.4 is supported until November of 2012, and Apostrophe 1.x will also be supported until at least November of 2012.

At some point, Apostrophe 2.x will come into being and it will be based on Symfony 2, but we have many client and internal projects that are purring away happily on Symfony 1.4 and we have absolutely no interest in abandoning it. So you can very safely pursue client projects based on the current stable releases of Apostrophe.

Wondering where the blog is? In the context of a larger website, a blog doesn’t always jump out and shake you by the lapels. On philly360 it’s the engine behind The Insider:

Notice the navigation links at the left. You can spelunk by category, date or tag.

Don’t see the categories? That’s because, on this particular site, they have been rebranded as “Features.” This is a common way to use Apostrophe blog categories: as separate “blogs.” It’s possible to set them up with entirely separate pages at any point in the site or, as in this case, as subpages of the main blog.

The Apostrophe blog plugin also drives the Events page:

But that’s not quite the whole story. In truth, the blog is front and center on the home page. Let’s take another look:

Notice the “News” and “Events” sections. These are Apostrophe slots pulling in recent blog posts and recent events from the blog plugin. Editors can plug in recent posts and events, or plug specific posts and events into specific pages. And designers can customize the presentation of posts to suit any page template.

Visitors can comment on blog posts in a spam-free environment, optionally logging in via Facebook, Twitter and several other services thanks to the excellent Disqus blog comment management service.

All of these capabilities are standard in Apostrophe’s blog plugin. And it’s open source, so Symfony developers can dive right in. Visit the Apostrophe documentation for details.

“Great, so how come your own blog is still running WordPress?” That will change! It’s not broken and we have plenty of client projects to build, so it’s not our first priority today. But our blog will be migrating to punkave.com/window. We need to take a little time to design it nicely and take advantage of Disqus’ “import comments from Wordpress” feature.

CALLER: “I chose your open source project for my client project and it’s due tomorrow and it doesn’t work! This is your problem and you must fix it immediately or I will explode!”

TOM: [CLICK]

CALLER: “Your code has several bugs, which I am going to describe in harsh and unsympathetic but highly accurate detail.”

TOM: [Hangs up on caller, then fixes those bugs]

CALLER: “I translated your program into Swahili! Here’s the XLIFF file. Also I found a bug. Here’s a patch file.”

TOM: “Yay! Welcome to the cool people’s club! We’re having chocolate ice cream. Would you like some?”

CALLER: “500 ERROR! AAAAAAAAAAAAAA!”

TOM: “Lower your voice, read your log files, try the dev controller and call back.”

CALLER: [reads own log files, discovers glaringly obvious permissions problem, solves it, is never heard from again]

CALLER: “something isn’t quite right. When I do X, Y and Z, I get the following error message [copies and pastes complete error message].”

TOM: “reproducible bug reports make me deeply happy. I’ve just committed a fix in svn. Would you like some ice cream?”

If you visit our demo site and switch languages you’ll see pages with pretty translated chrome but no content. That, of course, is because our own demonstration web site’s content is currently only available in English. Feel free to play with translating it, but keep in mind that the demo site resets at the top of the hour. If you’re seriously interested in translating our demo site’s content to go along with the nicely translated interface, join the Apostrophe google group and drop us a line to get involved.

Interested in putting this power to work on your projects? Visit apostrophenow.com to find out how we can help you. If you’re a Symfony developer or just a ballsy webmaster who doesn’t mind learning some new tricks, head straight for the Apostrophe manual to check out our installation guide. We do documentation in a big way.

We’d like to thank Quentin Dugauthier (French), Frank Wenzl (German), and Pablo Godel (Spanish) for their hard volunteer work on the translations. Others are working hard on Portuguese and Greek and have been patient through our growing pains as we mastered the fine points of UTF-8 and character sets in our translation system. We’ll be sure to thank them by name when they are done, so you don’t nag them too much now. (:

There are, of course, other important fixes and improvements in Apostrophe 1.0.9, including one security fix. Here’s the list:

• A computer abandoned by an admin who has logged out can no longer be used to edit slots the admin previously edited using cleverly constructed URLs (only an issue on the same computer and if the PHP session has not ended). Note that you must upgrade your myUser class in apps/frontend/lib to extend aSecurityUser rather than sfGuardSecurityUser to get this fix (aSecurityUser is a subclass of the latter)
• Global or virtual-page media slots can be edited successfully on Symfony pages that are not CMS pages
• Unpublished pages no longer interfere with aNavigationAccordion layout
• Fixtures no longer use HTML tags our filters remove on edit
• Plaintext slots now autolink URLs and email address (obfuscated) as described in the manual
• Search engine updates refactored, search engine now updates when you save page settings
• ‘tool’ option to rich text slots now correctly activates the FCK toolbar set name you specify
• Slot save/cancel buttons now survive form validation passes properly (thanks to Spike)
• Date widget is XHTML correct (thanks Spike)
• Engines now work when the CMS is not mounted at the root of the site (important for those using the CMS as a subfolder of a site dominated by other Symfony modules)
• Attempting to attach a list of zero items to a slideshow no longer results in adding all items in the media repository
• Cross-browser and XHTML strictness fixes
• Moved lib/base to lib/action (you must symfony cc)
• Lost connections between existing media slots and media items when editing other media slots: fixed. Also, slideshows etc. are no longer removed on “cancel,” and selecting zero media items no longer selects all media items
• i18n of over 99% of the admin interface (many thanks to Quentin, Galileo, Frank, Pablo and Fotis), new languages are regularly being added to the demo project’s apps/frontend/i18n folder
• More convenient i18n of your site content (temporary titles supplied, all navigation controls work for pages whose titles are not yet translated)
• Aesthetic upgrades
• Superadmins can grant superadmin status
• Some demo-specific styles moved from a.css to demo.css
• Optional language selector in a/login partial
• Global admin buttons now have separate names and labels (labels can be internationalized) and a documented way to add and reorder them in app.yml
• Alpha channel is now preserved when rendering PNGs from a PNG original with gd (not available with netpbm)
• Compact PDF slot style, without inline preview (you can override this in aMediaPDF/normalView if you want it back and you have ghostscript)
• Better IE6 upgrade message
• Various private methods now protected for easier app level overrides

The Apostrophe Google Group has become pretty active lately. It has been so great to connect up with people around the world that are using Apostrophe to make sites for themselves or their clients. It feels great to be able to share something that we have labored long and hard on. It is especially exciting to know that we scratched our own itch and made something that works well for us and for our clients. It’s also exciting to see it helping with other peoples’ itches.

We love the passion that people have about Apostrophe. We have seen that in many forms including the suggestion of new features. What I want to make clear, though, is that Apostrophe does have a point of view embedded in all of the decisions that we make as we design and build it. If someone asks for a new feature, I always ask, “What problem are you trying to solve?” or “Can you describe a situation where the need for this feature came up?”

I think that surprises some people. They assume that our goal is to have the longest list of features of any web content management tool. In fact, that is not our goal. Our goal is to create a tool that is joyful to use while still being powerful.

The reason people fall in love with Apostrophe is because we have worked very hard to keep it simple and elegant. We are always going to ask the tough question of what problem does this solve. (Can it be solved with what is already built?)

We will never build a feature just because we wonder if it can be done. We are not in a feature race with anyone. We have found that sometimes people pick something based on a list of features, but our clients and users pick Apostrophe based on how they feel when they use it (think Tiffany’s, not Walmart). They feel empowered and excited. They have often mentioned the joyfulness of using Apostrophe. We have even heard people gasp and giggle when editing content for the first time.

All that said, we don’t want to be the solution for everyone, but we hope you enjoy using Apostrophe if it works for you.

________

Note: I just finished reading Rework by Jason Fried and David Heinemeier Hansson of 37 Signals, and it reminded me that I should be putting down more of our thoughts on Apostrophe. These decisions have been embedded in Apostrophe from the beginning, but we have not always been good about communicating them.

ok ok, it’s Monday but you can’t let that stop the dance party!

With frameworks like Symfony, you can build them faster still, and follow modern programming practices at the same time.

And Apostrophe strips away yet another layer of effort if your site calls for a content management system.

Yes, Java has more raw speed, all else being equal (which it never is). But as the LISP programmers used to say, “a moment of regret, a lifetime of convenience.”

Still, sooner or later success catches up with you and you want your site to cope with Serious Traffic… or cope with moderate traffic on a cheap virtual machine… or at the very least, not be dog-slow with just a handful of users on the system.

There’s a lot of advice out there about optimizing PHP code, some of it well worth your while. And there’s excitement about HipHop, Facebook’s new native code compiler for PHP. But these are drastic steps that require you to rewrite your code or adopt less proven and more awkward ways of delivering your code.

Justified? Sure, sometimes, on the biggest projects in the world (like Facebook) (*). But as Donald Knuth says, “premature optimization is the root of all evil.” That’s because tweaking your code for speed’s sake usually makes it harder to maintain and less adaptable to new requirements.

What most developers don’t realize is that there are three major factors that typically slow down PHP projects based on frameworks (like Symfony or, sigh, Drupal) so much that code profiling and database query redesign don’t even have a chance to become relevant factors. Fix these things first before you worry about other issues:

1. Compiling code over and over and over. Would you wait for your Mac to recompile MacOS X from source code every time you boot it up? Of course not. How about every time you fill out a dialog box? That’s pretty much what you’re doing every time you access a PHP-driven website that doesn’t use a bytecode cache.

2. Waiting and waiting and waiting for web browsers to make another request, pinning down web server processes that your other users need. By default Apache usually lets browsers hold on to a connection for up to 15 seconds just in case they ask for more. This is a good thing in many ways, but 15 seconds is far too long. Which leads us to #3:

3. Tying up a “fat” web server process with PHP on board for every request, even requests for the zillions of little static PNGs that probably make up your page design. (**) A typical Apache web server configuration with mod_php suffers from this flaw, fatally limiting the number of simultaneous users you can handle.

So what can we do about these problems? Quite a bit as it turns out. I’ll start with the low-hanging fruit and move on to the tougher stuff. The fascinating common thread with all of these suggestions: no changes at all to your PHP code.

Stop Recompiling Your World: APC

APC, aka the Alternative PHP Cache, is a bytecode cache. What does that mean and what good does it do?

Today, when users visit your website, your web server struggles to translate all of your PHP code into a more manageable “bytecode.” And only then does it actually run the bytecode and output the page.

Bytecode isn’t true native machine code and doesn’t run as fast as compiled Java, and certainly not as fast as compiled C. That’s why Facebook’s HipHop project seeks to convert PHP code to C++, and then compile that to native code. But that’s a drastic step with far-reaching consequences for your project. Before you think about HipHop, try a simpler fix: stop throwing away the bytecode and starting over from zero on every new request that comes to the site!

In our experience, enabling APC reduces both memory usage and the time required to respond to a request by vast amounts. Even a simple action in Symfony or Drupal can implicitly require that quite a bit of PHP code be compiled. With APC, all of that code stays compiled, and that simple action actually runs quickly and simply.

APC is simply indispensable for serious PHP programming. Turn it on. Make sure it’s really working. And enjoy dramatic improvements in your social life, hair and skin.

Installing APC

Depending on your system, APC may already be installed or even, if you are very lucky, activated correctly. Virtual machine hosting from ServerGrove comes with APC “out of the box.” Most shared hosting probably won’t because it increases the amount of memory pinned down for each user on the shared server, but if you care about your website’s speed, you’re not using shared hosting. Get a small, cheap virtual machine from ServerGrove instead (or if you must, do it the hard way and set up a Slicehost or linode virtual machine; you’ll learn a lot about system administration).

On our slicehost VMs, we found it necessary to install APC with pecl, the PHP package manager for extensions (like PEAR, but different in that they are not written in plain PHP):

pecl install apc

We then enable it in php.ini (you won’t be able to do this in a .htaccess file):

; Must enable APC otherwise we compile all of Symfony on every hit
extension=apc.so
; Give APC enough shared memory to handle Symfony, etc.
apc.shm_size = 48
apc.include_once_override = 1
apc.mmap_file_mask = /tmp/apc.XXXXXX

Then restart Apache:

apachectl restart

And you’re off to the races. The first page access will be as slow as ever, but subsequent accesses will be much, much faster. You can also check whether you’re saving memory and time using Symfony’s debugging toolbar.

Your system also likely has an APC status page that you can copy to your website to check out the current status of APC. It’s fun to play with.

Dialing Back Keepalive: Too Much of a Good Thing

In the beginning there was NCSA Mosaic, and it was pretty cool, all things considered. But it wasn’t fast.

Mosaic made only one request of a web server at a time. Trying to do more probably seemed rude. Besides, lots of web servers couldn’t cope with more than one request a time at all. But that would only happen if two users came along at once, and that was never gonna happen, right?

Ah, those were the (sad, lame, pathetic) days. Scroll to the present. Typical web browsers first request the page, say “hang on a minute,” open perhaps five more connections besides and then make note of all the images, JavaScript files, CSS files and other embedded bric-a-brac and start requesting all of those things. Consecutively and in parallel. Really a lot.

The Apache web server is actually very good at handling this. But by default, it is very generous: it lets the browser leave it hangin’ for fifteen seconds. That means an Apache process and all of the memory it requires is tied up for all of that time, just doin’ nothin’. And that’s bad news.

Fortunately it’s very easy to fix this in your httpd.conf file (actually, in our setups, this is usually in apache2.conf):

KeepAliveTimeout 2

Restart Apache:

apachectl restart

And you’ll find that your site can suddenly cope with higher loads. That’s because your’re not tying up valuable resources waiting around for more requests from browsers that are already using and reusing five other connections to your server. The browser is welcome to promptly request more files and finish its business with you, but not to stand around twiddling its thumbs while you wonder if you have a date or not.

You can turn keepalive off entirely, but doing so forces the browser to “call back” for each and every little image file on your page, which is a terrible idea. So use it… just don’t let it abuse you.

MaxClients: Does This mod_php Make My Butt Look Big?

mod_php is fast. Unlike the old-fashioned “PHP as CGI” approach, mod_php keeps the PHP interpreter itself loaded in memory and ready to rock at all times, and that’s good.

But mod_php is also a pig. For a big-deal web application that wrangles lots of database objects, or makes thumbnails of uploaded images, or does pretty much anything cool, it’s not uncommon for a PHP process to use 50MB of memory or more. More miserly code can still hit 30MB without much difficulty.

We first ran into this problem when we wanted to move smaller client sites onto small VMs, so that they could have well-secured, highly-reliable web hosting at an affordable price. They tended to bog down and become unusable quickly.

We discovered that dialing back keepalive helped tremendously with the problem. And we also learned to do the math and figure out how many reasonably fat PHP Apache processes would really fit in the memory available to the slice, and configure Apache to run no more than that. In httpd.conf:

MaxClients          20

This may seem drastic (OMG! I can’t serve more than 20 simultaneous users!) but here’s the thing: you already can’t. If you try, if you leave this set to its much higher default, the result will be a VM crushed by the need to swap out all of these Apache processes to virtual memory while they are still trying to do work. As the operating systems geeks say, the “resident set size” of your Apache and PHP processes is bigger than your actual memory. And when that happens you’re SOL.

When you set MaxClients to a realistic number, what happens instead is this:

You can handle up to 20 connections at once gracefully.
That 21st connection queues up and is dealt with soon after.
If the average load doesn’t exceed 20 connections, you’re fine.

If too many connections queue up, some people will not get through. But you will still be able to get through to other services on the VM… like the ssh connection you use to administer it and change these settings. Without that, you’re stuck in a seesaw battle, shutting down your website, tweaking settings, firing it up again and watching it gradually become overwhelmed.

What Is The Right MaxClients For Me?

Take the amount of RAM in your server (for instance, a 256MB slicehost VM). Subtract a bit of overhead (at least 50MB, ideally more, bigger VMs are better that way). Now divide by the largest PHP process you typically see when running “top” or “ps -auxw | grep httpd” (you might have to grep for apache rather than httpd depending on your OS). For instance, if your processes top off around 30MB, you can set MaxClients to (256-30) divided by 30. Round down and you have a MaxClients setting of 7.

One snag: some operating systems show shared memory (like the memory used by APC) as memory in use by every one of the Apache processes, even though it is really only allocated once and shared by all of them. If your APC cache is set to 40MB and all of your PHP processes seem 40MB overweight, you can increase MaxClients somewhat to allow for this.

Yes, you can use swap space (virtual memory) to go higher, but this just forces the machine to swap, using disk space in place of memory to do hard things it needs to do quickly and freezing you out of your own machine. So don’t do that.

PHP, I Love You, But Could You Sleep Downstairs?

Dialing back the number of Apache processes is a helpful step that allows your server to say no with grace and style when there is too much traffic. But the underlying problem remains: we can’t deal with a lot of requests at once. And the reason we can’t do that is PHP. So we’re stuck. Or are we?

Our Apache processes are “fat” in terms of memory use because of the memory taken up by PHP. But most of the requests we’re handling are for little PNG files and not-so-little JPEG files and CSS files and JavaScript files… all of which Apache can serve up handily with about three bytes of memory and a piece of string.

The obvious solution is to serve PHP requests and static files separately. And many sites do this explicitly, using absolute URLs pointing at a different subdomain for static files. For example:

<img src=”http://static.example.com/foo.png” />

Now, this is a fine thing and I have nothing against it. When you design things this way you can use entirely separate machines to serve these requests if you wish, and that’s pretty exciting from a performance perspective. Many bigger sites find this well worth their while.

But you are also complicating things. And you are forced to change working code, which introduces the potential for new and exciting bugs.

There’s another approach (well, one of many): FastCGI. FastCGI is an enhanced version of the CGI protocol that appeared quite early in the evolution of the web but caught on only with those most concerned about performance. I must admit I am a very recent convert, ironic since FastCGI is a bit out of vogue today. But there are solid reasons to consider using it.

FastCGI has three big advantages:

1. FastCGI runs PHP processes separately from Apache. That means Apache can stay lean and mean, not only running much smaller processes (and therefore perhaps many more of them) but even running in a separate “worker thread” that outperforms the separate-processes mode by a long mile. This is a big, big win.

2. It can reuse a single process for new PHP requests (***), avoiding the need to restart the PHP interpreter. That’s nice, but mod_php can do the same trick, and mod_php is capable of sharing APC cache memory between all of its processes. And FastCGI can’t do that… or it wouldn’t be able to without a little help from PHP:

3. PHP comes with a special FastCGI mode in which it manages several child processes of its own, and allows all of those processes to share a single APC cache.

Put these advantages together and you have the holy grail of PHP hosting: PHP running separately from Apache, but still maintaining all of the performance advantages of the APC cache. And we can do it without changing a line of PHP.

Installing FastCGI

There’s one catch: Apache 2.0 ships with mod_cgid, a rewritten version of FastCGI that complies with the official Apache license, instead of the oh-so-fractionally-different FastCGI license (****). And it’s nice and all, except that it completely lacks the third advantage of FastCGI I mentioned above. If you want the benefits I’m describing here, you have to use the real mod_fastcgi. Accept no substitutes.

These directions work for slicehost Ubuntu slices and other Ubuntu-based Linux. They will not work exactly as-is for servergrove which is centos-based:

Edit /etc/apt/sources.list
Add multiverse, which includes software with insufficiently “open” licenses, such as mod_fastcgi. Change intrepid to the ubuntu version on your box, it’ll be mentioned all over sources.list:

# tom@punkave.com: we want multiverse support so we can have real mod_fastcgi
deb http://us.archive.ubuntu.com/ubuntu/ intrepid multiverse
deb-src http://us.archive.ubuntu.com/ubuntu/ intrepid multiverse
deb http://us.archive.ubuntu.com/ubuntu/ intrepid-updates multiverse
deb-src http://us.archive.ubuntu.com/ubuntu/ intrepid-updates multiverse

Now do:

apt-get update
apt-get install libapache2-mod-fastcgi

Now edit /etc/apache2/mods-available/fastcgi.conf to read:

<IfModule mod_fastcgi.c>
  # One shared PHP-managed fastcgi for all sites
  Alias /fcgi /var/local/fcgi
  # IMPORTANT: without this we get more than one instance
  # of our wrapper, which itself spawns 20 PHP processes, so
  # that would be Bad (tm)
  FastCgiConfig -idle-timeout 20 -maxClassProcesses 1
  <Directory /var/local/fcgi>
    # Use the + so we don't clobber other options that
    # may be needed. You might want FollowSymLinks here
    Options +ExecCGI
  </Directory>
  AddType application/x-httpd-php5 .php
  AddHandler fastcgi-script .fcgi
  Action application/x-httpd-php5 /fcgi/php-cgi-wrapper.fcgi
</IfModule>

Now set up /var/local/fcgi/php-cgi-wrapper.fcgi:

mkdir -p /var/local/fcgi/
vi /var/local/fcgi/php-cgi-wrapper.fcgi

Paste in:

#!/bin/sh

# We like to use the same settings we formerly used for apache mod_php.
# You don't want this if your php.ini is in /etc
PHPRC="/etc/php5/apache2"
export PHPRC
# We can accommodate about 20 50mb processes on a 1GB slice. More than that
# will swap, making people wait and locking us out of our own box.
# Better idea: just make people wait to begin with
PHP_FCGI_CHILDREN=20
export PHP_FCGI_CHILDREN
exec /usr/bin/php-cgi

Note the figure 20, this can be adjusted for the box in question if it has more or less memory to offer. Also note that we use the same php.ini we used with mod_php (/etc/php5/apache2). You can change that if you think it appropriate but don’t forget to bring settings over.

Set permissions:

chmod -R 755 /var/local/fcgi

IMPORTANT: comment out any php_value lines in .htaccess files for the sites on this box, and move those directives to php.ini. Otherwise you will get errors form those sites and they won’t work.

If two sites on the same slice really must have separate php.ini settings, consider separate slices for the sites. It’s possible to set up more than one fastcgi pool, but that halves the resources available and so on.

# Commented out; moved to /etc/php/apache2/php.ini
# php_value arg_separator.output &

Disable mod_php5, enable mod_fastcgi in its place, enable mod_actions which is required by the above, and restart Apache:

a2dismod php5; a2enmod fastcgi; a2enmod actions; apache2ctl restart

Now test the site. Also check /var/log/error.log and/or error.logs for individual sites to make sure you see mentions of fastcgi and not mod_php.

If you get an error and you see this in the log:

[Thu Mar 04 02:51:33 2010] [alert] [client 69.141.215.7] (2)No such file or directory: FastCGI: failed to connect to (dynamic) server "/var/local/fcgi/php-cgi-wrapper.fcgi": something is seriously wrong, any chance the socket/named_pipe directory was removed?, see the FastCgiIpcDir directive

There’s a chance it’s just a transitory problem; first-time fastcgi startups seem to be a bit temperamental, but we’ve had no problems in the long haul. Restart apache again:

apache2ctl restart

If it still doesn’t work reenable mod_php5:

a2dismod fastcgi; a2enmod php5; apache2ctl restart

And do some more reading.

Late-breaking news: PHP 5.3.3 and the new SAPI FPM

In addition to the built-in support for managing FastCGI child processes in php-cgi, PHP 5.3.3 introduces a new PHP binary, php-fpm, that offers a superior implementation of FastCGI support. You don’t have to switch if you are happy with the FastCGI support in php-cgi, which is fortunate because your operating system might not offer PHP 5.3.3 or its new php-fpm binary (aka the SAPI FPM) yet.

Setting up the new SAPI is not that different from setting up FastCGI with php-cgi, provided you can get past the probable need to compile it yourself (of course, by the time you read this, there may be a php-fpm package in your favorite Debian repository).

Interested parties should check out the new FastCGI Process Manager article on www.php.net.

Installing the Worker Thread MPM

Once you reach this point successfully, you are ready to switch Apache from “prefork” mode (which mod_php requires) to “worker thread” mode. Worker thread mode is blindingly, ridunculously fast at serving static stuff, and uses mod_fastcgi to take care of PHP. You can’t do this with mod_php enabled, so you must succeed in setting up fastcgi first (see above):

apt-get install apache2-mpm-worker

That will restart Apache by itself. But if not you can do so manually.

Now test the site again. If it doesn’t work, you can easily undo this:

apt-get install apache2-mpm-prefork

To verify success:

ps auxw | grep apache

Should show fewer processes (unless your operating system shows threads as processes). The processes you do have are running many threads (lightweight subprocesses that are exposed to each other’s memory etc. and generally less expensive).

ps auxw | grep php

Should show roughly 20 processes, plus a process to manage the others. Significantly more than 20 (say, 40+) indicates you goofed and didn’t set maxClassProcesses properly and you’re going to have a lot of PHP processes on your hands in a hurry, so fix that. (I’m assuming you chose 20 processes as your limit for PHP above.)

Now beat up on the site a bit. Remember to check any other sites on the same box, you just changed how all of your PHP sites on this box are run.

Now copy apc.php to the web folder of one of your sites and visit that URL to see a page giving stats about how well the cache is working. You should see a healthy percentage of cache hits if you have revisited some of the same pages or at least reused Symfony and Doctrine. If not check whether you ever enabled APC for this site. You can find apc.php in /usr/share/php/apc.php on some systems. Its absence doesn’t mean APC is not available.

You need to set up both mpm-worker and fastcgi to get the most benefit here. The worker MPM can serve zillions of static files in a hurry with minimal memory usage each. However, after setting up fastcgi, you can certainly crank up MaxClients and stick with the prefork MPM if you prefer.

Alternatives

APC alternatives: there are alternatives to the APC cache. These include eAccelerator and Zend Optimizer. I’m not an expert on the others, but APC will be standard in PHP 6.0, so I recommend standardizing on it now. For extreme cases (i.e. “we’re getting as big as Facebook and we have too much code to start thinking about improving the code itself in any serious way”), by all means consider HipHop. You can think of it as a distant relative of APC that provides a roughly 2x performance boost at a large cost in complexity and maintenance.

FastCGI alternatives: some will disagree with my recommendation of FastCGI. mod_cgid supposedly has better child process management… with the glaring exception that APC is not shared, ballooning your memory requirements in a seriously ugly way. Better alternatives include running the nginx (pronounced “engine X”) web server as a lightweight “front end” that serves static files directly and proxies other requests through to an Apache server running mod_php. One can also run Apache (without the fat mod_php module) as a front end for another instance of Apache. In these setups, the back-end Apache doesn’t accept connections except from the front-end one, and Apache’s reverse proxy features come into play. Personally I like the simplicity of Apache communicating directly with a master PHP process via the FastCGI protocol.

Conclusion

ERRRRRRRRRRRROOOOOMMMMMMM

Beep beep

ERRRRRRRRRRRRRRRRRROOMMMMMMMM

[HONK]

Zoom!

(*) Actually, one of Facebook’s stated goals for HipHop is to avoid rewriting and presumably hand-optimizing their existing PHP code. They have billyuns and billyuns of lines of PHP code, not all of it written by hardcore software jocks. So if a handful of smart folks can make mediocre PHP run 50% faster, that’s a big deal for Facebook. For most of us it makes more sense to pick the low-hanging fruit first (see all of the above), and then stop making separate SQL queries for every single darn object on the page, and then maybe think about HipHop. I’m not knocking HipHop here at all, it’s an impressive technical accomplishment. But if you’re starting with HipHop as your
first optimization, you’re not paying attention.

(**) Yes, you could use CSS sprites to speed these up, and given time you probably should, but in the short term let’s talk about ways to deliver them quickly without getting bogged down in hard-to-maintain optimizations. With HTTP keepalive working for us instead of against us, the performance difference between delivering 20 PNGs and one PNG is mostly on the browser side— still good to avoid, but not a brutal impact on your web server. One step at a time, okay?

(***) Yes, FastCGI is capable of running lots of things other than PHP, but this is a PHP article. So: neener.

(****) There’s nothing wrong with the FastCGI license. It’s a very boring MIT-style license that shouldn’t interfere with your commercial use.

Probably the easiest way to get a feel for Apostrophe is to go to our demo site and login. The user name is “admin” and the password is “demo”. Keep in mind that the content resets itself every hour on the hour.

If you want to get your bearings before you you do that, head over to the newly revamped Apostrophe site. For the very interested, you should consider checking out our extensive README which includes an Installation section, an Editor’s guide, a Designer’s guide and a Developer’s guide.

Now for some of the highlights.

Slots!

There are rich text, image, slideshow, video, button, PDF, Raw HTML, and other slots built in. If you have used Apostrophe before, you know that you can add a slot on a page, choose what you want to place and then reorder it. New custom slots can also be made for any project.

Slot Options

For some time we have wanted to be able to give you more fine control of a specific slot. For instance, what if you wanted to make the background color of a some text slots yellow, and some white? In the past that would have required two slots. Now, it can just be an option of the same text slot. In this screenshot, you can see that we allow you to switch between different types of slideshows. Make sure you try that out in the demo. It is probably our favorite new feature. We really sweated the details on making sure the option control was contextual. We hope you appreciate the effort.

There are many other new features and highlights, but for the moment I will leave you to find them in the demo (remember: user is “admin” and password is “demo”) or in the documentation. (We promise to highlight these in future posts.)

So, what does this mean to you?

Well, it depends. If you are a PHP developer with Symfony skills you can get started today. From our README:

Right now Apostrophe is best suited to PHP developers who want to make an intuitive content management system available to their clients. Apostrophe is very easy for your clients to edit, administer and maintain once it is set up. Right now, though, Apostrophe installations does call for some command line skills and a willingness to learn about Symfony. We are working to reduce the learning curve.

If you are a front-end developer and want to get started using Apostrophe, talk to us. We are in the process of working out a package where we set up a staging server with Symfony and Apostrophe running on it. We would train you on templating in Apostrophe and you should be up in running in a day or two.

If you don’t want to go that route, here is what we suggest:

Front-end developers who do not yet have PHP and Symfony skills but wish to set up an Apostrophe site by themselves should consider tackling the Symfony tutorial to get up to speed. It’s not necessary to complete the entire tutorial, but it helps to have at least a passing familiarity with Symfony.

If you just think Apostrophe is rad and you want one… like now, just drop us a line. We would be happy to design and implement an Apostrophe site for you. You would be joining some good company if you do.

Surprise!

We (more accurately Tom) decided to build an extra slot last night as a gift for making you wait an extra day. Isn’t that nice of us (him)?

If you are observant you may have noticed an extra slot in the screenshot above. So without further ado, we present the Feed Slot (commonly referred to as the RSS Feed slot, but it will take Atom feeds as well). Use this to bring in your Twitter updates or maybe our Apostrophe SVN code commit feed.

Feel free to thank us anytime. (We like expensive beer.)

This is really just the beginning. We hope you have an opportunity to check out Apostrophe. We would love to hear from you if you do. Comments below would be much appreciated (and read), as well.
__________________

Don’t forget to follow us on Twitter for on-going updates: @apostrophenow

If you are a developer, the Apostrophe Trac is the home of the open source community. On that site you can open support tickets, browse and contribute to the Wiki, and access and potentially contribute to the source code via svn (you’ll need to contact us if you want write access).

Also, please join the Apostrophe Google Group if you want to tap into the community of people using Apostrophe to get support and help.

We have decided to push back the release of Apostrophe 1.0 until tomorrow.

We are truly in the home stretch. Just hitting a few bugs, finishing up documentation and adding some instructional content to the demo site. To tide you over, we are publishing this screencast of how you add video to a project by searching YouTube from within Apostrophe. Note how we bring in associated metadata (url, title, etc). For the record, you can add video by pasting in embed codes from countless other services like Viddler and Vimeo.

Please tune back in tomorrow.

P.S. We are not blaming the snow for the delay, but did want to note that we are certainly under a deep white blanket here in Philadelphia.

If you follow us carefully, you have probably already seen this screencast of Apostrophe, our open source content management system built in the Symfony PHP Web Framework. You also probably know that we have built many sites with it at Duke University (Trinity College, Theater Studies, Economics, Evolutionary Anthropology, etc) and others like the Kimberton Waldorf School, the Environmental Management Assistance Program, and Diversified Community Services. Since it is an open source project, other teams have used Apostrophe to power their sites to provide easy content management, as well.

You may be wondering why we haven’t made an official 1.0 release to date?

The answer is simply that every time we were going to do that, we decided that it could use one more cool feature or could be re-factored in this way or that. No regrets, though. For this first official 1.0 release, we have done so many under-the-hood changes and updates that we are glad we waited.

I wanted to post to let you know that we will be sharing screencasts and screenshots of features over the next few days leading up to the release (and beyond). Hold on to your hat and get ready for the ride.

Coincidently, we are timing this release so that it was ready for Symfony Live. Tom will be in attendance spreading the good word. If you are planning on being there, drop us a line so Tom can buy you a drink.