[Please, CC replies to me directly as I am not subscribed to the
list. Thank you.]
Joe Landman wrote:
As mentioned above, four test-files were used for the benchmark:
1. Small static file - 429 bytes
2. Larger static file - 93347 bytes
3. Small PHP file (a single php call in it – to phpinfo() function).
Although the file is small, its output was over 64Kb.
4. Large PHP file (apc.php). Although the file is larger, its output
was only about 12Kb.
One of the questions I routinely ask our customers is what
their definitions of "small" and "large" are, as their
definitions might not match what I use for these
terms.
This is directly relevant in your case. What you call
"larger" is considered small for GlusterFS. You want
MB sized IOs to amortize the cost of the fuse system
calls.
But these files are representative of what our
web-servers will be serving -- primarily. Though there may be an
occasional video, mostly it is static HTML and "web-size" images,
plus PHP-scripts...
Are you saying, GlusterFS is not really for us? We expected to pay
some performance penalty for the features, but the actual
numbers are causing a sticker-shock...
(Writing to GlusterFS is even more horrid -- extracting
thunderbird-24.0.tar.bz2, for example, on a GlusterFS share takes
almost 30 minutes, instead of seconds on local FS, but we have
very few writes, and so were willing to ignore that.)
Did you look at the CSW
number? Is it also high?
Around 8K per second, if I'm reading the output of vmstat correctly.
-mi
|