Low-end CPUs but CPU intensive (WEB) applications

As you can imagine, the CPU of a SparcStation 20 is not the fastest CPU around these days and lacks a lot of features for optimimal performance in comparsion to the CPUs available these days. Still, with its limitations in terms of clock speed and register capabilities, like many other old CPUs regardless the architecture, can be used these days in the modern application solutions, with its speed limitations and not as fast as it’d run on a T2000 or V880 of course. The magic word is caching.

Web proxies
When you run web based applications using PHP and MySQL the chances are you see your CPU usage go to 100% every time somebody or something requests a page.  This has to do with SQL queries and PHP code rendering that has to be done for every page. 

I resolved this on my SparcStation20 by installing a Squid Proxy infront of my Apache webserver.  The parts that can be cached will be served by the Squid Proxy and parts that really have to be rendered will be served by the Apache webserver, which offloads PHP on the Apache server and therefor the CPU.

Configuring a basic Squid proxy is pretty easy. My squid.conf looks like this.

http_port <ip address>:<port_number> accel defaultsite=www.patrickale.org vhost
icp_port 0

cache_mem 128 MB
maximum_object_size_in_memory 8 MB
memory_replacement_policy lru

cache_replacement_policy lru
cache_dir ufs /var/squid 400 16 256

emulate_httpd_log on
acl all src 0.0.0.0/0.0.0.0
cache_mgr cachemaster@patrickale.org
cache_effective_user squid
cache_effective_group squid
cache_peer <apache ip> parent <apache port> 0 no-query originserver default name=pebbles-web
acl valid_dst dstdomain www.patrickale.org pebbles.patrickale.org

cache_peer_access pebbles-web allow valid_dst
cache_peer_access pebbles-web deny all

http_access allow valid_dst
http_access deny all

buffered_logs on

This basicly tells Squid to only allow requests for www.patrickale.org and pebbles.patrickale.org and forward it to my Apache webserver. Simple, is it not?

Application page rendering cache
Unfortunatelly not everything can be catched and cached by a web cache. Most dynamic content applications prevent a web cache to store the data by means of no-cache headers. This is mostly done because the applications assume dynamic data will change in a fast pace and therefor never or almost never will be the same, even when requested in short intervals, or for the simple reason they (the applications) want to guarantee that the last data available is served.

Most applications these days however, come with plugins or built-in functionality to generate static pages out of dynamic content. This will do the MySQL queries and the data rendering once, after which a static page is generated and served to the other end users requesting the same data. Most times the static pages come with an expire time, configurable within the application.

For example, in Gallery2, by default, everything is rendered in PHP, slowing things down a lot. By using the ‘acceleration’ feature, you can create static pages out of your dynamic content, which can be stored and served by Squid and therefor offload the CPU time spent on retreiving dynamic data from the database (like amount of views, random image blocks etc.) Even when you dont use a web cache, you will find the CPU time spent on serving your pages is significantly less.

The side effect of caching though is that your dynamic data might be out of sync with reality. Since you’re making static pages out of your dynamic data, the data of render/making static time is presented till the expire time has been reached. However, this can be resolved by telling users to do a ‘hard refresh’ in their browsers (shift + reload/ ctrl+ reload).

Other methods and conclusion
These are just two examples of how to run somewhat modern applications and their technology. They are free and fairly easy to implement. There are of course other methods to offload the CPU but they most time require in memory caching (memcache, MySQL query cache etc) or plugins that pinch in to your data rendering mechanism like PHP which might not be compatible with the applications you use (ACP, eAccelerator). They are however, worth playing around with and giving a try to see how they affect your applications.

I tried eAccelerator for example, which worked perfect with Gallery2 and WordPress but did not work well with my Mp3 JukeBox. Memcached really works well on machines with lots of memory, which a SparcStation20 just doesnt have. So again, it’s all a matter of what you want to do and what you feel most confident with. This post in no way tries to tell you what’s the best method to run applications on old(er) hardware but merely functions as a sharing of personal experience.