Oh, pish posh, (i_recognize_you_name_omitted) ... we all know better.   Everyone reads the documentation first.   Then, they go out and write something with it.   If everyone just did that and said nothing, why, there would be no reason at all for PerlMonks to exist or for any of us to while away our time here, both reading and contributing as best we can.   But we do ... we all do ... and that is precisely why “petitioning the Monks” is, and remains, the most fruitful way to address a particular issue.

Documentation is tough to write, because it is usually written by the author herself.   She knows it too well.   She’s too close to it.   Quite often it is the secondary documentation, written by end-users who have read and absorbed the original perldocs, which is the most valuable in practice.   (And in the ideal world, that feedback loops back around to an improvement in those docs.)

I frankly don’t think that it is right to answer a post with, “RTFM,™” let alone to do so as an Anoymous Monk.   It is far better, and considerably less discourteous, simply to not to answer at all.   Let’s never “shut out” conversation, even those with which we do not agree.   Just let it perish on the vine in silence, if it may.   My very-legitimate and urgent need to seek the wise counsel of my peers on this matter, remains.   I mean no harm, and I mean to waste no one’s time.

Oh, pish posh, .... I frankly don’t think that it is right to answer a post with, “RTFM,™” let alone to do so as an Anoymous Monk. It is far better, and considerably less discourteous, simply to not to answer at all.

But there is a difference, I didn't answer with RTFM. RTFM is simply part of my technique, should I have lied?

Let’s never “shut out” conversation, even those with which we do not agree.

Having a discussion means other people get to have a say, even if you do not agree, and the beauty of text communication -- no volume.

Just let it perish on the vine in silence, if it may. My very-legitimate and urgent need to seek the wise counsel of my peers on this matter, remains. I mean no harm, and I mean to waste no one’s time.

Maybe you should emphasize this part.

Performance is hard to predict, which is why I benchmark. Static/dynamic.... it doesn't really matter, it all depends on your app. See http://serverfault.com/questions/26337/whats-the-difference-between-fastcgi-static-and-dynamic-applications-in-term

Oh, fret not about that ... I am reading, not just writing.   The first stumbling steps are, of course, those bits of reading.   What I would like to find, in the most concentrated form, are war-stories (references to...) from actual deployments.   I always appreciate finding threads that are fruitful and that take me directly to where I might not initially know to go.   And, I like to try to start such threads now and then, if I can.   (Naturally for those who have finished with reading stuff like this.)

If someone now comes forward with, say, “Well, I started out with dynamic and it worked fine for a while but then, when we went above 5,000 requests per second we switched to a static server (or something else) for these reasons ...”   Well, that would be a pot of gold because it would apply both to the short and the long term.   I can “Google It™,” of course, and spend the rest of my days reading 2.6 million documents ... or, I can petition the Monks, and benefit from years of experience in one pleasant afternoon.

I wish no one to do my work for me, and humbly mean not to waste anyone’s time.

I can “Google It™,” of course, and spend the rest of my days reading 2.6 million documents ... or, I can petition the Monks, and benefit from years of experience in one pleasant afternoon.

Or, you skip the fancy formatting and read the two 2 documents, and tell us all about it :)

Alway, for every thing, RTFM Synopsis :) followed by RTFM benchmark

When you feel the urge to give 'RTFM' as a response, do everyone a favor and opt for another cute acronym: STFU.

I did not give RTFM as a response.

sundialsvc4 asked how did you take your first baby steps? , and baby steps are always RTFM for me.

Then test and examples directory. Then I whip up benchmark for a part that interests me. If benchmark looks promising, then I scrutinize things more.

There are no "potted wisdoms" to be had outside of the current documentation, tests and benchmarks, that is just line-noise.