I dont think its that easy. 50,000 sockets open, sure, but whats the
performance? The programming model has everything to do with that,
and windows select() wont support that many sockets with any sort of
performance. For windows you have to convert to using non-blocking
sockets w/messages. (and I've never see the PG code, but I'll bet
it's not using non-blocking sockets & windows msg q, so 50k sockets
using select() on windows will not be usable).
That being said, I'm not a windows socket component developer, so its
mostly guessing. But saying "it can" and saying "its usable" are two
different things, and that depends on the code, not the registry
settings.
Actually that is incorrect. You can use Synchronous non-blocking
sockets. Asynchronous is a nightmare due to the overhead of pushing and
handling messages... the busier the kernel, the slower your application.
Syn-Non-Blocking will perform a small degradation in performance every
5,000 sockets. (Meaning 10,000 streams is minimally slower than 5,000 -
but enough to denote degradation).
Systems Running my product and Designs:
AOL's Proxy Server System
Some of the UK's largest ISP's
AT&T Fiber Monitoring Framework
HBO Video Streaming to Satellite
Hart, a Front-End for TransUnion, Equifax and Experian
OFAC Query (B-Tree Query Service, processing over 100,000 requests
a second) (*)
* WAN Latency plays a running variable on their stats, but they average
100,000+ a second during peak-hours. [1 master, 2 fail-over
load-balanced servers].
Most people run into the "2048+/-" thread limitation until they learn
how to properly manage stack allocation per thread. I have been
designing commercial enterprise socket solutions for over 15 years and
sell an SDK that no product has yet to touch and I compete with ALL the
big boys (and they all know who I am). :-) ... the limitations in
performance are factors of poor (modern sloppiness) variable allocation,
memory management, buffering techniques, etc. I got out of actively
promoting DXSock (my socket suite) when I found I could capitalize more
on my time and my product... so since 2000 - I sale my knowledge.
Factors which also come into play are the built-in overhead of the
Operating System when it is a "Network Client/Server" it has active
connections. These connections also incur the poor default settings
Microsoft picked (FIN_WAIT/2 issue which is another registry tweak).
Once you learn what servers a "Dedicated Windows Server" will not need,
rip out all of the excess "Network Client" junk (and this is well
documented all over the net) - you can produce very robust Windows
servers. (Of course there are much better solutions for production
servers than Windows - but, people still drink the Microsoft "blue"
coolaide.
* People who document the registry tweaks needed:
http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.dc38421_1500/html/ntconfig/X26667.htm
;-)
O.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
