{"id":205420,"date":"2010-01-20T08:18:00","date_gmt":"2010-01-20T13:18:00","guid":{"rendered":"http:\/\/www.cmswatch.com\/Trends\/1781-Performance-Requirements?source=RSS"},"modified":"2010-01-20T08:18:00","modified_gmt":"2010-01-20T13:18:00","slug":"performance-is-a-requirement-too","status":"publish","type":"post","link":"https:\/\/mereja.media\/index\/205420","title":{"rendered":"Performance is a requirement, too"},"content":{"rendered":"<p>Performance testing is a notoriously difficult undertaking. So much so, in fact, that it is sometimes not done at all, or only done when a performance problem arises in production, making some sort of investigation unavoidable.<\/p>\n<p>Testing the performance characteristics of a system in advance of its rollout is particularly difficult, because it&#8217;s hard to know how to simulate real-world usage situations. Developer and QA-lab setups rarely replicate real-world environments. In the real world, machines have fragmented hard disks, superfluous extra files on the file system, anti-virus and other software running, etc., while end-users do crazy things like start and stop applications, run hard-disk searches, flush the browser cache, leave Gmail, Skype, and other &quot;chatty&quot; applications running in the background, and so on.&nbsp; This can all affect the performance of <a href=\"http:\/\/www.cmswatch.com\/CMS\/Report\/\">WCM<\/a> or <a href=\"http:\/\/www.cmswatch.com\/DAM\/Report\/\">DAM<\/a> applications in particular. The real world of end-users (and of real servers running in real data centers) is not easily duplicated in a sandbox environment.<\/p>\n<p>Some CMS vendors (for example, <a href=\"http:\/\/www.cmswatch.com\/CMS\/Vendors\/PaperThin\">PaperThin<\/a> and <a href=\"http:\/\/www.cmswatch.com\/CMS\/Vendors\/Sitecore\">Sitecore<\/a>) provide built-in reporting capability for determining time-to-render for various content elements. But in general, onboard profiling capability is woefully lacking from most WCM and DAM systems. <\/p>\n<p>A few vendors are beginning to delve more deeply into this area. One that does is <a href=\"http:\/\/www.cmswatch.com\/CMS\/Vendors\/Day%20Software\">Day Software<\/a>: The next release of its Communiqu&eacute; offering (version 5.3, slated for March) has what I might call (tongue in cheek)  pervasive thermometry. Almost any operation that takes (or <em>can <\/em>take) a noticeable length of time has a thermometer bar or other progress indicator associated with it, and in many cases a comparative bar-graph is available at the click of a button. The bar graphs are drawn using the Google Charts API, which means that a graph can be stored, sent, and managed as a bookmark &#8212; the charts are essentially <a href=\"http:\/\/www.cmswatch.com\/Trends\/1379-Is-CMIS-RESTful-Or-merely-HYPEful\">REST<\/a> URLs.<\/p>\n<p>As with any vendor &#8212; and especially Day &#8212; you need to be careful that the engineering vision of a reporting subsystem is matched by its usability.&nbsp; So Day customers will want to test closely when it comes out.&nbsp; <\/p>\n<p>Until more CMS&nbsp;or DAM systems start offering good tools for profiling or performance monitoring, we recommend that you be sure to address those requirements up front.&nbsp; Make it part of your requirements process, before undertaking a system implementation, or for that matter, before choosing a vendor. Determine ahead of time what your performance goals are &#8212; then put them in writing, in your <a href=\"http:\/\/www.cmswatch.com\/SiteSearch\/?query=rfp&amp;x=0&amp;y=0\">RFP<\/a>s and <a href=\"http:\/\/www.cmswatch.com\/SiteSearch\/?query=rfi&amp;x=0&amp;y=0\">RFI<\/a>s. Structure them into purchase agreements as well. &quot;Pay for performance&quot; isn&#8217;t a bad policy. But if you don&#8217;t spell it out, it&#8217;s like anything else; it won&#8217;t get implemented.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Performance testing is a notoriously difficult undertaking. So much so, in fact, that it is sometimes not done at all, or only done when a performance problem arises in production, making some sort of investigation unavoidable. Testing the performance characteristics of a system in advance of its rollout is particularly difficult, because it&#8217;s hard to [&hellip;]<\/p>\n","protected":false},"author":2781,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"class_list":["post-205420","post","type-post","status-publish","format-standard","hentry","category-news"],"_links":{"self":[{"href":"https:\/\/mereja.media\/index\/wp-json\/wp\/v2\/posts\/205420","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mereja.media\/index\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mereja.media\/index\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mereja.media\/index\/wp-json\/wp\/v2\/users\/2781"}],"replies":[{"embeddable":true,"href":"https:\/\/mereja.media\/index\/wp-json\/wp\/v2\/comments?post=205420"}],"version-history":[{"count":0,"href":"https:\/\/mereja.media\/index\/wp-json\/wp\/v2\/posts\/205420\/revisions"}],"wp:attachment":[{"href":"https:\/\/mereja.media\/index\/wp-json\/wp\/v2\/media?parent=205420"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mereja.media\/index\/wp-json\/wp\/v2\/categories?post=205420"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mereja.media\/index\/wp-json\/wp\/v2\/tags?post=205420"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}