@Calvin, Once upon a time, there was a discussion on this list on how KNEC can optimize their setup for checking results, that thread contained a wealth of information on performance issues from a number of skunks, I highly recommend you dig up that thread and learn from it. On Mon, Jul 9, 2012 at 2:27 PM, TheMburu George <themburu@gmail.com> wrote:

Some concerns here:

Is it for production purposes, if so you would consider having MySQL in its own separate server, then DB is tweak and scarifice options for tables mostly on engines i.e. MYISAM & INNODB choose on application and access or load. To improve perfomance consider having only the necessary services running and disable the unnecessary ones (this is also for security purposes - chkconfig will assist here) Another option would change the runlevel to 3 if defaults to 5 with GUI.

Those are some of the options off my head...

./TheMburu

On Mon, Jul 9, 2012 at 1:21 PM, Calvin Omari <calvinebarongo@gmail.com>wrote:

...

Hi Skunks,

How ca I optimize the performance of a Lamp server to increase it sperfromance

Please if you can give in terms like 1.memory (What is the optmimum memory user and what is cirtical) 2.CPU Usage 3. Config files (my.conf and Appache2d,conf

With Kind Regards ./Cal

-- Our greatest fear is not that we are inadequate, but that we are powerful beyond measure. It is our light, not our darkness, that frightens us.

Calvin Omari Systems Software Developer http://www.facebook.com/barongo

_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------

Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke

-- Conservatism is the adherence to the old tried against the new untried.

_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------

Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke

-- Regards, Peter Karunyu -------------------

Stack overflow, serverfault and co will also pile on ideas.. To scale, it boils down to this 1) Cache everywhere. For example, each of the following entries is a caching/service layer (and reduces the amount of traffic to the next layer) - Use reverse proxies. - Use dedicated servers for static media (nginx or lighttpd) - Use memcached instead of hitting the db. - Use as much memory in the db as you can afford 2) RAM in the db helps alot. Of course, this requires you to tweak your db settings, index your tables, set up a replication service where readers read from replicated slaves... etc 3) Build you service to share nothing. (Are all your requests hitting the db? If so, this will eventually be your bottleneck) This will allow you to scale out. 4) Automate everything.... Really! -> Your code should be in a git/hg repo somewhere, . -> You should have a build environment (or at least unit tests). -> You should deploy your application in an audit-able manner (package it into whatever archive your os uses). -> Use cfengine et al to help you with these tasks. 5) YCFIIYCSI (You can't fix it if you can't see it). I can only show you the door: <door>http://graphite.readthedocs.org/en/latest/index.html</door> and a window: <window>http://square.github.com/cubism/</window> into a new world :) See: http://serverfault.com/questions/272567/setting-up-a-high-speed-load-balanci... On Mon, Jul 9, 2012 at 8:32 PM, Calvin Omari <calvinebarongo@gmail.com>wrote:

@peter Thanks so much

On Mon, Jul 9, 2012 at 3:45 PM, Peter Karunyu <pkarunyu@gmail.com> wrote:

...

@Calvin,

Once upon a time, there was a discussion on this list on how KNEC can optimize their setup for checking results, that thread contained a wealth of information on performance issues from a number of skunks, I highly recommend you dig up that thread and learn from it.

On Mon, Jul 9, 2012 at 2:27 PM, TheMburu George <themburu@gmail.com>wrote:

...

Some concerns here:

Is it for production purposes, if so you would consider having MySQL in its own separate server, then DB is tweak and scarifice options for tables mostly on engines i.e. MYISAM & INNODB choose on application and access or load. To improve perfomance consider having only the necessary services running and disable the unnecessary ones (this is also for security purposes - chkconfig will assist here) Another option would change the runlevel to 3 if defaults to 5 with GUI.

Those are some of the options off my head...

./TheMburu

On Mon, Jul 9, 2012 at 1:21 PM, Calvin Omari <calvinebarongo@gmail.com>wrote:

...

Hi Skunks,

How ca I optimize the performance of a Lamp server to increase it sperfromance

Please if you can give in terms like 1.memory (What is the optmimum memory user and what is cirtical) 2.CPU Usage 3. Config files (my.conf and Appache2d,conf

With Kind Regards ./Cal

-- Our greatest fear is not that we are inadequate, but that we are powerful beyond measure. It is our light, not our darkness, that frightens us.

Calvin Omari Systems Software Developer http://www.facebook.com/barongo

_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------

Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke

-- Conservatism is the adherence to the old tried against the new untried.

_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------

Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke

-- Regards, Peter Karunyu -------------------

_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------

Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke

-- Our greatest fear is not that we are inadequate, but that we are powerful beyond measure. It is our light, not our darkness, that frightens us.

Calvin Omari Systems Software Developer http://www.facebook.com/barongo

_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------

Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke

Let me invite the wrath of dragons and old school gospel adherents with the following. If you are getting Apache can't handle your load with the current resources, and do not have any reason you really want to use Apache, you may as well replace it with Nginx. Call me names now, thank me later.

Calvin, “Performance” with apache, just as is in the bedroom, is a relative/subjective term shrouded in myth and legend. I say relative/subjective because “performance” depends on who is measuring, what is being measured and the task underlying these measurements. Facebook’s perception of performance does differ from that of Safaricom.co.ke though you can bet, in a downtown bar, both sysadmins will throw the word around boisterously. The short of it is that it is not a discrete science. There are no absolutes! The long of it is that there are many variables that affect performance, and your first step in treatment is to find out where one is “lacking” – of course after accepting there are “performance” issues to be addressed. Consider the following typical “performance” killers: i) Congenital disorders: Your application is poorly designed; right from DNA, upwards is mbaya & mboff. ii) Systemic diseases: Your application strategy is computationally expensive and degrades exponentially with a slight increase in load. An example is a PHP for-loop that counts to 100,000 on each request; This will run acceptably for 10 concurrent users but might significantly degrade for 1000 concurrent users iii) Diet: Poor supply (or absorption) of server nutrients like RAM, Bandwidth etc iv) Excessive Weight: Your application responses and/or backend activities are excessively bloated; try reducing these to query, render, serve. Store JavaScript & CSS in minified form and gzipped if possible. Side Note: On this, I STRONGLY maintain it is strategically wrong to carry out repetitive computations on each request as opposed to offloading much of this as is possible to when the data goes into the database. (@Michael Pedersen: are you reading this? J) v) Lousy Partners: Here you place rogue systems and those hackers being hired all over the place. Unfortunately, short of divorce by pulling the cable your only recourse is to learn to live with it. vi) Use Performance Enhancers: Consider bytecode compilers/encoders/accelarators like eAccelarator, XCache or php_apc for PHP. I recommend eAccelarator but on a multi-instance apache setup it seems to misbehave, nothing life-threatening though… vii) Environment: Your application can only get so much out of a 16-bit 286 box Side Note: AMD Interlagos processors have up to 16 cores for under $600 and ASUS Dual CPU boards for approx $400 supporting up to 512GB RAM anyone out there who has had the nerve to try this assembly on DIY basis? While not seeking to slight what it is you are doing, I have seen apache serving in excess of 500 requests a second at peak times with pretty much default settings and a CPU load of less than 30% with database, dns and mail servers on the same box (an Acer desktop) with the good old Windows XP. By web standards and apache deployments out there, this box and load amounts to a small toy, hence my serious doubt that apache is your problem. You are bound to hit other bottlenecks way, way before apache’s default settings become an issue. While requests per second is an important metric to measure, you should be more concerned with the duration per request – how long does it take from the time you receive a request to the time you return a response at the application level. When you get to that side of the world you will realize that apache or its cousins nginx/lighthttpd (even IIS) are least of your problems – typically a http server’s processing constitutes less that 5% of the request’s duration. I stand to be corrected, but I find it unlikely that for a php application that intrinsically takes 1000 milliseconds to process a request under apache will suddenly speed up to serve the same request in 50ms when switched to nginx. Figures floated around the net seem to suggest that apache can do upwards of 6000 requests a second whereas nginx is capable 9000. I have not experienced either nor can I say the figures are authentic, but trust you me on this one: at 1000 requests per second (all http servers out there can do this) your concerns will be way beyond squeezing an extra 10ms from your http server. Assuming a modest average response size of 5kb, at 1000 requests a second you will need uplink bandwidth upwards of 40mbps… Locally, not even NMG with a combined suite of most popular sites are halfway up at that scale, is your application at that level? That said, here are a couple of optimizations you could look at: a) Assuming your issue of performance relates to sluggishness: i) RAM can never be enough, but first move to 64-bit hardware and OS platform. 32-bit systems have an implicit limit of 2GB per process. Intel released some magic called PAE that raises this limit to 3GB but I doubt apache is by default compiled to take advantage of those extensions. Go figure out from the source code and good luck J. The 2GB/process limit may not apply if you are running apache with the prefork mpm. Get PAE details here: http://en.wikipedia.org/wiki/Physical_Address_Extension ii) Use mod_deflate to reduce up to 70% of your bandwidth. Additional strategies here are using proxy servers like squid to shield your apache deployment iii) Use mod_expires to instruct in-transit and browser caches not to keep requesting content that does not change frequently iv) KeepAlive directive: Reduce (or eliminate) keep alive. I find that KeepAlive set to 3 to be optimal than the default 15, but you may need to experiment with this by looking at your analytics in terms of the average stay on a page and number of resources required to load a page completely. Rational here is that higher keep-alive values unnecessarily tie up resources on the server without necessarily adding benefit to page load times v) Timeout directive: lower this value from the default of 300 to something like 30 but beware of your folks on slow connections, rationale is the same as for keep alive vi) Separate your dynamic content from static content. Dynamic content suffers from RAM hogging owing to your scripting environment (whether NGinX, LightHTTPD, Apache or IIS – the difference is the same). Problem here is that worker threads allocate RAM but never release it back to the OS when finished even if serving the next request will require less RAM than is allocated. (ironically this is done for performance reasons). You could consider the MaxRequestsPerChild directive to force killing of workers after a certain number of requests to reclaim RAM – also useful if you suspect there is a module leaking memory. Static content on the other hand benefits from OS facilities for memory mapping frequently accessed files. Static content ought to be stored in pre-compressed format (gzip) for direct serving without having to commit the server’s resources to compress these at each request vii) Combine your JavaScript and CSS files into as few as possible per page. Combine your images – especially applies to those numerous small images/icons used for madoido. Set the expires header far into the future viii) Of course your disk RPMs do matter but I find this an over kill. Am told a raid 5 disk setup can also speed up things significantly but am yet to personally measure this. I prefer to avoid disks altogether and majorly run applications based on a RAM cache. b) Assuming your issue of performance relates to number of concurrent requests i) Raise the MaxClients directive to something like 300 and ThreadsPerChild to something like 50. Experiment this with your heaviest script with respect to RAM (remember you have a 2GB limit on 32 bit systems) on NT based systems only ThreadsPerChild applies, set it to something like 400. Caveat here is that when apache runs out of ram during a request, it returns a HTTP error 500. On thread-based systems, it hangs and users get a WSoD ii) A more advanced - but simple J (sic) alternative is to setup apache load balancing by instantiating several instances of apache on the back end as workers, each with default settings but running on different ports and setup another apache on port 80 in reverse proxy facing the web. Here you will need mod_proxy and mod_load_balancer modules. The web-facing apache should be stripped of all modules (especially those related to scripting like mod_php or mod_perl) so that its ThreadsPerChild, MaxClients and MaxRequestsPerChild can be increased significantly without hitting RAM issues All said and done, you ought to know your actual application metrics per cluster of users. Things like average bandwith per batch of say 100 users, RAM/CPU utilization at low,normal and peak load times etc. If all the above is implemented but fails, then you have a very good and disirable problem. You have massive traffic (and assuming dollars to boot). Setup a server farm and go for a layer 4/7 load balancer. I would recommend a unit from KEMP technologies. Lastly, as a rule of thumb, in my experience, if the server does below 300 requests a second at peak load, I had rather play pacman than bother tweaking configs Hope this helps. Regards Outstanding Online Investment Content Provider 2009 – Computer Society of Kenya From: skunkworks-bounces@lists.my.co.ke [mailto:skunkworks-bounces@lists.my.co.ke] On Behalf Of Odhiambo Washington Sent: Wednesday, July 11, 2012 4:41 PM To: Skunkworks Mailing List Cc: calvine_barongo@yahoo.com Subject: Re: [Skunkworks] IMproving perfomance of a Lamp Server Names!!! On Wed, Jul 11, 2012 at 4:36 PM, Dennis Kioko <dmbuvi@gmail.com> wrote: Let me invite the wrath of dragons and old school gospel adherents with the following. If you are getting Apache can't handle your load with the current resources, and do not have any reason you really want to use Apache, you may as well replace it with Nginx. Call me names now, thank me later. _______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24 <http://my.co.ke/phpbb/viewtopic.php?f=24&t=94> &t=94 ------------ Other services @ http://my.co.ke -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I can't hear you -- I'm using the scrambler.

@Eugene Thanks alot for the insight On Thu, Jul 12, 2012 at 5:58 PM, Bernard Owuor <b_owuor@yahoo.com> wrote:

Great, entertaining but educative write-up. Didn't need to read but you got my attention to the very last line. Such pieces need to be preserved somewhere.

------------------------------ *From:* Eugene Lidede (Synergy) <eugene@synergy.co.ke> *To:* 'Skunkworks Mailing List' <skunkworks@lists.my.co.ke> *Cc:* calvine_barongo@yahoo.com *Sent:* Thursday, July 12, 2012 5:12 PM *Subject:* Re: [Skunkworks] Improving performance of a Lamp Server

Calvin,

“Performance” with apache, just as is in the bedroom, is a relative/subjective term shrouded in myth and legend. I say relative/subjective because “performance” depends on who is measuring, what is being measured and the task underlying these measurements. Facebook’s perception of performance does differ from that of Safaricom.co.ke<http://safaricom.co.ke/>though you can bet, in a downtown bar, both sysadmins will throw the word around boisterously. The short of it is that it is not a discrete science. There are no absolutes!

The long of it is that there are many variables that affect performance, and your first step in treatment is to find out where one is “lacking” – of course after accepting there are “performance” issues to be addressed.

Consider the following typical “performance” killers:

i) *Congenital disorders*: Your application is poorly designed; right from DNA, upwards is mbaya & mboff. ii) *Systemic diseases*: Your application strategy is computationally expensive and degrades exponentially with a slight increase in load. An example is a PHP for-loop that counts to 100,000 on each request; This will run acceptably for 10 concurrent users but might significantly degrade for 1000 concurrent users iii) *Diet*: Poor supply (or absorption) of server nutrients like RAM, Bandwidth etc iv) *Excessive Weight*: Your application responses and/or backend activities are excessively bloated; try reducing these to query, render, serve. Store JavaScript & CSS in minified form and gzipped if possible. *Side Note:* *On this, I STRONGLY maintain it is strategically wrong to carry out repetitive computations on each request as opposed to offloading much of this as is possible to when the data goes into the database. (@Michael Pedersen: are you reading this? **J**)* v) *Lousy Partners*: Here you place rogue systems and those hackers being hired all over the place. Unfortunately, short of divorce by pulling the cable your only recourse is to learn to live with it. vi) *Use Performance Enhancers*: Consider bytecode compilers/encoders/accelarators like eAccelarator, XCache or php_apc for PHP. I recommend eAccelarator but on a multi-instance apache setup it seems to misbehave, nothing life-threatening though… vii) *Environment*: Your application can only get so much out of a 16-bit 286 box *Side Note: AMD Interlagos processors have up to 16 cores for under $600 and ASUS Dual CPU boards for approx $400 supporting up to 512GB RAM anyone out there who has had the nerve to try this assembly on DIY basis?*

While not seeking to slight what it is you are doing, I have seen apache serving in excess of 500 requests a second at peak times with pretty much default settings and a CPU load of less than 30% with database, dns and mail servers on the same box (an Acer desktop) with the good old Windows XP. By web standards and apache deployments out there, this box and load amounts to a small toy, hence my serious doubt that apache is your problem. You are bound to hit other bottlenecks way, way before apache’s default settings become an issue.

While requests per second is an important metric to measure, you should be more concerned with the duration per request – how long does it take from the time you receive a request to the time you return a response at the application level. When you get to that side of the world you will realize that apache or its cousins nginx/lighthttpd (even IIS) are least of your problems – typically a http server’s processing constitutes less that 5% of the request’s duration. I stand to be corrected, but I find it unlikely that for a php application that intrinsically takes 1000 milliseconds to process a request under apache will suddenly speed up to serve the same request in 50ms when switched to nginx.

Figures floated around the net seem to suggest that apache can do upwards of 6000 requests a second whereas nginx is capable 9000. I have not experienced either nor can I say the figures are authentic, but trust you me on this one: at 1000 requests per second (all http servers out there can do this) your concerns will be way beyond squeezing an extra 10ms from your http server. Assuming a modest average response size of 5kb, at 1000 requests a second you will need uplink bandwidth upwards of 40mbps… Locally, not even NMG with a combined suite of most popular sites are halfway up at that scale, is your application at that level?

That said, here are a couple of optimizations you could look at:

a) Assuming your issue of performance relates to sluggishness: i) RAM can never be enough, but first move to 64-bit hardware and OS platform. 32-bit systems have an implicit limit of 2GB per process. Intel released some magic called PAE that raises this limit to 3GB but I doubt apache is by default compiled to take advantage of those extensions. Go figure out from the source code and good luck J. The 2GB/process limit may not apply if you are running apache with the prefork mpm. Get PAE details here: http://en.wikipedia.org/wiki/Physical_Address_Extension ii) Use mod_deflate to reduce up to 70% of your bandwidth. Additional strategies here are using proxy servers like squid to shield your apache deployment iii) Use mod_expires to instruct in-transit and browser caches not to keep requesting content that does not change frequently iv) KeepAlive directive: Reduce (or eliminate) keep alive. I find that KeepAlive set to 3 to be optimal than the default 15, but you may need to experiment with this by looking at your analytics in terms of the average stay on a page and number of resources required to load a page completely. Rational here is that higher keep-alive values unnecessarily tie up resources on the server without necessarily adding benefit to page load times v) Timeout directive: lower this value from the default of 300 to something like 30 but beware of your folks on slow connections, rationale is the same as for keep alive vi) Separate your dynamic content from static content. Dynamic content suffers from RAM hogging owing to your scripting environment (whether NGinX, LightHTTPD, Apache or IIS – the difference is the same). Problem here is that worker threads allocate RAM but never release it back to the OS when finished even if serving the next request will require less RAM than is allocated. (ironically this is done for performance reasons). You could consider the MaxRequestsPerChild directive to force killing of workers after a certain number of requests to reclaim RAM – also useful if you suspect there is a module leaking memory. Static content on the other hand benefits from OS facilities for memory mapping frequently accessed files. Static content ought to be stored in pre-compressed format (gzip) for direct serving without having to commit the server’s resources to compress these at each request vii) Combine your JavaScript and CSS files into as few as possible per page. Combine your images – especially applies to those numerous small images/icons used for madoido. Set the expires header far into the future viii) Of course your disk RPMs do matter but I find this an over kill. Am told a raid 5 disk setup can also speed up things significantly but am yet to personally measure this. I prefer to avoid disks altogether and majorly run applications based on a RAM cache.

b) Assuming your issue of performance relates to number of concurrent requests i) Raise the MaxClients directive to something like 300 and ThreadsPerChild to something like 50. Experiment this with your heaviest script with respect to RAM (remember you have a 2GB limit on 32 bit systems) on NT based systems only ThreadsPerChild applies, set it to something like 400. Caveat here is that when apache runs out of ram during a request, it returns a HTTP error 500. On thread-based systems, it hangs and users get a WSoD ii) A more advanced - but simple J (sic) alternative is to setup apache load balancing by instantiating several instances of apache on the back end as workers, each with default settings but running on different ports and setup another apache on port 80 in reverse proxy facing the web. Here you will need mod_proxy and mod_load_balancer modules. The web-facing apache should be stripped of all modules (especially those related to scripting like mod_php or mod_perl) so that its ThreadsPerChild, MaxClients and MaxRequestsPerChild can be increased significantly without hitting RAM issues

All said and done, you ought to know your actual application metrics per cluster of users. Things like average bandwith per batch of say 100 users, RAM/CPU utilization at low,normal and peak load times etc. If all the above is implemented but fails, then you have a very good and disirable problem. You have massive traffic (and assuming dollars to boot). Setup a server farm and go for a layer 4/7 load balancer. I would recommend a unit from KEMP technologies.

Lastly, as a rule of thumb, in my experience, if the server does below 300 requests a second at peak load, I had rather play pacman than bother tweaking configs

Hope this helps.

Regards

*Outstanding Online Investment Content Provider 2009* – Computer Society of Kenya

*From:* skunkworks-bounces@lists.my.co.ke [mailto: skunkworks-bounces@lists.my.co.ke] *On Behalf Of *Odhiambo Washington *Sent:* Wednesday, July 11, 2012 4:41 PM *To:* Skunkworks Mailing List *Cc:* calvine_barongo@yahoo.com *Subject:* Re: [Skunkworks] IMproving perfomance of a Lamp Server

Names!!!

On Wed, Jul 11, 2012 at 4:36 PM, Dennis Kioko <dmbuvi@gmail.com> wrote: Let me invite the wrath of dragons and old school gospel adherents with the following.

If you are getting Apache can't handle your load with the current resources, and do not have any reason you really want to use Apache, you may as well replace it with Nginx.

Call me names now, thank me later.

_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------

Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke

-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I can't hear you -- I'm using the scrambler.

_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------

Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke

_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------

Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke

-- Our greatest fear is not that we are inadequate, but that we are powerful beyond measure. It is our light, not our darkness, that frightens us. Calvin Omari Systems Software Developer http://www.facebook.com/barongo

Ooops.. That was for Eugene. :-) On Thu, Jul 12, 2012 at 7:16 PM, Humphrey Kirui <hkirui@gmail.com> wrote:

Good stuff there Calvine! All round end to end optimization.

Would have easily mistaken your writing for Rich Bowen's: he of the Apache Software foundation & the Apache Cookbook: http://shop.oreilly.com/product/9780596001919.do The guy is actually born & bred Kenyan. :-)

Rgds, Humphrey.