tag:blogger.com,1999:blog-130440502011-11-12T22:28:46.595-08:00Pranshuhttp://www.blogger.com/profile/04824192526729122018noreply@blogger.comBlogger11100tag:blogger.com,1999:blog-13044050.post-1116576231599485202005-05-20T01:02:00.000-07:002005-05-20T01:04:40.186-07:00I will try to complement Apoorv's blog<br /><a href="http://apoorvdurga.blogspot.com/">Apoorv Durga's Blog on Portals and Content Management</a> whichever ways in which I can.<br /><br /><br />In one of the recent blogs, Apoorv mentioned sizing. That is one thing which I happen to have worked a lot on.<br /><br />I will list a few things which I noticed about the content management systems that I worked on :<br /><br />- It is the database access that kills.<br /><br />- SQL Queries on the presentation layer tend to be a lot heavier than the queries on the Content management backend<br /><br />- Unless and until you have a very simple presentation - it will always make sense to cache the presentation as HTML pages and serve that to customers instead of dynamic pages (of course everyone knows that)<br /><br />- Even if the update frequency or volume is large (lets say more than a page a minute on an average) and the database size gets large - even the publishing process takes its toll. It is good to have an aggressive archiving for the content. In case Archiving is not feasible (after all it is a content management system) - a replicated database for presentation may be the only option.<br /><br />- Coming to sizing you are likely to get a better projections by benchmarking against existing applications<br /><br />- For benchmarking against existing application - you need to have page views per second for the most frequently used dynamic pages and the database size.<br /><br />- If you have a benchmark - you can half the performance for every 10 times increase in data size<br /><br />- Typically, if you can serve 7 pages per second by 1 CPU of application server and 2 CPU of database server for a non cached application - it is considered good performance. Typically the CMS pages which are updating "one content item" only can achieve this kind of performance for a database having 10 to 50 thousand content items.<br /><br />- XML processing is usually a big killer, so if you are transferring around large structured documents using web services, and a document size is expected to be more than 20 KB then you have to really look at the performance. As per a benchmark I am doing now - 1 CPU can consume a web service returning 1 Meg data only 3 times a second. This is with it doing no processing at all - just a web service call using regular soap client. So as a thumb rule - if you are making web service calls - it will be a good start to halve the above benchmark of 7 pages per CPU on the app server to form a target to aim for.<br />- Some CMS have object or XML databases. I am not sure how you can size for them if the content size is beyond a certain size.<br />- Search engines fall in a different league. I am not sure how to size for them.<br /><br />I have a question if anyone can help me answer : Can I use google desktop on my CMS server and let people search that ?<br /><div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/13044050-111657623159948520?l=pranshujain.blogspot.com' alt='' /></div>Pranshuhttp://www.blogger.com/profile/04824192526729122018noreply@blogger.com20