Computer entropy

Written on 6 May 2015, 08:55am

Tagged with: , ,

I recently had an issue with a Tomcat server taking very long to restart. It was bizarre because when the system was starting, the Tomcat server was taking about 20-30 seconds to start, but a subsequent Tomcat restart was taking 20-30 minutes.
The logs indicated that the following step was taking a lot of time:
INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [135172] milliseconds.

This lead to the Tomcat page with advice on faster startup. The problem was – Tomcat was using /dev/random as source of randomness, and when the entropy pool was exhausted, this device was blocking.
This explained why the problem was not manifesting right after system restart: because of the associated ‘noise’, there was a lot of entropy. But after the system was stable, the entropy pool was depleted.

The solution to this is to tell Tomcat to use the non-blocking /dev/urandom device instead of /dev/random:

When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool.

A counterpart is /dev/urandom (“unlimited”) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from /dev/random.
wikipedia

So, to make Tomcat use /dev/urandom you have 2 options:
1. As indicated in the Tomcat slow startup troubleshooting guide: Configure JRE to use a non-blocking entropy source by setting the following system property: Djava.security.egd=file:/dev/./urandom

2. Change the $JAVA_HOME/jre/lib/security/java.security settings file:
securerandom.source=file:/dev/urandom
instead of
securerandom.source=file:/dev/random

More about entropy

(more…)

Some questions

Written on 9 April 2015, 07:48pm

Tagged with: ,

The 3 questions interviewers ask

Can you do the job?
Will you do the job?
Can you work with the others?

Apparently all the interview questions gravitate around these 3 questions.

The five WHYs

Two stories about how many times you must ask ‘why’ before you find the root cause of a problem:

Q: “Why did you submit a purchase requisition for $750?”
A: “Because we need to purchase 150 staplers!”
Q: “Why do you need to purchase 150 staplers?”
A: “Because our agents need to staple the pages of the driver’s license application together.”
Q: “Why do they need to staple those pages together?”
A: Because […]

In the late 1980s, the parks service in the United States were concerned about the deterioration of the stonework on the Lincoln Memorial. So they asked the maintenance staff why the stone was decaying.

The crew needed to spray to get rid of the large volume of bird droppings. So they erected bird nets. These scarcely worked, and were unpopular with tourists, so the parks service called in the maintenance workers again and asked, ‘Why are there so many birds?’

‘The birds come to feed on the spiders,’ they said. ‘And the spiders are there to eat the midges.’ After dark, midges covered the memorial. The spiders came to eat the midges, and the birds came to eat the spiders. So the executives tried insecticides. But this also proved ineffective: the bugs came back. So the committee finally asked one more question. Why are there so many midges in the first place?
[…]
It is a wonderful story, and has entered folklore in a philosophy called ‘the five whys’. The idea is that you should always go on asking ‘why’ in order to get to the root cause of a problem rather than the proximate cause. If you do this, what at first appears to be a masonry problem may turn out to be a problem about lighting design and insect behaviour.
Why plane crashes are getting weirder

IMG_9181

A/B, MVT testing and usability

Written on 30 March 2015, 10:31pm

Tagged with: , ,

Some quick notes after reading A field guide to usability testing and re-reading the Smashing Book #1:

1. A/B testing

– always test both versions simultaneously
– wait for it :) (use a calculator to determine when to end it, and don’t give up earlier)
– keep the A/B tests for new visitors only (don’t surprise the regulars)
– but make sure that a new visitor gets the same version on consecutive visits
– be consistent: make sure that the variation appears on all pages (ex – if you have a promotional price on version A, make sure that the user will always see the promotional price on all the pages)
– the results might be un-intuitive
– naturally, the higher the number of users, the more reliable the result
More

Who would be involved in an A/B test:
the UI/UX team – to propose the 2 versions and analyze the metric results
the dev team – to implement the metric, manage sessions and make changes consistent across all the interfaces
the network team – to handle various types of redirects (ex – run the A/B test only for users in a given geographical area, or only users on mobile)

2. MVT (multi variate testing)

– it needs a lot of traffic and time
– keep the number of combinations to 25 or less and make sure you preview them all
– global vs local optimum (A/B vs MVT)
– if you don’t have the traffic and cannot use full factorial testing, you can still use partial factorial testing.

3. Some usability rules/principles

(more…)