The question comes down to whether it matters. There is no other
functionality attached to the file size and all it represents is the
number of file requests and the network traffic.
On the other hand, solving the problem of generating files on the fly or
dealing with a set of files to cover the range of the distribution will
either add a lot of logic or a large chunk of data to the driver, making
it rather large. If we choose on the fly generation, the driver will
become quite a bit heavier. Also, we may want to generate random jpeg
images (in case we test the app directly, we at least come up with
something the browser can display).
This comes down to whether it is worth the additional complexity. If
there is an obvious gain, we should consider it. But if it won't change
the overall number of image hits or the network traffic, and has no
other benefits, I wouldn't want to add to the complexity. But this is
just my personal opinion. Others?
-Akara
Samuel Guo wrote:
Hi all,
After using olio and reading the source code, I found that Olio uses the
files from $WORKLOAD/resources whose file-size are fixed as the pictures
used by every simulated user. Can this simulate the real-world workload? Why
we can make the file size of the pictures used by the users changed during
simulation? I don't think it is a hard problem to simulate it if we know the
file size distribution of the real-world workload(may be power-law
distribution).
Hope for your reply.:)
Thanks,
Samuel
