1. Design for available parts and sizes
2. Buy everything you can stock (pins, springs, aluminum channel, etc…)
3. Minimize milling by doing the above

To that end, I did a bit of springy research, and found that neither McMaster Carr or Manhattan Supply Co. had really small springs in bulk (only precision (eg expensive) springs in those sizes).

So I re-placed one of the pins to fit a standard (cheap) McMaster spring, and got pricing from http://centuryspring.aitrk.com/products/extension.html for a special spring.  The trigger spring has ~ a 2/1 leverage (finger/spring), so we need to have several lbs of spring pull to equal a decent trigger pull.  They have a spring with these dimensions:

While $1.20 is more than I wanted to pay, it sure beats $2.00 to $3.00 per spring that I was looking at from McMaster.

With a shorter spring, I was able to re-design the pin placement, which resulted in this:

Anyway, I wished to share one of the models I’m working on. This is a mechanism for a Rubber Band Gun receiver.

x86_64
Python 3.1.1
mod_wsgi 3.0c5
apache 2.2
RHEL 5.3
quad core xenon
8 GB ram

Development system – not in production use.

==================================================================
Application:

1 import time
2
3 def application(environ, start_response):
4     status = ’200 OK’
5
6     output = “hello world!”
7
8     #time.sleep(1)
9
10     response_headers = [
11         ('Content-type', 'text/plain'),
12         ('Content-Length', str(len(output))),
13         ]
14
15     start_response(status, response_headers)
16
17     return [output]

==================================================================
Apache Configuration:

WSGISocketPrefix run/wsgi
<VirtualHost *>
ServerName shankproject.jason.star.ionzoft.net
DocumentRoot /home/jason/Code/ShankProject/Web
WSGIScriptAlias /Admin /home/jason/Code/ShankProject/WSGI/
Admin.wsgi
WSGIDaemonProcess shankproject.jason.star.ionzoft.net threads=15
WSGIProcessGroup shankproject.jason.star.ionzoft.net
</VirtualHost>

==================================================================
Tests:

—————————————————–
# Baseline with one process and 15 threads
# 15 threads total

threads=15
no process definition

WITHOUT time.sleep(1)
concurrency = 1  >> 1800 / second
concurrency = 100 >> 3900 / second

WITH time.sleep(1)
concurrency = 1  >> 1 / second
concurrency = 100  >> 14 / second

—————————————————–
# Get a marginal improvement by doubling the threads to 30
# 30 threads total

threads=30
no process definition

WITHOUT time.sleep(1)
concurrency = 1  >> 1680 / second
concurrency = 100 >> 3500 / second

WITH time.sleep(1)
concurrency = 1  >> 1 / second
concurrency = 100  >> 30 / second

—————————————————–
# Take processes from 1 to 3
# 90 threads total

threads=30
processes=3

WITHOUT time.sleep(1)
concurrency = 1  >> 1770 / second
concurrency = 100 >> 3500 / second

WITH time.sleep(1)
concurrency = 1  >> 1 / second
concurrency = 100  >> 88 / second

—————————————————–
# Take processes from 3 to 6
# Take threads from 30 to 15
# 90 threads total

threads=30
processes=3

WITHOUT time.sleep(1)
concurrency = 1  >> 1550 / second
concurrency = 100 >> 3300 / second

WITH time.sleep(1)
concurrency = 1  >> 1 / second
concurrency = 100  >> 88 / second

==================================================================
Conclusion:

mod_wsgi performance is outstanding.  Even running slower requests, it
can still handle significant concurrency in daemon mode without any
apparent issues.

Questions:
Is there any information on the balance between more processes less
threads and more threads less processes?

Thanks!

After the excellent comment by Sergio Olivo, I did some heavy looking into the Extra Packages for Enterprise Linux project (EPEL for short).  On a brand-spanking-new RHEL 5 box, I installed the YUM repository for EPEL, and quite immediately had access to tons of extra packages.  Erlang is there.  Git is there.  Memcached is there.  Sweet!

However, EPEL does not update or replace the version of any packages provided by RHEL.

So the problem of having out of date versions of PHP and Python still remain.  Next I looked into using a third party RPM repository (provided by RackSpace).  They provide updated versions of PHP and a number of PHP modules.  But alas, this created incompatibilities with the EPEL packages for PHP.  This is because EPEL packages are targeted for RHEL versions. Bla…

So here is what I decided to do (haven’t done it yet, but will soon).  We will build and package our own custom set of RPMs for RHEL 5, and publish them in an RPM repository.  Then we will simply point each server to that repository in addition to the main RHEL repository, and poof, problem solved.  We may also use EPEL for things like Erlang and git.  Or we may compile from source.  Not sure.

For those of you who are not familiar with YUM RPM repositories, they can be as simple as a specail directory structure served by a webserver.

There are a few items remaining to be concluded, but they should fall into place fairly quickly.

At AppCove, we run RedHat Enterprise Linux on all of our servers.  RHEL is great, because:

1. It works
2. It still works
3. Automatic security updates
4. Did I mention, it just works?

RedHat, as far as I know, takes a very serious perspective on patching all of their RPM’s and automatically pushing them out via the update agent (up2date).  They are very conservative on the versions of packages that they publish.  RHEL 4, for example, is still running PHP 4.x.  Python 2.3.  MySQL 4.x…  I believe that they do this to maintain stability and long term support.

However, for a company like AppCove, those versions are simply too old. For years we have hand-compiled about a dozen packages on RHEL 4 in order to be able to take advantage of relevant features in newer software.  PHP, Python, MySQL (from mysql.com supplied RPM), python-mysql, git, erlang, memcached, libmcrypt, and others are part of the growing list of software that we have to install manually.

With this growing list comes a growing issue of security updates and maintainability.  More complicated packages need more updated libraries, creating a chain-reaction of additional packages.  Etc…

–
Recently I signed up with a “slice” at SliceHost.  (SliceHost provides virtualized machines for a great price, with lots of scalability available).  I chose Fedora Core 10 for the OS.  I must say I have been very impressed.

All of the packages that I have needed were right there, available by yum install.  PHP, Python, python-mysql, erlang, memcached, php-memcached, python-memcached, git, etc…, etc…, and did I mention that tree was even there?  And it has all “just worked”.

–
In summary, here are the items that I need to resolve:

1. Is fedora considered as “secure” as RHEL?  Is there a team dedicated to getting security patches our fast when identified?
2. Are continuous upgrades in fedora an issue?  Do software packages abruptly get updated without notice?  (this has at times been an issue with RHEL).
3. Is it possible to run RHEL while also connecting to fedora package repositories to install specific packages?  Desirable?  Undesirable?  Conflicts?

The most secure computer is one that is locked in a vault and turned off.  Since that won’t work for most needs, one must find the appropriate balance between functionality and security.

Comments welcome…