Content Server Sizing Information Required

[Former Member]

Hi All,

Need a concept for Content Server Sizing for DMS.

The requirement is, Client has legacy doc/xls/dwg(autocad files)/pdf files which needs to be loaded on content server as bmp/jpeg/tiff files for which the size of Content server is not being able to finalize.

Also, sizing needs to be planned for next 5 years for ongoing files for all the above files.

Could anybody send me the sheet along with the calculation process required for CS sizing.

Points awaited.

Thank You,

Manoj

[Former Member]

hi.

there is no standard formula for actual sizing,

u can ref below one to arrive ur actual sizing

Say after calculating the total size of all application with compression ration u get say 796 GB = (A)

Add 25% for DB tables = 796+25%A= 996=(B)

Add 20% for DB log space = 996+20%B=1195=(c)

Document increase per yr 20%

First yr =195+20%C = D( 1434)

second yr = D+20%D = E(1720)

third yr = E + 20%E = F(2064)

--

--

Say for Three yr Plan u should have 2064 GB size( 2 TB)

If u want for more yr just cumulate the Value

Award points if useful

Regards

Sham

[Former Member]

Hi

When sizing the Content Server, you need to focus on estimating the required disk and main memory space together with the required CPU power. Depending on the number of sample documents in the calculations below the estimations may vary from u201Cvery roughu201D to u201Cpretty closeu201D. The following figures are the foundation for your sizing estimations, so please take your time and try to be as precise as possible.

You have to collect infomation about the document volume, document types, and number of parallel web requests, in accordance with the steps below. The more accurate you try to make these figures, the more precise your estimations will be resulting in a optimal usage of your hardware ressources. Especially when calculating the compression ratio it is important to use a representative number of documents (which could be thousands or even tens of thousands for each type) and not just to compress a single file.

1. Find out all document types (Microsoft Word, Excel, Powerpoint, CAD, Pictures, etc.) that you intend to store on the Content Server

2. Try to find out (at least roughly) how many legacy objects of each document type you have to migrate from a legacy system into the Content Server. Omit this step if you donu2019t have legacy documents.

3. Find out the average compression ratio (at least roughly) for each document type. The Content Server encodes objects using a Lempel Ziff Hufman compression algorithm. This is the most widely-used algorithm today. You can get quite a good impression of the compression ratio if you compress a representative number of documents with an alternative tool (such as WinZip or GnuZip), as all LZH-based compressors behave very similarly.

4. Now define a certain time frame (a week, month, quarter, or year) for which you can reliably predict the document growth in bytes of each document type.

Steps 1 to 4 determine storage space on the disk. The following steps includes answers for disk, CPU and memory.

5. Try to find out (even vaguely is better than nothing) how many parallel document requests (read and write) you can expect on the Content Server. Be aware that your u201Cnumber of seatsu201D in the SAP System is not a sufficient value, because not all SAP users usually access the Content Server simultaneously.

6. The number of parallel users helps determine system requirements for memory, CPU, and additional log space for the disk.

Practical Advice

1. Create a table with columns for each document type that you identified in step 1 above.

2. Add a row where you insert the average compression factor for each document type now (a ratio of 1:4 is a factor of 75%).

3. Add the document volume of your legacy data into the next row.

4. Now calculate the compressed document volume size for each document type and add them up in the next row.

5. Repeat steps 3 and 4 for your future documents.

6. Add up the total compressed values for legacy and future data. This yields the net amount of diskspace required for the database instanc

7. Add an additional 20 u2013 25% safety headroom to this result. This headroom is required for database overhead and for risk compensation. This results in the required devspacefor your Content Server.

Number of Parallel Web Requests

All database systems store their running transactions in a special buffer called the database log or logspace. The logspace must be large enough to store all open transactions at any one time. As a general rule of thumb, the log should be about 10% of the devspace size. Since all document requests are wrapped within a transaction, make sure that the logspace is at least twice as large as the largest document in your database. Finding the appropriate logspace size is a matter of experience of the overall runtime behaviour of your Content Server. If you find out that your data throughput is too low, and that this is because of latencies due to a too-small logspace, you can add more logspace at any time without shutting down the database.

CPU Power

Because documents are changed on the useru2019s PC, CPU power has not been a bottleneck so far. The table below lists recommendations for CPU with respect to the number of parallel users. Parallel users are concurrent users who access the database at the same time. Therefore, parallel user numbers are much lower than concurrent users.

Number of parallel users Number of SAPS2

0-50 250

51-100 500

101- 200 1,000

Memory Requirements

Currently, the Content Server runs on Microsoft Windows NT 4.0 Server and 2000 Server only. For sizing memory requirements, take the number of parallel users and apply the following formula:

Number of parallel requests * average document size * 2.5 = memory requirements

Regards,

Sunny

[Former Member]

Hi Sunny,

Thanks for you fast response.

I have some of the doubts related to some things which u have mentioned,

3. Find out the average compression ratio (at least roughly) for each document type. The Content Server encodes objects using a Lempel Ziff Hufman compression algorithm. This is the most widely-used algorithm today. You can get quite a good impression of the compression ratio if you compress a representative number of documents with an alternative tool (such as WinZip or GnuZip), as all LZH-based compressors behave very similarly.

-->pls tell me whether content server will be compressing all the files stored in it by itself thru winzip/gnuzip or we have to zip and then store in content server.

2. Add a row where you insert the average compression factor for each document type now (a ratio of 1:4 is a factor of 75%).

-->wat is this ratio "1:4 is a factor of 75%" related to..?

pls give me example in terms of numbers.

-->wat is "Number of Parallel Web Requests", "Number of parallel users Number of SAPS2"?

-->Number of parallel requests * average document size * 2.5 = memory requirements

here average document size relates to particular doc type or all doc types?

Thank You,

Manoj

[Former Member]

Hi,

-->pls tell me whether content server will be compressing all the files stored in it by itself thru winzip/gnuzip or we have to zip and then store in content server.

*********************************************************

The files are stored in maxDB database as blobs in compressed formats. You do not have to zip it and store it.

To get the approx. compression ratio take some sample files of different formats and zip and see it to what extent they are compressed.

Based on different file types you can define compression factor from 33% to 50% as an average or may be less for few types of files.

It is not hardfast defined how much compression should be considered for CS sizing but winzip helps to get an idea to define that ratio.

regarding RAM, CPU the basis administrator will be able to define but 4GB is the min RAM required for CS installation.

Regarding processor go for dual processor CPU as min.

BR,

Anirudh,

reward if useful

[Former Member]

Hi Anirudh,

The files are stored in maxDB database as blobs in compressed formats. You do not have to zip it and store it

i want to know,

whenever we checkin any files(softcopies) (doc,xls,pdf etc..) into content server, these files get compressed automatically to certain compression ratio and get stored in CS but whenever we checkout/edit/display file from CS thru DMS is it that these files which are in compressed form are seen on screen??

Thank You,

Manoj

[Former Member]

Hi,

Only storage is in database compressed format. The retrieval is all taken care by K-Pro and what you see in GUI.

Anirudh,