Although there was an attempt to clarify the meanings of "Proof-Of-Concept" and "Prototype" I have to disagree.
Actually a Proof-Of-Concept ought to do exactly that: give a solid feedback upon the basic charactaritics of a specific concept. Therefore any statement wath a POC has to proof is dependent on the concept and can't stand for its own. With a concept for the algorothmic layout of a GUI for example you might not need to proof the performance. On the other hand if the concept you're trying to proof is a concept concerning data-transfer with optimization for time & space your POC would have to address exactly these aspects.

I am a bit suprised that the word Test was not mentioned in an article about Performance. Perhaps Test is included in the POC resources that the article mentions the client is making available. I don't think that one needs to understand the particular definitions or distinctions between a Proof-Of-Concept and a Prototype that were given, but at whatever stage of the project you should have some customer performance requirements that have been expressed somehow (otherwise why bother considering performance) for which you can define and execute a test. At the POC/Prototype stage you shouldn't need any fancy tools, just a written definition of how the test should be setup and a wristwatch for timing how long it took. Even at the paper stage, you should be able to define a test and execute it, for example, when the user hits the submit button how long do you think or estimate that action would spend in each sub-system of the design before the response is seen? Given that time is not free, you can't test everything and test for everything regarding performance, but there should be a vital few performance requirements for which you can. Also early on you may not be able to simulate thousands of users on your system, but you should be able to define a test and how it would work, and from that be able to analyze the pieces of your system would handle those users without crashing for example. What I like about this approach of defining and testing for performance from the beginning is that it helps the development team know what's important, and it allows you to explore the performance requirements further with the customer early on. Maybe a performance requirement is reasonable, maybe not, maybe it would be if you had another million dolars of hardware for the final production system, or maybe the customer would rather have you spend your time focusing on a different performance requirement that is more easily quantified. Another benefit is that provided you have executed and recorded the test results at each stage, it can show progress to the team and the customer as the performance (hopefully) increases from stage to stage or release to release. So my suggestion is to consider testing for the vital few performance requirements from the beginning of the design as that will help you produce a better system sooner. Thanks for the article.