Thread: Re: Committing Resources to Win32
Hello there, > I have arranged to have 1 full time dedicated programmer to the Win32 port. That's fantastic. I've been trying to arrange the same thing at my company... > Specifically, I believe and through conversations with several Win32 programmers I know, that using create process is a bad idea and that we should move to a threaded model (at least for Win32). CreateProcess appears to be the method the core developers have decided upon. Unfortunately, and speaking from experience, unless either the decision to use MingW as a build environment is reviewed (as opposed to VC++, for instance), or MingW "soon" supports thread local storage declspecs, a threaded implementation would be just too difficult to integrate cleanly with the existing source base. > Is there a development plan for the Win32 version that I perhaps haven't seen or are we just kind of hacking it as we go along? I'll let someone with cred answer this officially. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
Claudio Natoli wrote: > >Hello there, > > > >> I have arranged to have 1 full time dedicated programmer to the Win32 >> >> >port. > >That's fantastic. I've been trying to arrange the same thing at my >company... > > > I agree, it's great. > > >> Specifically, I believe and through conversations with several Win32 >> >> >programmers I know, that using create process is a bad idea and that we >should move to a threaded model (at least for Win32). > >CreateProcess appears to be the method the core developers have decided >upon. Unfortunately, and speaking from experience, unless either the >decision to use MingW as a build environment is reviewed (as opposed to >VC++, for instance), or MingW "soon" supports thread local storage >declspecs, a threaded implementation would be just too difficult to >integrate cleanly with the existing source base. > > > The requirement is that we can build with opensource tools. I'm quite prepared to buy the (cheap version of) VC++, but only as a last resort. cheers andrew
Claudio Natoli wrote: >> Specifically, I believe and through conversations with several Win32 >> >> >programmers I know, that using create process is a bad idea and that we >should move to a threaded model (at least for Win32). > >CreateProcess appears to be the method the core developers have decided >upon. Unfortunately, and speaking from experience, unless either the >decision to use MingW as a build environment is reviewed (as opposed to >VC++, for instance), or MingW "soon" supports thread local storage >declspecs, a threaded implementation would be just too difficult to >integrate cleanly with the existing source base. > I'm trying to understand this. Is it that the existing code references static data in so many places that it impractical to move all that into a structures? You could put a structure high up on the stack of each thread and pass down a pointer to it, or use a hash on thread id to reference the data. Structuring those globals would probably flush out some, er, "undocumented enhancements". It looks like the Apache group put a lot of work into modularizing their execution model for their 2.0.x. It has certainly made their app a serious choice under Windows. - Marsh
Marsh Ray wrote: > Claudio Natoli wrote: > >>> Specifically, I believe and through conversations with several Win32 >> >> programmers I know, that using create process is a bad idea and that we >> should move to a threaded model (at least for Win32). >> >> CreateProcess appears to be the method the core developers have decided >> upon. Unfortunately, and speaking from experience, unless either the >> decision to use MingW as a build environment is reviewed (as opposed to >> VC++, for instance), or MingW "soon" supports thread local storage >> declspecs, a threaded implementation would be just too difficult to >> integrate cleanly with the existing source base. >> > I'm trying to understand this. Is it that the existing code references > static data in so many places that it impractical to move all that into > a structures? > > You could put a structure high up on the stack of each thread and pass > down a pointer to it, or use a hash on thread id to reference the data. > Structuring those globals would probably flush out some, er, > "undocumented enhancements". > > It looks like the Apache group put a lot of work into modularizing their > execution model for their 2.0.x. It has certainly made their app a > serious choice under Windows. I don't think it makes sense to have threading on only one platform from a common code base. Perhaps a parallel effort needs to be to develop a threaded version for Unix and see how portable and stable it is, and then see how we can get that onto Windows. The TODO list at http://developer.postgresql.org/todo.php has these items which all seem potentially relevant: # Experiment with multi-threaded backend [thread <http://momjian.postgresql.org/cgi-bin/pgtodo?thread>] # Add connection pooling [pool <http://momjian.postgresql.org/cgi-bin/pgtodo?pool>] # Allow persistent backends [persistent <http://momjian.postgresql.org/cgi-bin/pgtodo?persistent>] If we are threaded do we still need to use SYSV shared memory? Threading has all sorts of other wrinkles, too (see recent discussion of SIGPIPE handling in threaded libpq apps for example). This URL seems to indicate what is happening with TLS in gcc for w32: http://gcc.gnu.org/ml/gcc/2003-10/msg00580.html ISTM that the best plan is to get it working for now with CreateProcess if possible. If the performance sucks really badly or it is unstable then we would have to reassess. cheers andrew
-----Original Message----- From: Andrew Dunstan [mailto:andrew@dunslane.net] Sent: Friday, November 07, 2003 10:02 AM To: pgsql-hackers-win32 Subject: Re: [pgsql-hackers-win32] Committing Resources to Win32 I don't think it makes sense to have threading on only one platform from a common code base. Perhaps a parallel effort needs to be to develop a threaded version for Unix and see how portable and stable it is, and then see how we can get that onto Windows. <snip> I 100% agree. Process management on windows is not *that* slow, and being able to track processes in the task manager is a nice feature. The IPC emulation over memory mapped files used in the PeerDirect port worked pretty much ok as did the rest of that port. If threading is really the way to go, it should be implemented and managed by the core team and not by the win32 porting effort. As for the move away from Visual Studio, it's going to cause a lot of short term pain (especially for would be contributors...like me :) ), but after some reflection I believe the move was the right one in the long run. Windows developers will be unfamiliar with the build environment but this can be mitigated by making a binary release for windows once in a while. Merlin
Merlin Moncure wrote: >As for the move away from Visual Studio, it's going to cause a lot of >short term pain (especially for would be contributors...like me :) ), >but after some reflection I believe the move was the right one in the >long run. Windows developers will be unfamiliar with the build >environment but this can be mitigated by making a binary release for >windows once in a while. > > > The only tool I have been using apart from the MinGW set is XEmacs for Windows. But then I'm far more at home developing for Unix than for Windows, so this is almost the same toolset I use all the time. cheers andrew
> I'm trying to understand this. Is it that the existing code references > static data in so many places that it impractical to move all > that into a structures? More like "unjustifiable for a single port" than impractical. > You could put a structure high up on the stack of each thread and pass > down a pointer to it, or use a hash on thread id to reference > the data. The second approach is more or less what I'm doing myself on a private port. However, the code for this simply would not integrate cleanly with the existing source base. What would is use of the __declspec(thread) directive, which could be macro'd into the definition of each global var under Win32. This, with some other related changes, would bring a Win32 multi-threaded port into existence in short order, however is not (yet) supported under the MingW environment. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
On Mon, 10 Nov 2003, Claudio Natoli wrote: > > > I'm trying to understand this. Is it that the existing code references > > static data in so many places that it impractical to move all > > that into a structures? > > More like "unjustifiable for a single port" than impractical. Not for a single port, maybe, but if it was done cleanly enough, could help for those that are investigating 'threading' parts of the backend to improve performance ... Note that the only reason that this hasn't been done yet is because nobody so far has step'd up to do more then propose it ... ever proposition, so far as my memory serves, has been "do it all at once" instead of incremental clean ups ...
> The requirement is that we can build with opensource tools. I'm quite > prepared to buy the (cheap version of) VC++, but only as a last resort. > Sorry for the late reply in this. I was ill all last week. Although I understand and commend the idea that we should be able to build with Open Source tools, the question comes to "What if the Open Source tools aren't good enough?". We could always use Borland or Intel. Win32 has shown a great performance boost for itself when using a threaded model of the process model. It could be argued (I read somewhere but can't remember where) that a great deal of the recent Apache growth (last 12 months) is due to the fact that they finally delivered a product that works on Win32 correctly (Apache 2.x). I believe that Apache 2.x is not completly threaded.. don't they use some kind of hybrid model? Hmmm... maybe this all becomes moot if we also do connection pooling? This all comes about because the customer that has requested that I put resources into the Win32 port is a customer that comes from Oracle. Their remark was that Oracle tried to go in a very similar direction during their initial Win32 port and it failed miserably. I believe the customer said it was during Oracle 7.x? Anyway.. the point is that I want to make sure we do it right and not have to go back to the drawing board. We are not talking about the differences between FreeBSD and Linux here. Win32 is an entirely different beast. Sincerely, Joshua D. Drake > cheers > > andrew > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
Joshua D. Drake wrote: > aren't good enough?". We could always use Borland or Intel. Borland released (not sure if they still do) a C++ compiler that is free for download (but closed source). Borland's compiler is a pretty decent C++ compiler, not sure how well it handles C, it does support TLS though. > I believe that Apache 2.x is not completly threaded.. don't they use > some kind of hybrid model? Apache by nature has a lot more performance issues wrt threading and process management. Postgres is more generally I/O bound. My professional opinion is that for win32 performance we should be looking at how the file system calls, especially synching, will run rather than ipc and threading. > Hmmm... maybe this all becomes moot if we also do connection pooling? This would serialize all database access...IMO not worth considering this angle. TLS variables are supported by the Win32 API, and all C compilers for windows support the Win32 API. __declspec(thread) is just syntactic sugar which automate the API TLS commands. Converting the variable access syntax is likely just one part of the overall move to the threaded approach. A win32 centric move to threading will marginalize the port (again, IMO). Regards, Merlin
Merlin Moncure wrote: >Joshua D. Drake wrote: > > > > > >>I believe that Apache 2.x is not completly threaded.. don't they use >>some kind of hybrid model? >> >> > >Apache by nature has a lot more performance issues wrt threading and >process management. Postgres is more generally I/O bound. My >professional opinion is that for win32 performance we should be looking >at how the file system calls, especially synching, will run rather than >ipc and threading. > Yes, Web requests by the nature of the protocol are short-lived connections - if you are setting up and breaking down connections at a very fast clip then forking a server per connection is going to be very expensive. That is not a common usage pattern with a database server and a well written app, IMNSHO. Apache's APR took them years to get right, too. >>Hmmm... maybe this all becomes moot if we also do connection pooling? >> >> > >This would serialize all database access...IMO not worth considering >this angle. > Why does it serialize access? I have a web server app with connection pooling - it has a pool of 20 connections that it keeps around for when they are needed - they can all be active at any given time. And a good connection pool manager sets up the connections ahead of time so that each request sees *no* startup time. > >TLS variables are supported by the Win32 API, and all C compilers for >windows support the Win32 API. __declspec(thread) is just syntactic >sugar which automate the API TLS commands. Converting the variable >access syntax is likely just one part of the overall move to the >threaded approach. A win32 centric move to threading will marginalize >the port (again, IMO). > > > *nod* Joshua, can you tell us any more about the nature of your client's app(s)? Speculating like this in the dark is a bit fruitless. cheers andrew
Merlin Moncure wrote: >Joshua D. Drake wrote: > > >>aren't good enough?". We could always use Borland or Intel. >> >> > >Borland released (not sure if they still do) a C++ compiler that is free >for download (but closed source). > And Intel won't sell you their Windows compiler unless you already own Microsoft's. - Marsh
> *nod* > > Joshua, can you tell us any more about the nature of your client's > app(s)? Speculating like this in the dark is a bit fruitless. > I can't legally tell you much but what I can tell you is: There application creates a great deal of processes that open and close. On Linux which has a very light process model the performance hit is nominal. On platforms like Win32 or Solaris where processes are expensive, under heavy load you can see a pretty significant increase in performance by going to a threaded model. They are currently running our Cygwin installation which combined with connection pooling has provided "ok" performance but nothing worth writing home about (especially considering they compared against Linux). I am not going to lie, from a Windows perspective I am a little bit of a PHB. I don't develop (personally) on Windows. However the customer requirements are simple: Command Prompt needs to provide a native Win32 PostgreSQL version that supplies a reasonable proximity of performance per the Linux native version. The Win32 native version must also maintain the same level of transactibility as the Linux version. My customer is a house of Windows C/C++ and they are telling me that using CreateProcess will not generate that proximity. They and I could be totally on crack, but my own research suggests pretty much the same thing and the Windows programmers that I have talked to that are not associated with this customer also say the same thing. What this all comes down to for us is this: Can we (the community) develop a Win32 native version using CreateProcess that will scale and perform at a level that is acceptable to wide general use. Understanding that for many operations PostgreSQL on Linux will perform as well if not faster than the other well known database with the letter O in their name. Sincerely, Joshua Drake > cheers > > andrew > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
> And Intel won't sell you their Windows compiler unless you already own > Microsoft's. > That still leaves Borland as an option. So what if it is not Open Source. Option 2: What would it take to add the functionality we need to minGW? > - Marsh > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
Joshua D. Drake wrote: > >> >> Joshua, can you tell us any more about the nature of your client's >> app(s)? Speculating like this in the dark is a bit fruitless. >> > I can't legally tell you much but what I can tell you is: > > There application creates a great deal of processes that open and close. > On Linux which has a very light process model the performance hit is > nominal. On platforms like Win32 or Solaris where processes are > expensive, under heavy load you can see a pretty significant increase > in performance by going to a threaded model. > > They are currently running our Cygwin installation which combined with > connection pooling has provided "ok" performance but nothing > worth writing home about (especially considering they compared against > Linux). I think the short answer is that we should do better than the Cygwin version (a lot better, probably) - anecdotal information about the previous PeerDirect port suggested significant performance gains, but not as well as a threaded version. I personally ran that version very happily for months, but not under heavy connection load. If they see big improvements with threads on Solaris they would probably see bigger improvements on Windows, I suspect, although Solaris process creation cost is notoriously high (as it is on Windows). > > I am not going to lie, from a Windows perspective I am a little bit of > a PHB. I don't develop (personally) on Windows. However the > customer requirements are simple: > > Command Prompt needs to provide a native Win32 PostgreSQL version that > supplies a reasonable proximity of performance > per the Linux native version. The Win32 native version must also > maintain the same level of transactibility as the Linux version. > > My customer is a house of Windows C/C++ and they are telling me that > using CreateProcess will not generate that proximity. > > They and I could be totally on crack, but my own research suggests > pretty much the same thing and the Windows programmers > that I have talked to that are not associated with this customer also > say the same thing. You are not on crack. The question is how we can get there, within the generally accepted parameters of the PostgreSQL project. Those include, as I understand it, . use of Open Source software tools only to build, and . maintaining a single body of code > > > What this all comes down to for us is this: > > Can we (the community) develop a Win32 native version using > CreateProcess that will scale and perform at a level that > is acceptable to wide general use. Understanding that for many > operations PostgreSQL on Linux will perform as well if > not faster than the other well known database with the letter O in > their name. Depends right now on your definition of "wide use" ;-) The "O" entity's connection times are also notoriously slow. I think we can get acceptable performance for what I would regard as typical usage patterns. But possibly not right now for your client's usage pattern. cheers andrew
If you guys have already discussed the following possibilities, I apologize. I joined the list late. The correct way to create a high performance server on the Windows platform (NT, Advanced Server, etc) is to utilize IO Completion Ports. The kernel will manage your connection pool and threading for you. Any object that is serializable can utilize this model (sockets, files, etc). If one thread becomes busy with processing, a second worker thread is awoken, and it performs the processing. Sockets and threads are all preallocated to increase performance. Here are a couple informative articles on the subject : Writing scalable server applications using IOCP http://www.codeproject.com/internet/iocp.asp Developing a Truly Scalable Winsock Server using IO Completion Ports http://www.codeproject.com/internet/winsockiocp.asp The Microsoft SDK comes with a free compiler, but you will have access to only the API functions, none of the frameworks (MFC, ATL, etc). Jim -----Original Message----- From: pgsql-hackers-win32-owner@postgresql.org [mailto:pgsql-hackers-win32-owner@postgresql.org] On Behalf Of Joshua D. Drake Sent: Monday, November 10, 2003 4:57 PM To: Andrew Dunstan Cc: pgsql-hackers-win32@postgresql.org Subject: Re: [pgsql-hackers-win32] Committing Resources to Win32 > *nod* > > Joshua, can you tell us any more about the nature of your client's > app(s)? Speculating like this in the dark is a bit fruitless. > I can't legally tell you much but what I can tell you is: There application creates a great deal of processes that open and close. On Linux which has a very light process model the performance hit is nominal. On platforms like Win32 or Solaris where processes are expensive, under heavy load you can see a pretty significant increase in performance by going to a threaded model. They are currently running our Cygwin installation which combined with connection pooling has provided "ok" performance but nothing worth writing home about (especially considering they compared against Linux). I am not going to lie, from a Windows perspective I am a little bit of a PHB. I don't develop (personally) on Windows. However the customer requirements are simple: Command Prompt needs to provide a native Win32 PostgreSQL version that supplies a reasonable proximity of performance per the Linux native version. The Win32 native version must also maintain the same level of transactibility as the Linux version. My customer is a house of Windows C/C++ and they are telling me that using CreateProcess will not generate that proximity. They and I could be totally on crack, but my own research suggests pretty much the same thing and the Windows programmers that I have talked to that are not associated with this customer also say the same thing. What this all comes down to for us is this: Can we (the community) develop a Win32 native version using CreateProcess that will scale and perform at a level that is acceptable to wide general use. Understanding that for many operations PostgreSQL on Linux will perform as well if not faster than the other well known database with the letter O in their name. Sincerely, Joshua Drake > cheers > > andrew > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Using completion ports assumes your app is threaded in the first instance, doesn't it? Unless I am mistaken, at the moment . we don't have a server app at all . our code base does not currently support threading, and we want to keep to a single code base - corollary: we don't know if supporting POSIX threads and Windows threads in a single code base is possible or sensible . we don't know of any OpenSource tools that support compiling threaded apps with TLS on Windows (specifically, MinGW does not, apparently) So I suspect we are a very long way from being able to use Completion Ports. cheers andrew Jim Jones wrote: >If you guys have already discussed the following possibilities, I >apologize. I joined the list late. > >The correct way to create a high performance server on the Windows >platform (NT, Advanced Server, etc) is to utilize IO Completion Ports. >The kernel will manage your connection pool and threading for you. Any >object that is serializable can utilize this model (sockets, files, >etc). > >If one thread becomes busy with processing, a second worker thread is >awoken, and it performs the processing. Sockets and threads are all >preallocated to increase performance. > >Here are a couple informative articles on the subject : > >Writing scalable server applications using IOCP >http://www.codeproject.com/internet/iocp.asp > >Developing a Truly Scalable Winsock Server using IO Completion Ports >http://www.codeproject.com/internet/winsockiocp.asp > >The Microsoft SDK comes with a free compiler, but you will have access >to only the API functions, none of the frameworks (MFC, ATL, etc). > >Jim > > >-----Original Message----- >From: pgsql-hackers-win32-owner@postgresql.org >[mailto:pgsql-hackers-win32-owner@postgresql.org] On Behalf Of Joshua D. >Drake >Sent: Monday, November 10, 2003 4:57 PM >To: Andrew Dunstan >Cc: pgsql-hackers-win32@postgresql.org >Subject: Re: [pgsql-hackers-win32] Committing Resources to Win32 > > > > >>*nod* >> >>Joshua, can you tell us any more about the nature of your client's >>app(s)? Speculating like this in the dark is a bit fruitless. >> >> >> >I can't legally tell you much but what I can tell you is: > >There application creates a great deal of processes that open and close. > > >On Linux which has a very light process model the performance hit is >nominal. On platforms like Win32 or Solaris where processes are >expensive, under heavy load you can see a pretty significant increase in > >performance by going to a threaded model. > >They are currently running our Cygwin installation which combined with >connection pooling has provided "ok" performance but nothing >worth writing home about (especially considering they compared against >Linux). > >I am not going to lie, from a Windows perspective I am a little bit of a > >PHB. I don't develop (personally) on Windows. However the >customer requirements are simple: > >Command Prompt needs to provide a native Win32 PostgreSQL version that >supplies a reasonable proximity of performance >per the Linux native version. The Win32 native version must also >maintain the same level of transactibility as the Linux version. > >My customer is a house of Windows C/C++ and they are telling me that >using CreateProcess will not generate that proximity. > >They and I could be totally on crack, but my own research suggests >pretty much the same thing and the Windows programmers >that I have talked to that are not associated with this customer also >say the same thing. > >What this all comes down to for us is this: > >Can we (the community) develop a Win32 native version using >CreateProcess that will scale and perform at a level that >is acceptable to wide general use. Understanding that for many >operations PostgreSQL on Linux will perform as well if >not faster than the other well known database with the letter O in their > >name. > >Sincerely, > >Joshua Drake > > > > > > >>cheers >> >>andrew >> >> >>---------------------------(end of >> >> >broadcast)--------------------------- > > >>TIP 5: Have you checked our extensive FAQ? >> >> http://www.postgresql.org/docs/faqs/FAQ.html >> >> > > > >
Jim Jones wrote: >If you guys have already discussed the following possibilities, I >apologize. I joined the list late. > >The correct way to create a high performance server on the Windows >platform (NT, Advanced Server, etc) is to utilize IO Completion Ports. > > 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. - Marsh
Joshua D. Drake wrote: > Can we (the community) develop a Win32 native version using > CreateProcess that will scale and perform at a level that > is acceptable to wide general use. Understanding that for many > operations PostgreSQL on Linux will perform as well if > not faster than the other well known database with the letter O in their > name. IMO, The answer is yes. Don't take my word for it though, download the PeerDirect port and slam it a bit, and compare vs. a similar *nix version running pg 7.2.1. (or, run the cygwin version). In my experience, the cygwin version runs just fine performance wise, the only problem is the ipc-daemon which has a tendency to crash. It seems slower on writes, but that is strictly anecdotal. With synching off, it hums along happily. The perceived win32 process management problems are a total red herring. The major issues are process startup time and memory system performance issues wrt using memory mapped files for shared memory. In Postgres's case, the latter is more important but the performance disparity really is quite minor (and gets slimmer with each version of windows). Practical matters of development should outweigh performance concerns...do you want to be writing a fork, or a port? A functional server can be optimized a lot easier than a planned one. Are you comfortable that 320 hours is enough time to complete a threaded version? Developer skill level and familiarity with the databases sources will play into that. Regards, Merlin
>>
>>
> 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.
> - Marsh
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
> your
> joining column's datatypes do not match
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
>IMO, The answer is yes. Don't take my word for it though, download the >PeerDirect port and slam it a bit, and compare vs. a similar *nix >version running pg 7.2.1. (or, run the cygwin version). In my >experience, the cygwin version runs just fine performance wise, the only > > Try running the Cygwin version with more that 65 connections. Try running the Cygwin version doing more than 10,000 transactions over 5 connections (50,000 transactions). Now run a vacuum. Try running the Cygwin version doing more than 10,000 transactions over 5 connections (50,000 transactions), run an application that during that test will turn a tif into a postscript file for 5 different people and then load it into the database.... Cygwin is fine if you want MS Access level performance (O.k. that is a little harsh but close). Cyrgin is not fine if you want Linux/FreeBSD or any semblance thereof performance. >problem is the ipc-daemon which has a tendency to crash. It seems >slower on writes, but that is strictly anecdotal. With synching off, it >hums along happily. > > It is slower on rights, connection startup, limited on connections, tcp/ip transfer and you should never run PostgreSQL with sync off unless you are not worried about data integrity. >The perceived win32 process management problems are a total red herring. > > I disagree... read the other posts. CreateProcess does not scale like CreateThread. >Practical matters of development should outweigh performance >concerns...do you want to be writing a fork, or a port? A functional >server can be optimized a lot easier than a planned one. Are you >comfortable that 320 hours is enough time to complete a threaded >version? Developer skill level and familiarity with the databases >sources will play into that. > > I don't know that 320 hours would deliver a threaded port but I also don't want to go at this the wrong way. Sincerely, Joshua D. Drake >Regards, >Merlin > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
Andrew Dunstan wrote: > Using completion ports assumes your app is threaded in the first > instance, doesn't it? Basically, yes, but using asynch I/O (file comp. ports) does not necessarily require the whole thing have to be moved over to threads. That said, I agree on all points. Merlin
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
Andrew Dunstan wrote: > >> Specifically, I believe and through conversations with several Win32 > >> > >> > >programmers I know, that using create process is a bad idea and that we > >should move to a threaded model (at least for Win32). > > > >CreateProcess appears to be the method the core developers have decided > >upon. Unfortunately, and speaking from experience, unless either the > >decision to use MingW as a build environment is reviewed (as opposed to > >VC++, for instance), or MingW "soon" supports thread local storage > >declspecs, a threaded implementation would be just too difficult to > >integrate cleanly with the existing source base. > > > > > > > > The requirement is that we can build with opensource tools. I'm quite > prepared to buy the (cheap version of) VC++, but only as a last resort. Actually, I think the requirement wasn't that we can build with open-source tools, but rather that we can build using the same toolchain we have under Unix. The concern was that a separate build environment made up of Visual C project files was not maintainable. MinGW allows us to use that same tool chain, as does Cygwin as well. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Marsh Ray wrote: > Claudio Natoli wrote: > > >> Specifically, I believe and through conversations with several Win32 > >> > >> > >programmers I know, that using create process is a bad idea and that we > >should move to a threaded model (at least for Win32). > > > >CreateProcess appears to be the method the core developers have decided > >upon. Unfortunately, and speaking from experience, unless either the > >decision to use MingW as a build environment is reviewed (as opposed to > >VC++, for instance), or MingW "soon" supports thread local storage > >declspecs, a threaded implementation would be just too difficult to > >integrate cleanly with the existing source base. > > > I'm trying to understand this. Is it that the existing code references > static data in so many places that it impractical to move all that into > a structures? > > You could put a structure high up on the stack of each thread and pass > down a pointer to it, or use a hash on thread id to reference the data. > Structuring those globals would probably flush out some, er, > "undocumented enhancements". > > It looks like the Apache group put a lot of work into modularizing their > execution model for their 2.0.x. It has certainly made their app a > serious choice under Windows. Agreed, threads have helped Apache under Windows, but it doesn't seem to be buying them much under Unix, so then we have to wonder whether adding the cruft to the source tree is worth it. Right now I have done stuff that is needed under Win32 wether we use thread or CreateProcess, and in fact once I have fork/exec work under Unix (and then Win32 CreateProcess), all the code will be marked as EXEC_BACKEND so we can come back later if we need to remove it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Hello,
O.k. there has been a lot of discussion in regards to what the best
method to take with PostgreSQL Win32 is.
It seems that the community is set on using CreateProcess. If this is
the case I have a couple of further questions:
1. Are we just a bunch of Unix coders trying to develop a product for
Win32 or are there any people a part
of the Win32 port project that actually have REAL, hardcore experience
coding at the system level for Win32?
I am not trying to be an antagonist but I it is a legitamate question.
2. Have we built a test case? For example:
We have a client that connects to a server. For every connection we
start a new process and write 1k to disk from the client.
Connect in varying degrees from 5 connection to say 500 connections.
Do it with CreateProcess and the with CreateThread... Time the
difference, and review the load on the server during the tests...
What is the difference? Maybe it is nominal enough not to worry
about it... Maybe it's not.
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC
Postgresql support, programming, shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL.Org - Editor-N-Chief - http://www.postgresql.org
CreateProcess has to come first since all the work that happens for the
multithreaded version also has to happen for the CreateProcess version, and
it's just natural that it will come first.
It makes a lot of sense for Postgres to get the CreateProcess version
working and stable before embarking on threads - Win32 and threading are two
separate and mostly unrelated tasks, but threading on Win32 can't happen
until Win32 is stable.
Just my two cents...
- Steve
-----Original Message-----
From: pgsql-hackers-win32-owner@postgresql.org
[mailto:pgsql-hackers-win32-owner@postgresql.org] On Behalf Of Joshua D.
Drake
Sent: November 13, 2003 12:30 PM
To: pgsql-hackers-win32@postgresql.org
Subject: [pgsql-hackers-win32] CreateProcess vs Create Thread
Hello,
O.k. there has been a lot of discussion in regards to what the best
method to take with PostgreSQL Win32 is.
It seems that the community is set on using CreateProcess. If this is the
case I have a couple of further questions:
1. Are we just a bunch of Unix coders trying to develop a product for
Win32 or are there any people a part
of the Win32 port project that actually have REAL, hardcore experience
coding at the system level for Win32?
I am not trying to be an antagonist but I it is a legitamate question.
2. Have we built a test case? For example:
We have a client that connects to a server. For every connection we
start a new process and write 1k to disk from the client.
Connect in varying degrees from 5 connection to say 500 connections.
Do it with CreateProcess and the with CreateThread... Time the
difference, and review the load on the server during the tests...
What is the difference? Maybe it is nominal enough not to worry about
it... Maybe it's not.
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC - S/JDBC
Postgresql support, programming, shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL.Org - Editor-N-Chief - http://www.postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
Joshua D. Drake wrote: > Hello, > > O.k. there has been a lot of discussion in regards to what the best > method to take with PostgreSQL Win32 is. > It seems that the community is set on using CreateProcess. If this is > the case I have a couple of further questions: > > 1. Are we just a bunch of Unix coders trying to develop a product for > Win32 or are there any people a part > of the Win32 port project that actually have REAL, hardcore experience > coding at the system level for Win32? > I am not trying to be an antagonist but I it is a legitimate question. Not sure. We have a working Win32 port from PeerDirect, and I have one from SRA, so we know it can be done whether we have hard-core guys or not. > 2. Have we built a test case? For example: > > We have a client that connects to a server. For every connection we > start a new process and write 1k to disk from the client. > > Connect in varying degrees from 5 connection to say 500 connections. > > Do it with CreateProcess and the with CreateThread... Time the > difference, and review the load on the server during the tests... > > What is the difference? Maybe it is nominal enough not to worry > about it... Maybe it's not. I certainly would like to see that test with a skelaton C program. You can use PeerDirect's beta version for the CreateProcess test. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Joshua D. Drake wrote: > Hello, > > O.k. there has been a lot of discussion in regards to what the best > method to take with PostgreSQL Win32 is. > It seems that the community is set on using CreateProcess. If this is > the case I have a couple of further questions: > > 1. Are we just a bunch of Unix coders trying to develop a product for > Win32 or are there any people a part > of the Win32 port project that actually have REAL, hardcore experience > coding at the system level for Win32? > I am not trying to be an antagonist but I it is a legitamate question. Speaking for myself I am a Unix coder and proud of it :-) I don't know how many times I have said in my professional life "I don't do Windows". That's why I chose to make my major contribution to the project the porting of initdb to C - it had to be done (and it took me quite a few hours) but it didn't require a deep level of understanding of Windows. OTOH there is clearly a deeper level of understanding and experience around than I have. I think the answer is a mixture. cheers andrew
Joshua D. Drake wrote: > 1. Are we just a bunch of Unix coders trying to develop a product for > Win32 or are there any people a part of the Win32 port project that > actually have REAL, hardcore experience coding at the system level for > Win32? I've got exactly 10 years' experience as a Win32 coder, most of it on the server side. I haven't yet committed any time to the effort, but I suppose if I keep yacking on this list, then I'll have to. I really think what Steve Tibbett said is right on the money: >CreateProcess has to come first since all the work that happens for the >multithreaded version also has to happen for the CreateProcess version, and >it's just natural that it will come first. >It makes a lot of sense for Postgres to get the CreateProcess version >working and stable before embarking on threads - Win32 and threading are two >separate and mostly unrelated tasks, but threading on Win32 can't happen >until Win32 is stable. > I'll guess that once any Win32 version is out there with a nice installer and documentation, it will quickly become popular. It probably won't too slow for most uses, although benchmarkers might form lasting first impressions from it. This will probably reveal a demand for a threaded version. - Marsh
Joshua D. Drake wrote: > 1. Are we just a bunch of Unix coders trying to develop a product for > Win32 or are there any people a part of the Win32 port project that > actually have REAL, hardcore experience coding at the system level for > Win32? I've got exactly 10 years' experience as a Win32 coder, most of it on the server side. I haven't yet committed any time to the effort, but I suppose if I keep yacking on this list, then I'll have to. I really think what Steve Tibbett said is right on the money: >CreateProcess has to come first since all the work that happens for the >multithreaded version also has to happen for the CreateProcess version, and >it's just natural that it will come first. >It makes a lot of sense for Postgres to get the CreateProcess version >working and stable before embarking on threads - Win32 and threading are two >separate and mostly unrelated tasks, but threading on Win32 can't happen >until Win32 is stable. > I'll guess that once any Win32 version is out there with a nice installer and documentation, it will quickly become popular. It probably won't too slow for most uses, although benchmarkers might form lasting first impressions from it. This will probably reveal a demand for a threaded version. - Marsh