home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / alt / irc / 2585 < prev    next >
Encoding:
Text File  |  1992-07-29  |  4.0 KB  |  74 lines
  1. Newsgroups: alt.irc
  2. Path: sparky!uunet!decwrl!lambda.msfc.nasa.gov!sol.ctr.columbia.edu!mtu.edu!ngmitche
  3. From: ngmitche@mtu.edu (SuperNate I am!)
  4. Subject: Re: How many clients to a server?
  5. Organization: Michigan Technological University
  6. References: <1992Jul20.085423.25491@aston.ac.uk>
  7. Message-ID: <1992Jul30.023524.19119@ctr.columbia.edu>
  8. Distribution: planetary
  9. Sender: news@ctr.columbia.edu (The Daily Lose)
  10. Date: Thu, 30 Jul 1992 02:35:24 GMT
  11. X-Posted-From: melab9.me.mtu.edu
  12. X-Posted-Through: sol.ctr.columbia.edu
  13. Lines: 59
  14.  
  15. The general concensus of the discussion about servers seems to indicate that
  16. a server will use at least as much bandwidth as 10 clients, and since the
  17. server runs continually, will do so at all times.
  18.  
  19. I do not have a functioning server (although a fair number of people have
  20. suggested that I make one), so I have no confirmed information to amend
  21. this approximation, but would like to point out a few things.
  22.  
  23. An unloaded server might use the same bandwidth at most times of day as 10 
  24. regular clients, but since the load caused by a server increases as clients
  25. are added to it, the "break-even" point is probably closer to 12 when
  26. a simple comparison of individual loads is made.
  27.  
  28. That is:  the loads (bytes, packets, whatever) of 12 clients is compared to
  29. a comperable measurement of the load of a single server.  This provides a 
  30. simple comparison, but still neglects certain facts.  In general, persons from
  31. a local region will converse more with each other than with other users.
  32. Also, such things as notify and channel modes might also be similar.  So for
  33. those messages that are sent to several clients from a local region, it might
  34. be more efficient to have a local server so that they will cross a long stretch
  35. of the net only one time.  This will once again change the "break-even" point
  36. in the opposite direction, but probably not below 8.  (8 clients == 1 server)
  37.  
  38. The chief concern of any site running a server is the load on that site's link
  39. at PEAK hours.  Since the load on the site will almost NEVER be less than
  40. that of 8 clients unless there are VERY few people on all of IRC a simple
  41. suggestion is just don't run IRC at peak times of network use.  Sure it's not
  42. as nice as getting a server running and having savings from going to 20 clients
  43. to the equivalent of 10, but getting the number of clients down to less than
  44. 10 during peak hours will show net savings without the hassle, work, and off-
  45. peak constant load of a server.  No IRC between 1400-1700 for instance.
  46.  
  47. Peak IRC hours aren't usually at the same time as peak network hours (thank
  48. god)  so it might not REALLY be a killer problem.  That is, the server
  49. won't be bogged by keeping track of a zillion users at the same time that 
  50. everyone and their brother at a site is ftping, emailing, (even ircing), 
  51. telnetting, etc.
  52.  
  53. If I don't see at LEAST 8 clients during peak hours, I don't need to make a 
  54. server and since MTU has a policy disallowing IRC at any time that might be
  55. construed as "high-network-usage", I sure hope that I don't EVER see that 
  56. many IRCers from tech at those times.  I would like to continue to use IRC
  57. and not have it squelched because a few individuals cannot respect the limits
  58. of the resources available to students here.  I can think of one person who
  59. ran IRC when his department's mainframe was down to 4M and swapping to a floppy-
  60. drive or some rediculous situation like that--and YES, it was during a time 
  61. that MTU policy would ordinarily disallow IRC.  What bugs me most is that _I_
  62. set up the client on that mainframe and before I did so, I specifically asked
  63. that user to talk with the director of that department's computing facility so
  64. that he would be fully aware and cognizant of the policy.  (yeah, right!)
  65.    
  66. All that I have mentioned is just stuff to consider.  I'm not a computer whiz 
  67. or a networking whiz.  I've only used real computers a little less than a year,
  68. but at least my default server list for the client I maintain uses servers
  69. that are topologically close, reliable, capable and have consistently small
  70. ping times..
  71.  
  72. --
  73. What?  no .sig?
  74.