On Thu, 29 Nov 2007, isplist@xxxxxxxxxxxx wrote:
The point of the test was just to get a starting point since I didn't have
one. Even a rudimentary starting point is better than none.
I found the 'requests per second' interesting between the applications and not
wether they were being served up from a GFS partition or not. I have no doubt
that GFS plays a role in performance loss but it certainly would not be as
great a difference as I am seeing between applications. So it seems, for now
at least.
Is this a single-threaded or a multi-threaded test,
ab -k -n 100 -c 100 http://192.168.1.150/ (pointing to LVS server)
and how is the node access distribution handled?
You'll have to ask me this one in English since this is just a part time thing
for me, I'm not interested in becoming a guru at GFS/Cluster suites. I just
need to understand it enough to make it work for my needs. Can you rephrase
this please?
Are the same nodes asked to access individual subsets of the application
paths or are all nodes handling everything?
GFS will primarily add latency (because locks
need to be moved between the nodes). Once the node that needs to answer
obtains the locks, it should be able to deliver full speed on data
transfers. If you are accessing lots of small files, the latency will be
very dominant to the bandwidth. This could be what you are seeing.
I didn't shut the GFS or cluster services down, I only unmounted the shared
storage for the testing. Also, there was another GFS still mounted to that
same machine but it was in another path so not part of the path to test the
web server.
Indeed, that wouldn't affect it. But the point I was making was that if
your test waits for a response before asking again, you may find that the
throughput goes right down because latency goes up. If you are issuing
10 requests in parallel, that may cover up the latency increase.
I think I'm forgetting more version of this test? Remember that the machine
being tested does have a second GFS mount which is always mounted during this
testing.
Mounted filesystems that you aren't accessing won't be affecting the
performance. It's pretty safe to ignore those for now. It would be worth
looking into how Joomla handles it's file accesses. If it's constantly
opening and closing lots of files for r/w access, that may well explain
the 10x slowdown you're seeing.
Gordan
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
