Rubber Band Gun #6 – springs, etc…

I visited Dixon Tool and Die, Inc. today to see about having some machining done.  Bill Dixon Jr. was very helpful, and explained many of the points that will make the process go easier.

  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:

Part #80127
Diameter: 3/16″
Rest: 0.63″
Max Travel: 0.39″
Load at max: 3.9lbs
ID of loops at ends: .132
$1.20 each at 100

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:

Rubber Band Gun #6 and Pro/Engineer Wildfire

I recently purchased a copy of Pro/Engineer Wildfire 5.0, and have been comparing it to SolidWorks. They are both nice programs, and within about a day, I have achieved about the same level of usefulness in ProE as SolidWorks. (Note: all that means is that I am a beginner at this).

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

Interesting Numeric Pattern

>>> for i in range(1,31):
...     print('  ' + '1'*30)
...     print('x ' + '1'*i)
...     print('= ' + str(int('1'*30) * int('1'*i)))
...     print()
...
  111111111111111111111111111111
x 1
= 111111111111111111111111111111

  111111111111111111111111111111
x 11
= 1222222222222222222222222222221

  111111111111111111111111111111
x 111
= 12333333333333333333333333333321

  111111111111111111111111111111
x 1111
= 123444444444444444444444444444321

  111111111111111111111111111111
x 11111
= 1234555555555555555555555555554321

  111111111111111111111111111111
x 111111
= 12345666666666666666666666666654321

  111111111111111111111111111111
x 1111111
= 123456777777777777777777777777654321

  111111111111111111111111111111
x 11111111
= 1234567888888888888888888888887654321

  111111111111111111111111111111
x 111111111
= 12345678999999999999999999999987654321

  111111111111111111111111111111
x 1111111111
= 123456790111111111111111111110987654321

  111111111111111111111111111111
x 11111111111
= 1234567901222222222222222222220987654321

  111111111111111111111111111111
x 111111111111
= 12345679012333333333333333333320987654321

  111111111111111111111111111111
x 1111111111111
= 123456790123444444444444444444320987654321

  111111111111111111111111111111
x 11111111111111
= 1234567901234555555555555555554320987654321

  111111111111111111111111111111
x 111111111111111
= 12345679012345666666666666666654320987654321

  111111111111111111111111111111
x 1111111111111111
= 123456790123456777777777777777654320987654321

  111111111111111111111111111111
x 11111111111111111
= 1234567901234567888888888888887654320987654321

  111111111111111111111111111111
x 111111111111111111
= 12345679012345678999999999999987654320987654321

  111111111111111111111111111111
x 1111111111111111111
= 123456790123456790111111111110987654320987654321

  111111111111111111111111111111
x 11111111111111111111
= 1234567901234567901222222222220987654320987654321

  111111111111111111111111111111
x 111111111111111111111
= 12345679012345679012333333333320987654320987654321

  111111111111111111111111111111
x 1111111111111111111111
= 123456790123456790123444444444320987654320987654321

  111111111111111111111111111111
x 11111111111111111111111
= 1234567901234567901234555555554320987654320987654321

  111111111111111111111111111111
x 111111111111111111111111
= 12345679012345679012345666666654320987654320987654321

  111111111111111111111111111111
x 1111111111111111111111111
= 123456790123456790123456777777654320987654320987654321

  111111111111111111111111111111
x 11111111111111111111111111
= 1234567901234567901234567888887654320987654320987654321

  111111111111111111111111111111
x 111111111111111111111111111
= 12345679012345679012345678999987654320987654320987654321

  111111111111111111111111111111
x 1111111111111111111111111111
= 123456790123456790123456790110987654320987654320987654321

  111111111111111111111111111111
x 11111111111111111111111111111
= 1234567901234567901234567901220987654320987654320987654321

  111111111111111111111111111111
x 111111111111111111111111111111
= 12345679012345679012345679012320987654320987654320987654321

Python 3.1 and mod_wsgi performance notes

We’re researching the use of Python and mod_wsgi running under apache for developing some extensive web applications.  Here are some notes on a performance test that we recently ran.
==================================================================
Server:

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!

Update [1] on Fedora vs Redhat Enterprise Linux

This is in reference to https://blog.gahooa.com/2009/01/18/fedora-or-redhat-enterprise-linux-in-a-production-environment/.

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.

Fedora or RedHat Enterprise Linux in a production environment?

[UPDATE AT https://blog.gahooa.com/2009/02/08/update-on-fedora-vs-redhat-enterprise-linux/]

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…