home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / programm / 5269 < prev    next >
Encoding:
Text File  |  1992-11-13  |  2.7 KB  |  62 lines
  1. Newsgroups: comp.unix.programmer
  2. Path: sparky!uunet!gatech!psuvax1!vogon1!jdm1
  3. From: jdm1@vogon1.pasen.gov (Jonathan D McCown)
  4. Subject: SysV Message Queues - Use in TP - (rambling comment/question)
  5. Message-ID: <1992Nov12.154253.4188@vogon1.pasen.gov>
  6. Summary: SysV Message Queues - Use in TP - (rambling comment/question)
  7. Keywords: Bogus SysV Message Queues Whatever
  8. Organization: Vogon Poets Society
  9. Distribution: na
  10. Date: Thu, 12 Nov 92 15:42:53 GMT
  11. Lines: 49
  12.  
  13.  
  14.  
  15. I've been fiddling with a client/server configuration based around
  16. System V message queues.  Somewhere in my reading I found that their
  17. development had come out of some Bell Labs (or whatever) Transaction
  18. Processing work, and I thought it would bear investigation.  This post
  19. is to solicit comments, suggestions or increased news traffic.
  20.  
  21. My prototype looks like this:
  22.  
  23. --------- <------- SRVQUE <------ Client-1...n (write requests to server)
  24. MSERV   |
  25. ________| -------> CLIQUE ------> Client-1...n (read requests from server)
  26.  
  27. Messages to the server are coded by message-type (part of message queue
  28. structure) as to their transaction type. In this way should multiple
  29. specialized servers be reading the same queue, no conflict arises as
  30. they "read their own thing", this can have interesting effects if one
  31. spawns additional servers to handle traffic increases.
  32.  
  33. Responses from the server are enqueued with a message-type == PID of
  34. the client, so clients may either block on read or poll for their
  35. responses.
  36.  
  37. Since the processing is all "in core" the prototype is wonderfully fast.
  38. Initially ~230 "transactions" per second, using a non-optimized single
  39. threaded server.  Naturally, adding IO heavy functions to the server slows
  40. things down. (I am linking in Informix ESQL funcs).
  41.  
  42. I realize that this may not be bleeding edge for some, but it is an
  43. interesting study (and actually approaches a solution for some system
  44. bottlenecks in our environment).  In my case, a lot of Informix system
  45. overhead can be overcome via one "informix q-server" servicing hundreds
  46. of _inquiry_ based applications. (informix has an "engine" proc for each
  47. client app in its standard implementation, many many many procs) 
  48.  
  49. Comments, suggestions welcome.  Multi-threading would be great here...
  50. My environment is a Sequent (4 CPUs) under PTX 1.3 so some of the Sequent
  51. concurrent processing stuff may become involved (yeah..!).
  52.  
  53. - J.D. McCown
  54.     "It ain't CICS.. yet."
  55.  
  56. Domain in transition, best mailpath may be "psuvax1!vogon1!jdm1"
  57.  
  58. -- 
  59.             J.D. McCown - Computer Services - Senate of Pennsylvania  
  60. psuvax1!vogon1!jdm1                    "You don't want to get locked into   
  61. jdm1@vogon1.pasen.gov                   'open systems'." -anonymous IBM Rep.    
  62.