Date: Fri, 19 Sep 1997 22:39:27 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: Terry Lambert <tlambert@primenet.com> Cc: current@FreeBSD.ORG, (Nate Williams) <nate@mt.sri.com> Subject: Re: FYI: regarding our rfork(2) Message-ID: <XFMail.970919223927.Shimon@i-Connect.Net> In-Reply-To: <199709192210.PAA08418@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In response/addition to Terry's excellent analysis, not knowing much about implementation details, etc., let me briefly describe what I belive to be typical multithreaded application: We have an RDBMS server which participates in ocmpletion of telephone calls. The way it essentially works is this: The telephone equipment passes the server a piece of data. We compute something on the data, make a database access and send a reply. We need to do this about 30-200 times per second, and since most people hate to hear ``dead air'' when they dial a phone number, we also have to repond rapidly. The original design (which worked well on Slowlaris and Linux) was to have a listner thread waiting for requests. and a group of ``worker threads'' which sit and wait for work to be done. When a request arrives, it is handed to a worker thread and the master thread goes back to listening for more requests. the worker thread does what it does, replies to the requestor and then goes back into a queue, waiting for the next call to serve. We tried the approach of spawning new threads on demand but this is simply too slow. When we decided to go with FreeBSD on this project, the first task was to port the server. After about three weeks of hassle, we gave up. Even when the incompatabilities with Posix were accounted for, we had never been able to get more than aboout 400,000 calls processed before the thing will lock up. Our call rate, on a Pentium-90 went from 43/sec (Linux) to 14/Sec (FreeBSD-2.2). We then decided to toss the multithreading and re-build the server as multi-process. Same concept but having separate processes, using shared memory to comunicate. The result? Throughput went up to about 140/sec, and reliability is excellent; We have aborted a load test after two weeks of runtime. Why the story? Although multi-threading sounds good for certain things, when you compare it to the traditional Unix model, it really has very little benefit. Even in performance. What we gain instead is the need/requirement to ``play O/S'' in the user program (or library); If you remember, I started this thread with a very, very simple program; In an endless loop, fork. If you are the child, exit, if you are the parent, loop again. There is NOTHING syntatically or semantically wrong with this program. It domes something very basic to Unix but still crashes immediately. When I asked for help, I was shown a list of reasons what was wrong with my program. Chief amoung them was that I did not take the care to allocate a separate stack for each process. I plowed my greying memory and virtually any C and Unix specification, looking for a facility to manage my program's stack. I then went back to some of the original papers on C, and lo and behold, one of the main attractions was the ELIMINATION of the need to track, manipulate and manage the stack. Ask 10 GOOD C programmers, and 9 will mumble something about the stack being where local variables and arguments reside. One of the 9 maybe even knows how to increase its size at compile or run time. Only one of the original 10 will know how to actually do something useful about the stack in a running program. And this one is probably a participant in this thread :-) (Not me, I just read these and go ``wow!''). My two cents worht of opinion; If we want to maintain Unix in the spirit and make FreeBSD useful to a large audience of programmers, keep the original semantics. If I want a messy, complex, tricky environment (multi threading included), I can use NiceTry and get about half my management very, very happy (``now we are as mediocre as anyone else''). But this is just a biased opinion. Where I would LOVE to have more than one thread is in the kernel. --- Sincerely Yours, (Sent on 19-Sep-97, 21:59:17 by XF-Mail) Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970919223927.Shimon>