In June I met a very friendly colleague of mine, Alex Polozoff, at a common customer engagement. His blog on WebSphere Performance inspired me to start this one.
I don't believe, that there will be too much overlap, since I'm planning to concentrate on the upper layers of the stack, that deals with process choreography and it's surroundings.
Thank you Alex!
Tuesday, July 15, 2008
Thursday, July 3, 2008
How much space will my BPEDB occupy?
Database space is more or less irrelevant.
Why?
Today's disks have at least 40 (or 80) or more GB of space. Production level disks (heavy duty) are even larger.
For production you need performance. And for good I/O performance you'll need to distribute your I/O across multiple dedicated physical disks (striped FS, RAID 0, or alike). This applies to SAN storage too.
The typical DB sizes (in terms of occupied space on disk) for BPC production databases are a small fraction of the space (in terms of (number of) disk drives) you need for performance. Actually you'll "waste" maybe 80% of your available disk space in order to get the production level performance you're after.
So - don't bother about how large the production DB will be - it will very well fit on the disk array you'll need for performance.
Absolute numbers? I've hardly seen anything larger than 200GB so far - which was huge already. Typically MQWF's and BPC's DB sizes are between 50 and 150GB. You'll have a large installation? Well, then assume 500GB - you can squeeze that on a single disk today, but I'm sure you won't do that (performance).
From what has been have seen in lab tests, 2 million process instances take up around 100GB if you don't have excessively large and many BOs as variables in a process.
Some figures reported from capacity POCs:
Why?
Today's disks have at least 40 (or 80) or more GB of space. Production level disks (heavy duty) are even larger.
For production you need performance. And for good I/O performance you'll need to distribute your I/O across multiple dedicated physical disks (striped FS, RAID 0, or alike). This applies to SAN storage too.
The typical DB sizes (in terms of occupied space on disk) for BPC production databases are a small fraction of the space (in terms of (number of) disk drives) you need for performance. Actually you'll "waste" maybe 80% of your available disk space in order to get the production level performance you're after.
So - don't bother about how large the production DB will be - it will very well fit on the disk array you'll need for performance.
Absolute numbers? I've hardly seen anything larger than 200GB so far - which was huge already. Typically MQWF's and BPC's DB sizes are between 50 and 150GB. You'll have a large installation? Well, then assume 500GB - you can squeeze that on a single disk today, but I'm sure you won't do that (performance).
From what has been have seen in lab tests, 2 million process instances take up around 100GB if you don't have excessively large and many BOs as variables in a process.
Some figures reported from capacity POCs:
- 1 M process instances, 0.5 M human tasks: 100GB
- approx. 50 M process instances, no human tasks: 1TB
Subscribe to:
Posts (Atom)