Re: Committing Resources to Win32
От | Marsh Ray |
---|---|
Тема | Re: Committing Resources to Win32 |
Дата | |
Msg-id | 3FB1A6F1.6000104@mysteray.com обсуждение исходный текст |
Ответ на | Re: Committing Resources to Win32 ("Joshua D. Drake" <jd@commandprompt.com>) |
Ответы |
CreateProcess vs Create Thread
("Joshua D. Drake" <jd@commandprompt.com>)
|
Список | pgsql-hackers-win32 |
Joshua D. Drake wrote: > Marsh wrote: > >> I would think that you could probably get 80% of the performance with >> ordinary threads and ordinary blocking IO, and without the great >> increase in complexity required to implement asynchronous IO. If >> someone then wants to go after a possible 25% performance gain, they >> could submit a working set of modifications, or wait a few months for >> the hardware to catch up. >> > This argument doesn't work for several reasons: > > 1. Hardware generally does not catch up because: > A. Users demand increases and thus the load on the hardware > increases. > B. Users don't purchase new hardware every couple of months. > 2. If we were talking about a 5% performance gain that "might" be > acceptable but > the 20% gain you are talking about is huge. Think about it: > > I have several customers right now that push over 250,000 (some as > high as 750,000) > transactions an hour. They are pushing the hardware hard as it is, > especially with the > limitations of Vacuum. If they were to move to the Win32 version (it > doesn't matter why), > they would loose 50,000 transactions an hour based on your argument. > > That is completely illegitamate and would make PostgreSQL look like > a toy on Windows. > We already have PostgreSQL as a toy on Windows, it uses Cygwin. OK, but are you using asych IO on any platform now? Note that the original poster proposed it as a possible performance enhancement, and I'm not claiming that a threaded blocking-IO implementation on Windows is going to be slower than the current model on Unix. The hypothetical 25% gain really is a WAG that would probably only be achievable for some current worst-case scenarios, but the point is it represents a few months of hardware advance. If somebody's servers are really that saturated, they will be looking at hardware upgrades sooner rather than later, and a similar effect might achieved by throwing RAM at the problem. Ideally you would have a single process with exactly as many threads as there are CPUs (maybe x2 for Intel HyperThreading chips). Each thread would have affinity to a specific processor. All IO would be done asynchronously and use coroutines/fibers for task switching. Due to the complexity involved in implementing an app this way, it's usually not done. Process- or thread-per-connection with blocking IO is conceptionally much simpler and usually not that much slower. Efficient CPU scheduling is one of the main functions of the mainstream OS, right? - Marsh
В списке pgsql-hackers-win32 по дате отправления: