The first thing to look at is the general PHP performance on your server. Out of the box PHP is very poorly equipped for high traffic websites, and chances are you already have a few of these optimizations in place, combined these tricks will more then double the performance of your shindig deployment.

To be able to give some semi-meaningful measurements I’ll be using the QPS (queries per second) of how fast php-shindig can render the OpenSocial Dev App (OSDA) on my workstation, which has a single Quad Core 2 Duo @ 3Ghz and a single SATA II disk, so a standard of the rack server should be able to do a bit better then the results I’m getting here. The base line of a plain outo-of-the-box php and shindig configuration is ~ 210 QPS.

Opcode Cache

Perhaps the most important tip for php performance is to install an opcode cache.. PHP is still an interpreted language, and that means that in it’s default configuration, on every page hit, it will read your PHP code and interpret it into opcodes. An op(eration)code is the instruction that the Zend engine actually performs, and this constantly interpreting will take most of your server’s resources! The solution is to install an opcode cache that caches these compiled instructions in memory, so that your webserver can focus on actually executing the code. My personal favorite is the Alternative PHP Cache (APC)

Using APC the QPS on my workstation goes from 210 to 385, a pretty impressive performance increase!

PHP FatMM

The next tip is to use the php-fatmm patch, the fat memory manager patch changes the way that the PHP engine allocates memory, instead of (de/)allocating memory on the fly it will pre-allocate a configured amount of memory, and only if that runs out will it allocate more; The end result is that it can save PHP having to do thousands of alloc()’s, which means it can spend more time doing useful stuff This does mean your server process will use more memory, and I wouldn’t advice to use this on a server that also serves static content or very simple php scripts, but for a server that is dedicated to php-shindig, this is just what the doctor ordered.

Re-benchmarking our OSDA rendering using both APC and php-fatmm brings us to 410 QPS, while not as earth-shattering as APC, still a very nice improvement!

Disk IO – Caching back-ends to use

Now with the basic PHP bottle-necks out of the way, lets focus on the other thing that will bring a server to it’s knees: Disk IO. Harddisks are the slowest component in your server and having a lot of reads and writes happening will cause your CPU’s just just spin idly in their sockets waiting for data to appear.

The highest impact change here is to go from a disk based cache in php-shindig (the CacheFile class which is the default configured cache back-end since it works on every platform/configuration) to a memory based caching class. Now there’s two distinct types of cached information in php-shindig, the one is the ‘feature_cache’, where it stores the processed (and if configured, minimized) feature information.. parsing hundreds of little xml and javascript files is a very expensive operation so caching this adds a lot to the efficiency of php-shindig. The other cache type is the general ‘data_cache’, which is used to cache all remote resources such as the gadget xml files, message bundles, all proxied files, etc.

The features information doesn’t take so much space to store, and as such using a close-to-home cache for the feature_cache like the CacheApc class is the best solution, The data cache on the other hand will hold  many thousands of files, so will be considerably larger to store.. as such using a shared cache between your shindig servers is much more efficient, so using CacheMemcache is the optimum solutions there. So by changing the following bits:

'data_cache' => 'CacheMemcache',
'feature_cache' => 'CacheApc',


and rerunning the benchmark brings the total QPS to 435.

Disk IO – PHP Shindig configuration

The last bit of tweaking we can do is to disable the file checking, php-shindig has been coded to fail gracefully and check everything rigorously however that does cause some extra disk IO, however as long you feel certain you won’t go and delete files from your production systems, it’s pretty safe to turn this off, this is done by setting ‘check_file_exists’ to false in the configuration. We can also save some disk IO by changing the relative-path-resolution in the configuration to absolute paths, so change any paths like “realpath(dirname(__FILE__) . ‘/..’) . ‘/’” to their actual locations (like “/var/www/html/shindig/”). And setting ‘debug’ to false removes the last few of these checks. So in the configuration we set:

'debug' => false,
'check_file_exists' => false,
'base_path' => '/var/www/html/shindig/',
'features_path' => '/var/www/html/shindig/features',
'container_path' => '/var/www/html/shindig/config',
'javascript_path' => '/var/www/html/shindig/javascript',
'private_key_file' => '/var/www/html/shindig/php/certs/private.key',
'public_key_file' => '/var/www/html/shindig/certs/public.crt',

Conclusion

With all these measures in place, the benchmark now shows us doing some 450 QPS, more then doubling the 210 QPS we started out with, quite a satisfying result if you consider this means we end up transferring more then 45 megabyte/sec over the network at that point.

Now for the real speed freaks, all these results are based on the 1.0.x release tree from the svn repo, which is what you should be using since the trunk is seeing heavy development for the upcoming 0.9 changes, however the trunk has a re-factored gadget renderer that is a ~ 20-30% faster then the current release, so more performance goodness will be coming your way once the trunk stabilizes and becomes release ready.

So because things have been on hold so long i’ve decided to release and open-source what we have so far, as Eric S. Raymond said: “Release early, release often”.The project has been released under the GPL v2 licence.

In laymen terms this means you can do with it what you want, but you have to contribute your changes back to the community / the project, and you can’t just pick it up and sell it integrated into your own projects as if it was your own, integration into other projects is only allowed if you either contact me for a commercial licence, or if your project is GPL compatible too; However using it in your website, intranet, extranet, etc is fully permitted without any problems. I’ve setup a code.google.com project at:
http://code.google.com/p/webchat2/

To check out the project source:
# svn checkout http://webchat2.googlecode.com/svn/trunk/ webchat2

You can download the source of this initial release here:
http://www.chabotc.com/webchat2/webchat2-1.0.tar.gz

Issues can be reported here:
http://code.google.com/p/webchat2/issues/list

And you can contribute documentation and other usefull information here:
http://code.google.com/p/webchat2/w/list

I’m very open to contributions of any kind, so if you need any help to get started feel free to contact me at chabotc@xs4all.nl

Much of the information about this project can be found in the initial post:
http://www.chabotc.com/generic/chat-prototype-first-public-demo/

And the public demo version is still running at:http://www.chabotc.nl:2001/chat.html

Talking of the public demo, its been running without a glitch or restarting the IRC server or PHP daemon for over 3 months, so it seems its quite stable in real life testing.Do be ware, since the project isn’t completely finished yet, it does mean it currently comes without to much of documentation or instalation guides, and some small bugs remain.

And to get it all running you need a number of things:

• IRC server (hybrid prefered). I used the Fedora Extra’s ircd-hybrid package
• PHP (developed and tested with 5.2.x) Need to have socket extentions enabled. The demo version is running in a chroot’d envirioment, there’s plenty of guides out there on how to set this up if you need more information about this. Should only be a extra layer of security, since there’s no real potential for code injection, however if you are paranoid about security, this could be a good idea
• A modern web browser, like IE6, IE7 or preferable Firefox

When configuring your IRC server (which is used in the backend, and guarantees infinite scalability which is tried and tested) a few things are important:

Set the “throttle_time” to 0 or else connections would be denied if multiple people connect at the same time.Then to allow for more then the pre configured users from one IP (standard this is set to 3 or 4 connections). Change:
max_clients
number_per_ip
max_global
max_local

The demo server on chabotc.nl is set to a max of 4096 connections but any number will do as long as your server can handle it.

Also change the “auth” section in your ircd.conf and comment out the following:
/*flags = need_ident;*/

This is because all connections come from your own server, so it only causes delayes when connecting thru the web chat frontend.Then change your network name and description to something fitting, and you should be all set! There’s a lot of other options in the ircd.conf file, but their pretty well documented in the configuration file and there’s plenty of documentation about it on the web.

After this, check out the webchat2 source, change the port number you want it to listen on (currently defaults to 2001) in chat.php, change the server list in htdocs/js/chatConnectWindow.js(!!) you can hide the selection box and make it default to your local server easily there too and change the default channel in httpServer.php (line 78).

After this you should be able to run the daemon:
# chmod +x ./chat.php
# ./chat.php

if all worked well you should be able to connect to your chat setup thru (replace yourhost.com and port number with your local values):

http://www.yourhost.com:2001/

A few wishlist items that are currently high on my list of things to fix:

• Configuration file for IP’s, port numbers, etc
• Implement IRC /ignore, /query, /whois, /ping and /help commands in back and frontend
• Implement double click on nick (in left list) = open private chat window with that person
• Implement right click menu on nick (in left list) for common options like private chat, whois, etc
• Few cross browser bugs remain, and smiley’s selection still needs to be made! Much in the same style as color parsing in javascript, it needs to insert the image on click, then on sending the msg rewrite the image tag to the matching smiley sequence, aka “:D” etc, translating these smilies to images again is already implemented

There’s plenty of other items that i left out of the list but those are top priority in my perspective and i’ll be working on them as time permits, but i’m very open to patches too

This project brings together a lot of new technologies which had to be developed to make this a feasible, scalable and efficient.

Some of the underlying tools build to make this posible that i consider ’stable enough’ are already released, such as the php Socket Daemon library i wrote to be able to deal with hundreds up to many thousands of “Comet” http connections, and an equal amount of IRC client connections.

Also the javascript to parse the mIRC color codes is already available, also this web site of things relies solely on prototype and script.aculu.us, plus from the ground up implementations of tabs, windows, tooltip, context menu and channel components based on prototype (all to be released soon, together with the main app).

The main application its self will be open-sourced as soon as a few more visual features are finished (such as a context menu to have a visual interface to commands like whois, op, voice, topic, etc..These commands have already been implemented by typing things like: /op NickName, or /topic My New Topic, etc, but they still need a good, usable and attractive interface before the ‘average user’ will understand what and where they are.

Demo

To stress test the framework, and find any bugs that can only happen in the wild, I’m making the current version available as a preview to what is still to come, please feel free to play with it, and leave your comments, compliments and/or bugs reports here

Launch Web Chat Application.

* Please note only Firefox (1.5 & 2.0) and IE 7 have been tested, IE6 and opera still have some problems, which are planned to be addressed shortly. Until then i would strongly recommend using Firefox, in general this is a good idea actually

How to use

When you enter the application you will see a login dialog, enter a valid nickname here (and try to make sure its unique), and select a network to chat on. Currently 2 networks are supported: Local, which is a IRC server running on this server, which allows up to 4096 connections, and ‘EFNet’ (one of the worlds largest irc networks).

EFNet servers however only allow upto a max of 2 or 4 connections from one IP (as is the case with this chat, all connections come from the server), so it tries to pick a random server out of a pre-programmed list. However these slots will fill up quickly, so if your connections fails refresh the page, and try again.Connecting to EFNet takes longer then the local network too, this is due to the identd timeouts those servers maintain, please be patient while its connecting.

Commands

The join channel dialog has already been finished (click the + tab in the upper left corner), however most commands and functionalities don’t have a visual interface yet. However they do have ‘IRC’ style typed counterparts that allow you to use them. These are:

• /join #channel
• /part
• /op Nick
• /deop Nick
• /voice Nick
• /devoice Nick
• /nick newNickname
• /topic Some channel topic
• /invite Nick
• /whois Nick
• /whowas Nick
• /msg Nick some message
• /tell, /privmsg, as same /msg above..
• /quit

Technology

The chat application consists out of a few separate components:

1. Socket daemon library
2. HTTP daemon implementation (for the streaming comet connections for server to client communication, and dealing with the ajax requests for client for the client to server communication)
3. IRC Client implementation (which exchanges the events and messages with the comet http connection, and receives the user’s commands and messages)
4. The web application its self, which is implimented using prototype.js and script.aculo.us

A comet implementation was needed to provide real-time, fully async messaging, see this figure for an overview of the different application communication paradigm’s:

The colors and some graphics were borrowed from yui-ext, a unique look is in development, and i hope to have an alternative theme available at release.

When is the public release?

Ohhh i know the answer to this one: “When its done!”, in all seriousness though, i expect to have a few more good weekends and some of the Christmas holiday left to work on perfecting and finishing this, and your testing will help greatly with that!So expect a final release in early 2007. when it will most likely be released and licensed under the GPL (GNU Public License)Thanks to anyone who will is willing to help test this application, i’m looking forward to your feedback!

Other irc web chat projects

There’s only one viable other option i’m currently aware off, the widely used CGI:IRC (written in perl), however it’s not nearly as full featured, easy to use or scalable as this project

Interview

Ajaxian.com talked to me about this project, and asked me if I could share with them the biggest challenges: the Ajaxian article in which I replied to them:

The greatest challenge writing this was to make it scale up, and keep IO in check. The orignal plan was to layer out the http, irc and comet components, but the overhead of sending all the event trafic over local loops/connections when dealing with hundreds to thousands of connections, is just to much. All the memory bandwidth used would then be multiplied 3x, which was just a to high of a strain on the system.Second challenge was that there were no decent comet implementations available (except for dojo’s which i used as a reference), and there was definitely a challenge that there were no PHP (my preferred language) libraries or tools available which could deal with a large amount of always-on connections, even fast-cgi with something like lighttp just wouldn’t scale to hundreds of live connections, and the memory needed would be horrendous, hence the new php socket daemon library was born, its a riskier model, if the program has a fatal crash (great care was taken to avoid this) the service has to be restarted again (happens automaticly), loosing the client connections in the process, however it now only takes 15Mb of memory under moderate load, and guarantees responses in under 0.15ms, something that would be unfeasible with a clasic apache/php situation.Also most of the heavy lifting (such as link and color parsing, etc) has been lifted to the client, it would be way to heavy for the server to do all of this, and still be able to scale upLikewise the javascript side of things took a bit of trial and error too, some channels can have thousands of messages, and hundreds of members, so browser speed has defiantly been an thing to optimize too.Lastly the back-end uses a plain old IRC server, which is almost infinitely scalable, just add a server, link the IRC servers together, and run another web chat back-end on it, repeat ad infintum.. (irc networks are known to have many hundreds of thousands of people connected, using this as the backbone of the messaging provides guaranteed scalability)

This library contains the following files:

RPMDefines.php : RPM tag type and constants definitions
RPMIO.php : Used to read the RPM header information, and interpret its binary types propery
RPMLead.php : Reads in the RPM lead information (mostly depreciated info, use header info instead)
RPMSignature.php : Reads the signature of the RPM
RPMIndex.php : RPM index reading & parsing
RPMIndexEntry : Class instanced by RPMIndex
RPMHeader.php : RPM Header reading & parsing
RPM.php : demo file, change /path/to/some/file.rpm to a real rpm file, and run to see all the info collected

You can download the library here: phpRPMlib-1.0.tar.gz and here: http://phprpmlib.googlecode.com/files/phpRPMlib-1.0.tar.gz
Google code project page: http://code.google.com/p/phprpmlib/
Subversion repository: http://phprpmlib.googlecode.com/svn/trunk/

This project now has its own page, please see:

http://www.chabotc.nl/webfm/

While going thru my old projects to see which would be of any use to the open-source community, i came along an old project of mine, WebFM (Web File Manager).

I was applying for my previous job when i was asked to write a filemanager demonstrate my php abilities, the time alloted for this undertaking was 2 days, and i’m sure they wanted something a lot simpler, so i may have gone a little over the top when writing this, but i did feel i had a point to make Its Written for PHP 4, but i’m sure with some minor modifications it can be made to work fine with PHP 5.x too.

You can download the tarbal locally: webfm-0.1.tar.gz
or via google code’s download

Google code project page: http://code.google.com/p/webfm/
Subversion repository: http://webfm.googlecode.com/svn/trunk/

To configure the file manager for all virtual hosts and hide the script from the virual host’s document root:
Place fm.php in a dir outside of the document root (for example /var/www/fm.php, and the images in /var/www/fmicons).
Then configure Apache aliases in your httpd.conf to access them as such:
Alias /filemanager “/var/www/fm.php”
Alias /fmicons/ “/var/www/fmicons/”

It tries to be security conscious, stores its passwords outside of the webroot (must have feature), and is very simple to configure for mass-hosting environments.