mandriva 发表于 2014-8-10 11:58
单做一件事，前景 就是 暗淡无光
通用的就前途无量。
全世界所有的公司用的基本上是win因简单易用，需 ...
纯粹理性探讨一下。
每秒100万次响应需要选用Linux，这个说法有一定误导性。。
Linux的Epoll和BSD的Kqueue的确属于性能不错的异步IO模型，Windows下也有类似的实现，好像叫IOCP还是啥。性能对比我没有具体做过，不好说。
但是内核的IO模型只是一方面。你说的100万次每秒我猜指的是静态响应，即使如此我也非常怀疑这个是否真的能达到，单机的话至少带宽就承受不了。如果每个静态文件3K，100万次每秒是 1M * 3K = 3GB 每秒，显然已经超出了大部分网卡的吞吐能力。如果你是指分布式的，那又是另一码事了，只要架构合理，预算足够，100w每秒不是什么困难。。
而且响应是个很宽泛的概念，服务端业务本身的复杂度才是值得讨论的地方。
实际情况中，很多响应是动态内容，需要有锁，IO或者数据同步的操作。
即使单机能同时异步处理大量的并发IO，但对于每个连接，任何一个会被阻塞的操作（数据库操作，磁盘IO）就能消耗不少时间。。而这些性能瓶颈更多是程序设计需要考虑和解决的架构问题了，和OS已经基本无关，虽然有些时候OS能提供一些便利。
我觉得Windows没有大家想象的那么差，Linux也没有大家吹得那么神。OS内核本身已经是相当成熟的领域，任何巨头都不会存在明显的技术优势。
Linux大行其道的原因和IPhone的兴起差不多，在开发者领域，其生态系统构建的相对早和成熟，基本上你需要的工具都有稳定的开源版本。
Windows属于微软自己的生态圈，很多东西需要付费，也不是要啥就有啥。但优点是图形界面比较人性化，还有微软完备的文档和技术支持。这些对于IT背景不强的企业，是有一定竞争力的。
技术牛不牛和会不会什么OS基本没有必然联系。。只是牛人碰到问题时倾向直接研究代码，那么Linux是不二选择。。
另外回答下楼主的问题。
Linux是个庞大的生态系统，可能一辈子都很难玩转。各种发行版也是混乱不堪，除了内核以外，缺乏统一的标准。这样就导致管理员干的事情很多很杂，很可能没有什么连续性和相关性。比如今天要你配置个啥，明天可能又是别的什么地方出毛病了。
而基本上这些东西没有太高的门槛，看文档和多实践，正常人都可以完成。
所以这样的管理员，我觉得除了工具使用的熟练一点外，和普通人没有什么区别。
比较理想点的情况是，你是具体负责某一个环节的管理员，比如专攻网络方面的，或者专注系统安全方面的，这样时间久了能沉淀不少东西，对成长是有利的。
本帖最后由 mandriva 于 2014-8-14 18:54 编辑
和路雪 发表于 2014-8-13 22:44
纯粹理性探讨一下。
每秒100万次响应需要选用Linux，这个说法有一定误导性。。
纯粹理性探讨一下。
每秒100万次响应需要选用Linux，这个说法有一定误导性。。
Linux的Epoll和BSD的Kqueue的确属于性能不错的异步IO模型，Windows下也有类似的实现，好像叫IOCP还是啥。性能对比我没有具体做过，不好说。
但是内核的IO模型只是一方面。你说的100万次每秒我猜指的是静态响应，即使如此我也非常怀疑这个是否真的能达到，单机的话至少带宽就承受不了。如果每个静态文件3K，100万次每秒是 1M * 3K = 3GB 每秒，显然已经超出了大部分网卡的吞吐能力。如果你是指分布式的，那又是另一码事了，只要架构合理，预算足够，100w每秒不是什么困难。。
而且响应是个很宽泛的概念，服务端业务本身的复杂度才是值得讨论的地方。
实际情况中，很多响应是动态内容，需要有锁，IO或者数据同步的操作。
即使单机能同时异步处理大量的并发IO，但对于每个连接，任何一个会被阻塞的操作（数据库操作，磁盘IO）就能消耗不少时间。。而这些性能瓶颈更多是程序设计需要考虑和解决的架构问题了，和OS已经基本无关，虽然有些时候OS能提供一些便利。
我觉得Windows没有大家想象的那么差，Linux也没有大家吹得那么神。OS内核本身已经是相当成熟的领域，任何巨头都不会存在明显的技术优势。
Linux大行其道的原因和IPhone的兴起差不多，在开发者领域，其生态系统构建的相对早和成熟，基本上你需要的工具都有稳定的开源版本。
Windows属于微软自己的生态圈，很多东西需要付费，也不是要啥就有啥。但优点是图形界面比较人性化，还有微软完备的文档和技术支持。这些对于IT背景不强的企业，是有一定竞争力的。
技术牛不牛和会不会什么OS基本没有必然联系。。只是牛人碰到问题时倾向直接研究代码，那么Linux是不二选择。。
另外回答下楼主的问题。
Linux是个庞大的生态系统，可能一辈子都很难玩转。各种发行版也是混乱不堪，除了内核以外，缺乏统一的标准。这样就导致管理员干的事情很多很杂，很可能没有什么连续性和相关性。比如今天要你配置个啥，明天可能又是别的什么地方出毛病了。
而基本上这些东西没有太高的门槛，看文档和多实践，正常人都可以完成。
所以这样的管理员，我觉得除了工具使用的熟练一点外，和普通人没有什么区别。
比较理想点的情况是，你是具体负责某一个环节的管理员，比如专攻网络方面的，或者专注系统安全方面的，这样时间久了能沉淀不少东西，对成长是有利的。
我的主张是Linux 在做服务器方面 远胜于 Windows
你想说什么？ Linux 在做服务器方面 比 Windows 没有优势？
你给我说一下这个问题
http://nginx.org/en/docs/windows.html
Known issues
Although several workers can be started, only one of them actually does any work.
A worker can handle no more than 1024 simultaneous connections.
The cache and other modules which require shared memory support do not work on Windows Vista and later versions due to address space layout randomization being enabled in these Windows versions.
为什么 一个工作进程只能处理不超过1024个并发连接 ？
我用的是 从一个变量开始 全部libs components 都自己构建的系统 http://en.wikipedia.org/wiki/Linux_From_Scratch， + Win8.1 ，以前用的mandriva debian fedora opensuse gentoo，最喜欢的 现成的 Linux distro 是debian 。
Linux下的 nginx 没有这个问题！！你给我说下为什么？
nginx的开发者 不懂Win32 API？
你的水平在 nginx的开发者 之上？ 去跟他们吹去吧。
我是信了！
你去把它解决了吧。
我希望你 去去研究一年nginx的代码 再来和我说，而不要通篇废话。
省的你说木星时间的2015年，我睁大眼睛看你到2016年。
Win32 API 的限制！这个不行就是不行
mandriva 发表于 2014-8-14 19:46
我的主张是Linux 在做服务器方面 远胜于 Windows
你想说什么？ Linux 在做服务器方面 比 Windows...
看来你对常见的IO模型没有系统的认识。
也看的出你没有开发网络服务器底层IO部分相关的经验，否则不会拿这么浅显的东西出来大喊大叫。。
哥今天心情好，就免费给你上一课。请你看好。
Ngnix在windows下选用了很古老的select IO轮询模型，所有的socket会被放在一个类似数组的set中，供轮询器进行查找。 其FD_SETSIZE默认大小是1024。 超过1024个连接后，数组放不下了，原因就是这么简单。。这个Size的大小如果系统支持的话，完全是可调的。
但鉴于select是复杂度O(n)级的操作，通常不建议将FD_SETSIZE调的过大，以免消耗过多的CPU时间。而且在select被发明的时代，也没有什么大并发的需求。。
Linux下的Nginx选用了Epoll IO模型，由于数据结构不同，已经没有了select那样的限制。其时间复杂度是O(1)常数级。。
Windows支持select这个经典模型的同时，也有更先进的IOCP供开发者使用，其性能不在EPOLL之下，也没有什么1024的限制。。
1024的原因，完全是Nginx自己没有选用更先进的API。而并不是windows本身没有提供更好的选择。。你以为微软的人都是傻子吗，连这么重要的底层的东西都提供不了？
Nginx其实有非正式的Windows IOCP移植版本，叫Ngwsx。
至于Nginx为什么不在windows上搞的更像样点，不是技术问题，而是其自身在商业上没有这个动力。其主要市场就是Linux。
因为Windows Server下，有牛X的IIS，这个东西性能目前强的很，根本不在Nginx之下。。
我从研究生期间便开始从事网络服务器方面的编程，现在在为公司开发apache上的模块，水平不敢说比nginx的开发者高，但是回答你的问题是足够的，也不需要去为此看一年的Nginx代码。。
另外要完全搞懂Nginx根本不需要1年好吗。。拜托请有点常识。。这东西又不是什么很高精尖的玩意。。
和路雪 发表于 2014-8-14 20:30
看来你对常见的IO模型没有系统的认识。
也看的出你没有开发网络服务器底层IO部分相关的经验，否则不会 ...
看来你对常见的IO模型没有系统的认识。
也看的出你没有开发网络服务器底层IO部分相关的经验，否则不会拿这么浅显的东西出来大喊大叫。。
哥今天心情好，就免费给你上一课。请你看好。
Ngnix在windows下选用了很古老的select IO轮询模型，所有的socket会被放在一个类似数组的set中，供轮询器进行查找。 其FD_SETSIZE默认大小是1024。 超过1024个连接后，数组放不下了，原因就是这么简单。。这个Size的大小如果系统支持的话，完全是可调的。
但鉴于select是复杂度O(n)级的操作，通常不建议将FD_SETSIZE调的过大，以免消耗过多的CPU时间。而且在select被发明的时代，也没有什么大并发的需求。。
Linux下的Nginx选用了Epoll IO模型，由于数据结构不同，已经没有了select那样的限制。其时间复杂度是O(1)常数级。。
Windows支持select这个经典模型的同时，也有更先进的IOCP供开发者使用，其性能不在EPOLL之下，也没有什么1024的限制。。
1024的原因，完全是Nginx自己没有选用更先进的API。而并不是windows本身没有提供更好的选择。。你以为微软的人都是傻子吗，连这么重要的底层的东西都提供不了？
Nginx其实有非正式的Windows IOCP移植版本，叫Ngwsx。
至于Nginx为什么不在windows上搞的更像样点，不是技术问题，而是其自身在商业上没有这个动力。其主要市场就是Linux。
因为Windows Server下，有牛X的IIS，这个东西性能目前强的很，根本不在Nginx之下。。
我从研究生期间便开始从事网络服务器方面的编程，现在在为公司开发apache上的模块，水平不敢说比nginx的开发者高，但是回答你的问题是足够的，也不需要去为此看一年的Nginx代码。。
另外要完全搞懂Nginx根本不需要1年好吗。。拜托请有点常识。。这东西又不是什么很高精尖的玩意。。
哥今天心情好，就免费给你上一课。请你看好。
Ngnix在windows下选用了很古老的select IO轮询模型，所有的socket会被放在一个类似数组的set中，供轮询器进行查找。 其FD_SETSIZE默认大小是1024。 超过1024个连接后，数组放不下了，原因就是这么简单。。这个Size的大小如果系统支持的话，完全是可调的。
但鉴于select是复杂度O(n)级的操作，通常不建议将FD_SETSIZE调的过大，以免消耗过多的CPU时间。而且在select被发明的时代，也没有什么大并发的需求。。
Linux下的Nginx选用了Epoll IO模型，由于数据结构不同，已经没有了select那样的限制。其时间复杂度是O(1)常数级。。
Windows支持select这个经典模型的同时，也有更先进的IOCP供开发者使用，其性能不在EPOLL之下，也没有什么1024的限制。。
比尔叔叔亲自告诉你，任凭你怎么调这个数目，但对Windows Sockets 的实现不产生影响，
http://support.microsoft.com/kb/111855
NOTE: Defining FD_SETSIZE as a particular value has no effect on the actual number of sockets provided by a Windows Sockets implementation.
硬限制 就是 Windows Sockets 的 implementation ==> Implementierung ==> 实现。
Linux没有这个问题，所以 Linux 在做服务器方面 远胜于 Windows 明白了么？
本帖最后由 和路雪 于 2014-8-14 22:41 编辑
mandriva 发表于 2014-8-14 22:04
比尔叔叔亲自告诉你，任凭你怎么调这个数目，但对Windows Sockets 的实现不产生影响，
http:/ ...
我没有明白。。
FD_SETSIZE在windows上不可调那就是内核对其有更严格的设定，这没什么好奇怪的。因为这个模型太古老了，1024在那个时代已经足够了。因为调大这个值意义不大，反而会容易出问题。
Linux都开源了，那实际上就是啥都允许了。。你强行调大这个值，也只是勉强能容纳更多的连接数，加大CPU的负担，属于很笨重的做法。。明智的选择是用更先进的IO模型取代之，比如Epoll。
Windows的IOCP理论上比Epoll和Kqueue更先进，也不存在1024的限制。如果Ngnix愿意支持IOCP，那么技术上完全不是问题，性能会有大幅度提高。
Ngnix当系统不支持Epoll和Kqueue的时候，作为保底可以选择Select IO模型。因为Select是绝大多数系统都支持的，代码的移植性很好。 换句话说，Ngnix根本没有针对Windows做深入的开发和优化。只是仅仅能在Windows上编译和跑起来而已。
但这根本就不能说明哪个系统更好。Windows已经提供了非常优秀的机制，只是Ngnix重心不在这一块，没有去启用而已。
如果你觉得Linux更好用，更熟练，那就好好用。我平时的开发也是基于Linux为主，同时要兼容Windows。但我从不觉得哪个系统能够远胜于另一个。。也没有任何全面的评测，能够证明哪个系统纯粹在技术上有压倒性的优势。。
两个系统都是砸了无数的钱和人进去的，两边也都有最好的科研和开发团队，操作系统领域最新的科研成果也都是会应用在其中的，只是商业上发展策略不同而已。
另外微软的技术底子是厚到一般人无法想象的，也是少数有研究机构的企业之一，对学术界和科研的贡献是不小的。说Windows很差，个人觉得可能性很低。。
本帖最后由 mandriva 于 2014-8-14 22:15 编辑
和路雪 发表于 2014-8-14 21:39
我没有明白。。
FD_SETSIZE在windows上不可调那就是内核对其有更严格的设定，这没什么好奇怪的。因 ...
我没有明白。。
FD_SETSIZE在windows上不可调那就是内核对其有更严格的设定，这没什么好奇怪的。因为这个模型太古老了，1024在那个时代已经足够了。因为调大这个值意义不大，反而会容易出问题。
Linux都开源了，那实际上就是啥都允许了。。你强行调大这个值，也只是勉强能容纳更多的连接数，加大CPU的负担，属于很笨重的做法。。明智的选择是用更先进的IO模型取代之，比如Epoll。
Windows的IOCP理论上比Epoll和Kqueue更先进，也不存在1024的限制。如果Ngnix愿意支持IOCP，那么技术上完全不是问题，性能会有大幅度提高。
Ngnix当系统不支持Epoll和Kqueue的时候，作为保底可以选择Select IO模型。因为Select是绝大多数系统都支持的，代码的移植性很好。 换句话说，Ngnix根本没有针对Windows做深入的开发和优化。只是仅仅能在Windows上编译和跑起来而已。
但这根本就不能说明哪个系统更好。Windows已经提供了非常优秀的机制，只是Ngnix重心不在这一块，没有去启用而已。
如果你觉得Linux更好用，更熟练，那就好好用。我平时的开发也是基于Linux为主，同时要兼容Windows。但我从不觉得哪个系统能够远胜于另一个。。也没有任何全面的评测，能够证明哪个系统纯粹在技术上有压倒性的优势。。
两个系统都是砸了无数的钱和人进去的，两边也都有最好的科研和开发团队，操作系统领域最新的科研成果也都是会应用在其中的，只是商业上发展策略不同而已。
另外微软的技术底子是厚到一般人无法想象的，也是少数有研究机构的企业之一，对学术界和科研的贡献是不小的。说Windows很差，个人觉得可能性很低。。
我没有明白。。
没有明白 就 等你能解决了 我说的下面的红色加粗的这个 nginx用在Win下 的 问题 再来给我说，再来XX我，而不要信口开河和通篇废话。我就说睁大眼睛看你到2016年都解决不了。
http://nginx.org/en/docs/windows.html
Known issues
Although several workers can be started, only one of them actually does any work.
A worker can handle no more than 1024 simultaneous connections.
The cache and other modules which require shared memory support do not work on Windows Vista and later versions due to address space layout randomization being enabled in these Windows versions.
说Windows很差，个人觉得可能性很低。。
我有说过 “Windows很差” 吗？ 自己模棱两可不要给别人戴绿帽！
我只执着自己的信念和主张，和别人讨论问题只在一个点上 Linux 在做服务器方面 远胜于 Windows
，而不是通篇废话。
解决不了那个问题就自行送客吧。
mandriva 发表于 2014-8-14 23:14
没有明白 就 等你能解决了 我说的下面的红色加粗的这个 nginx用在Win下 的 问题 再来给我说，再 ...
红字加粗。。。
哥可以分析代码，然后做些移植工作，最后解决。
但是哥为什么要解决你这种无聊的问题呢？哥觉得毫无意义，因为正常的工程师在正常情况下不会没事在windows上跑Ngnix这种东西。但如果你有这嗜好，而且出得起个好价钱，那么哥自然愿意帮你解决。。
红字是人家开发者心里清楚，在Windows上咱没投入精力搞，只能用个破烂模型将就用用，顺便好心提醒你这样的小白一下，免得出了问题都不知道咋回事。。弄得不好还往微软身上泼脏水。。
其实吧，人家兼容windows也就是象征性的表示一下：这玩意是能够跨平台的。。 结果你还真信了！！
你看看自己这句：我只执着自己的信念和主张。
虽然是个病句，但哥看着还是好感动。。这态度，完全已经超越了理性思维，上升到了信念的新高度，快和绿教那帮人对自己主的态度一样了。。
Linus知道了，可能会比哥更加感动，考虑给你发工资的。。
本帖最后由 mandriva 于 2014-8-14 23:23 编辑
和路雪 发表于 2014-8-14 23:06
红字加粗。。。
哥可以分析代码，然后做些移植工作，最后解决。
红字加粗。。。
哥可以分析代码，然后做些移植工作，最后解决。
但是哥为什么要解决你这种无聊的问题呢？哥觉得毫无意义，因为正常的工程师在正常情况下不会没事在windows上跑Ngnix这种东西。但如果你有这嗜好，而且出得起个好价钱，那么哥自然愿意帮你解决。。
红字是人家开发者心里清楚，在Windows上咱没投入精力搞，只能用个破烂模型将就用用，顺便好心提醒你这样的小白一下，免得出了问题都不知道咋回事。。弄得不好还往微软身上泼脏水。。
其实吧，人家兼容windows也就是象征性的表示一下：这玩意是能够跨平台的。。 结果你还真信了！！
你看看自己这句：
我只执着自己的信念和主张
。
虽然是个病句，但哥看着还是好感动。。这态度，完全已经超越了理性思维，上升到了信念的新高度，快和绿教那帮人对自己主的态度一样了。。
Linus知道了，可能会比哥更加感动，考虑给你发工资的。。
就你这种的就会欺负幼儿园的朋友呢。
一开始别人不会写字就欺负别人不会写字，
等到别人学会了写字，理屈词穷就开始骂街和泼赖了。
以前某个写手笔下的XX精神在你这种人的身上体现得淋漓尽致。
你发的另一个贴还有人等着你回复呢。就像你这种三脚猫的程序员 碰到不给力的同事咋办？ 你的同事想给你说，你要是能解决那个在Win下的问题，叔把它给吞了。
和路雪 发表于 2014-8-15 00:06
红字加粗。。。
哥可以分析代码，然后做些移植工作，最后解决。
有这时间和无聊路人鸡同鸭讲 为什么不陪陪你学机械的老婆逛个街聊聊天。。