Mailing List Archive: Re: sorry, there it is (2nd try)

Hi Tyrel,

I had a very short glance at it and I have some comments:
o Please, please, for heaven's sake: DO an incremental diff on top of the
cleaned (make mrproper) vanilla kernel patched with the ipvs-patch you
modified. It's close to impossible to see what you've changed and I'm
sure not everybody will run fine with your .config file.
o Check out line 46 of index.cgi: It's a small typo but showing up very
often so you see it too much
o You shouldn't hardcode the servers [sac* in your example]. This should
be read from the /proc or from a config file.
o May I suggest you change the ``print << EndOfHTML'' construct:
You can use either arrays, enumerate it, or a for-loop. It will be more
readable instead of 150 nearly duplicate lines. That's what scripting
languages are for. This applies to index.cgi and cluster.cgi. By doing
this you can reduce your code by a factor 4 and even make it more readable.
Example: perl -e '@a= qw(jan feb mar apr may jun jul aug sep oct nov dez);
for ($a=0; $a<12; $a++) { printf "%02d %20s\n", $a, $a[$a]; }'
o Why did you write your own picture generator? There is mrtg or even
rrdtool (both very known and written by a good friend of mine)
http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/
http://ee-staff.ethz.ch/~oetiker/webtools/rrdtool/

Looking forward to your comments and consider the fact that I didn't look
very long at the code. Thank you for this contribution, the idea is nice.

Best regards,
Roberto Nibali, ratz

--
mailto: `echo NrOatSz@tPacA.cMh | sed 's/[NOSPAM]//g'`

--
mailto: `echo NrOatSz@tPacA.cMh | sed 's/[NOSPAM]//g'`

Hey,

Thanks for taking the time to look into a few of those things. I'll work on
the items you have suggested when I get some time today. I kinda wrote my own
pic generator because I wanted to know what was going on and how images were
scaled, what filters do, and what the heck convolution means... yeah, I'm
planning on putting most of that stuff into the code but your friends stuff
looks interesting... I even think I heard a consultant I work with talking
highly of it :-)...

Also, I was wondering what you though of using the RRT or the the window size to
derive which machines are running the fastest in the cluster... I know RRT would
be hard to use at the LVS because we don't know that the ACK for the oustanding
data will get back to the client after passing through the LVS so it is already
sounding kinda kluge like. I was thinking that maybe some kinda window size
idea might work, the machines with the smallest amount of oustanding data could
be view as serving requests the fastest...? just a few hair brained ideas... I
guess I'm going to need to give TCP/IP vol 1 a good re-read to freshen up on
stuff..

Also what does it mean to be the fastest server in the cluster, is it the
machine which is able to process the most requests between only it and the LVS?
How does one define system load? Is it the amount of bandwidth saturated
between it and the lvs?

Thanks, Tyrel