由买买提看人间百态

topics

全部话题 - 话题: nginx
1 2 3 4 5 6 7 8 9 10 下页 末页 (共10页)
r****r
发帖数: 22
1
来自主题: StartUp版 - Nginx vs. Apache
小流量当然没区别,apache用起来方便。
要节省内存比如便宜vps,nginx优势很大。
流量大的时候apache上边还要加一个nginx来负载均衡,还不如直接用nginx。
总的来说,内存足,流量小可能用到apache,其他情况都是nginx占优。
以发展的眼光,学nginx比apache值。
c********g
发帖数: 1173
2
来自主题: PhotoGear版 - 问个nginx rewrite的问题 (转载)
这儿牛人多,转过来哪位高手帮忙看看。
【 以下文字转载自 Linux 讨论区 】
发信人: cosmorning (Sleeping pig), 信区: Linux
标 题: 问个nginx rewrite的问题
发信站: BBS 未名空间站 (Thu Feb 14 23:33:19 2013, 美东)
现在要把URL:http://www.example.com/product/product-name/1234 forward到:http://www.example.com/details/product.jsp?pid=1234,希望用户端browser里看到的URL仍是第一个。我用了这个rewrite rule:
rewrite ^/product/(.*)/(\d+)$ /details/product.jsp?pid=$2;
但是,在product.jsp里,有一个指向css文件的连接:

bootstrap.css 所在目录是: /usr/sha... 阅读全帖
r*****s
发帖数: 1815
3
来自主题: JobHunting版 - Load balancer: NGINX vs HAproxy vs hardware
大公司用硬件lb。初创的话还是用nginx吧 tomcat做lb我印象中是比nginx慢很多的
c********g
发帖数: 1173
4
来自主题: Linux版 - 问个nginx rewrite的问题
现在要把URL:http://www.example.com/product/product-name/1234 forward到:http://www.example.com/details/product.jsp?pid=1234,希望用户端browser里看到的URL仍是第一个。我用了这个rewrite rule:
rewrite ^/product/(.*)/(\d+)$ /details/product.jsp?pid=$2;
但是,在product.jsp里,有一个指向css文件的连接:

bootstrap.css 所在目录是: /usr/share/nginx/www/docs/assets/css/ . 当我用了
上面的rewrite rule之后,root directory不知问什么就变成了 www/product, 所以
在 details/product.jsp里 bootstrap.css 的连接就变成了:
/usr/share/n... 阅读全帖
l**********n
发帖数: 8443
5
来自主题: Programming版 - 大家node都是跑在nginx后面吗?
你为什么要整nginx cluster?还有,nginx cluster是distributed的吗?还是像node
cluster module那样?

发帖数: 1
6
軟件設計太重要了,今天測試golang algernon http server靜態文件性能,比nginx差
了幾十倍以上。在我們硬件CPU領域,別說差幾倍,性能提升5%都叫大改進,可以更新
一代架構了。
這使我對golang寫的多核應用程序性能產生懷疑:一個http server在48核處理器上居
然搞出124個threads,而且沒有pin to core,不識別numa,簡單靜態文件性能還沒有
nginx的零頭多,75% CPU都是idle,有失golang的水準。
這讓我想到了EE工程師的悲哀:世界上硬件CPU公司屈指可數,最牛的CPU公司性能比最
差的快也不到一倍。而不合格的軟件工程師寫的爛程序糟蹋多核CPU,性能可能下降上
百倍,而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
省錢的。大多數互聯網公司對硬件的要求是穩定就好,不關心性能。而他們自己的軟件
開發部門不停的refactoring,翻修輪子製造工作崗位,才能保證軟件質量和性能。這
樣對於優秀的硬件工程師,跳槽也就一兩家公司競爭offer,而同樣優秀的軟件工程師
會有十幾家或更多公司競爭,包裹... 阅读全帖
d******c
发帖数: 2407
7
你这个引申的结论就不合适了
搞framework,做软件工具的是要发明轮子,因为那是他们的市场,他们要创造市场
但是对软件工程师的需求不是来自于这些被创造的市场,而是来源于软件能做的事情太
多,可能性无限。
硬件也可以做很多,但做个新硬件的成本和限制太多,周期太长,开辟新市场,产生新
产值这方面和软件没法比。软件从开源的开始往加东西,现成的都不需要成本,成本只
有很少的硬件成本,scale起来硬件成本不需要同样放大。硬件你用现成的也得先把硬
件成本算上,而且这个成本是和规模一起放大的。
你要想转CS,就得学习CS的优点,不能只从酸葡萄心理出发,那没有好处。哪怕你真的
认为软件就是靠烂创造市场,那你就该想想你怎么学这一招,也来靠烂创造市场。
另外nginx本来就是俄罗斯人搞的,在一个领域追求性能极致,golang是几个人创造工
具创造市场给自己保住饭碗,你用的更不知道是谁写的自己吹牛用的,跟nginx这样在
市场中证明的肯定没法比。

发帖数: 1
8
NGINX就做得很好啊,给俄国人点赞。软件业就缺像NGINX这样的好项目。不缺各种稀奇
古怪的新语言:golang/rust/scala等等。

发帖数: 1
9
目前发现两大问题:
1. GOGC,关闭Garbage Collection,性能提高20%,无语了,golang不是吹牛GC比JVM
G1强很多么?NGINX不用GC不是照样可以写程序么?
2. 滥用FUTEX,从strace上看,一个HTTP GET引发众多threads拼抢,thundering herd
problem,跟NGINX的SO_REUSEPORT设计完全不同。GO runtime调度需要用futex,众多
goroutines给本来就很脆弱的futex加重负担。
各位大侠,我没学过golang,只花了几天测测http性能,就发现这两个问题,这应该是
设计失误吧?
[pid 29063] <... epoll_wait resumed> [{EPOLLIN|EPOLLOUT, {u32=4228357504,
u64=140170486062464}}], 128, -1) = 1
[pid 29063] futex(0x147c010, FUTEX_WAKE, 1) = 1
[pid 29063] read(6,
[pid 290... 阅读全帖

发帖数: 1
10
golang到目前为止也不支持SO_REUSEPORT,这个至少比NGINX慢5倍。
垃圾GC估计比NGINX慢1倍。多余的goroutine调度再慢上1倍。
algernon建立在golang上,golang在性能设计上有问题,algernon也没办法。
s********k
发帖数: 6180
11
我的意思是实际上运行环境很多事虚拟化的,你把NGINX跑到VM上是不是也会性能下降.
VM肯定性能下降,但是大家(Golang http server 和NGINX)都下降下,你再比较下呢?
?关于去VM倒是又是一个课题。

了。

发帖数: 1
12
Nginx下降更多,都用VM結果是nginx和golang的差距比裸機小,從原來的10倍或100倍
下降到一半或幾倍,可能這就是網上說的golang和c差距不大的原因。去VM性能提高很
多,這也是亞馬遜買CPU公司做硬件的原因。

降.
呢?

发帖数: 1
13
軟件設計太重要了,今天測試golang algernon http server靜態文件性能,比nginx差
了幾十倍以上。在我們硬件CPU領域,別說差幾倍,性能提升5%都叫大改進,可以更新
一代架構了。
這使我對golang寫的多核應用程序性能產生懷疑:一個http server在48核處理器上居
然搞出124個threads,而且沒有pin to core,不識別numa,簡單靜態文件性能還沒有
nginx的零頭多,75% CPU都是idle,有失golang的水準。
這讓我想到了EE工程師的悲哀:世界上硬件CPU公司屈指可數,最牛的CPU公司性能比最
差的快也不到一倍。而不合格的軟件工程師寫的爛程序糟蹋多核CPU,性能可能下降上
百倍,而且還有安全漏洞。所以軟件公司願意多花幾倍的包裹雇用優秀軟件工程師還是
省錢的。大多數互聯網公司對硬件的要求是穩定就好,不關心性能。而他們自己的軟件
開發部門不停的refactoring,翻修輪子製造工作崗位,才能保證軟件質量和性能。這
樣對於優秀的硬件工程師,跳槽也就一兩家公司競爭offer,而同樣優秀的軟件工程師
會有十幾家或更多公司競爭,包裹... 阅读全帖
d******c
发帖数: 2407
14
你这个引申的结论就不合适了
搞framework,做软件工具的是要发明轮子,因为那是他们的市场,他们要创造市场
但是对软件工程师的需求不是来自于这些被创造的市场,而是来源于软件能做的事情太
多,可能性无限。
硬件也可以做很多,但做个新硬件的成本和限制太多,周期太长,开辟新市场,产生新
产值这方面和软件没法比。软件从开源的开始往加东西,现成的都不需要成本,成本只
有很少的硬件成本,scale起来硬件成本不需要同样放大。硬件你用现成的也得先把硬
件成本算上,而且这个成本是和规模一起放大的。
你要想转CS,就得学习CS的优点,不能只从酸葡萄心理出发,那没有好处。哪怕你真的
认为软件就是靠烂创造市场,那你就该想想你怎么学这一招,也来靠烂创造市场。
另外nginx本来就是俄罗斯人搞的,在一个领域追求性能极致,golang是几个人创造工
具创造市场给自己保住饭碗,你用的更不知道是谁写的自己吹牛用的,跟nginx这样在
市场中证明的肯定没法比。

发帖数: 1
15
NGINX就做得很好啊,给俄国人点赞。软件业就缺像NGINX这样的好项目。不缺各种稀奇
古怪的新语言:golang/rust/scala等等。

发帖数: 1
16
目前发现两大问题:
1. GOGC,关闭Garbage Collection,性能提高20%,无语了,golang不是吹牛GC比JVM
G1强很多么?NGINX不用GC不是照样可以写程序么?
2. 滥用FUTEX,从strace上看,一个HTTP GET引发众多threads拼抢,thundering herd
problem,跟NGINX的SO_REUSEPORT设计完全不同。GO runtime调度需要用futex,众多
goroutines给本来就很脆弱的futex加重负担。
各位大侠,我没学过golang,只花了几天测测http性能,就发现这两个问题,这应该是
设计失误吧?
[pid 29063] <... epoll_wait resumed> [{EPOLLIN|EPOLLOUT, {u32=4228357504,
u64=140170486062464}}], 128, -1) = 1
[pid 29063] futex(0x147c010, FUTEX_WAKE, 1) = 1
[pid 29063] read(6,
[pid 290... 阅读全帖

发帖数: 1
17
golang到目前为止也不支持SO_REUSEPORT,这个至少比NGINX慢5倍。
垃圾GC估计比NGINX慢1倍。多余的goroutine调度再慢上1倍。
algernon建立在golang上,golang在性能设计上有问题,algernon也没办法。
s********k
发帖数: 6180
18
我的意思是实际上运行环境很多事虚拟化的,你把NGINX跑到VM上是不是也会性能下降.
VM肯定性能下降,但是大家(Golang http server 和NGINX)都下降下,你再比较下呢?
?关于去VM倒是又是一个课题。

了。

发帖数: 1
19
Nginx下降更多,都用VM結果是nginx和golang的差距比裸機小,從原來的10倍或100倍
下降到一半或幾倍,可能這就是網上說的golang和c差距不大的原因。去VM性能提高很
多,這也是亞馬遜買CPU公司做硬件的原因。

降.
呢?

发帖数: 1
20
来自主题: JobHunting版 - Load balancer: NGINX vs HAproxy vs hardware
大牛们来说说目前流行的load balancing技术来实现restful service层的scale吧:
what's your TPS?
Load balancer: NGINX, HAproxy, hardware or others?
c*******f
发帖数: 378
21
来自主题: JobHunting版 - Load balancer: NGINX vs HAproxy vs hardware
apache should NOT be used as a production load balancer.
nginx is a primitive load balancer for small scales.
haproxy is a true load balancer that's widely used by small to large scale
production loads.
better software load balancers are actually lower level network
loadbalancers, i.e. LVS. this can be used by large to huge scales. the
performance can only be bettered by high end hardware load balancers.
the above are all open source software solutions.
hardware load balancers are all commercial... 阅读全帖
b******y
发帖数: 9224
22
来自主题: StartUp版 - Nginx vs. Apache
有人用过Nginx吗?感觉是不是比Apache要小很多,而且快?
b******y
发帖数: 9224
23
来自主题: StartUp版 - Nginx vs. Apache
网上找到了这个:
At its heart nginx is a fork of apache 1.3 with the multi-processing ripped
out in favor of an event loop (and all the copyright statements removed from
headers, but hey, it's cool).
http://news.ycombinator.com/item?id=518885
M**u
发帖数: 10158
24
来自主题: StartUp版 - Nginx vs. Apache
nginx性能是很强的
b***e
发帖数: 1419
25
来自主题: Programming版 - 大家node都是跑在nginx后面吗?
好像是第一个connect request过reverse proxy, 后面的message和disconnect直接连
,因为socket是在client和node server之间的, 不过nginx.
l**********n
发帖数: 8443
26
来自主题: Programming版 - 大家node都是跑在nginx后面吗?
need set some headers according to documentation of nginx
d*******r
发帖数: 3299
27
来自主题: Programming版 - 大家node都是跑在nginx后面吗?
有无 nginx cluster managing 软件的推荐
w***g
发帖数: 5958
28
软件也是,c的性能被numpy糟蹋,numpy被pandas糟蹋,tensorflow被keras糟蹋,
pandas和keras用的人最多。下里巴人最好找工作。

:軟件設計太重要了,今天測試golang algernon http server靜態文件性能,比nginx
差了幾十倍以上。在我們硬件CPU領域,別說差幾倍,性能提升5%都叫大改進,可以更新
:一代架構了。
s*********y
发帖数: 6151
29
静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是nginx改吧
改吧 你提这种问题没意思的很
g****t
发帖数: 31659
30
Can we put go binary server behind the nginx ?

发帖数: 1
31
就是這種簡單到不行的功能,golang algernon都沒做好,我不是做互聯網的,老闆要
求用各種語言給CPU做benchmark,在golang上就選了algernon,結果性能弱爆了。這個
就像drystone測試,一般都選最簡單的應用。


: 静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是
nginx改吧

: 改吧 你提这种问题没意思的很

w***g
发帖数: 5958
32
可以的,但是该慢还是慢啊。我现在全线从apache2转nginx了。
y*j
发帖数: 3139
33
Apache 的那些project用过几个,每个质量都相当差,印象相对不好。


: 可以的,但是该慢还是慢啊。我现在全线从apache2转nginx了。

d*******o
发帖数: 493
34
go本身就有http.FileServer,为什么要用第三方库。
性能跟nginx相差不大
https://www.reddit.com/r/golang/comments/28so0e/go_networking_performance_vs
_nginx/
S*******n
发帖数: 305
35
algernon 性能比nginx慢几十倍,你就得出golang不行了…… 然后感叹硬件不好混...
.无力吐槽
d******c
发帖数: 2407
36
任何一个功能要做好都没有简单的
这个功能有现成的最好产品,golang根本没有动力去再做一遍,做的只是一个demo,为
了证明说它能做,实际不可能去和人家竞争,根本没有动力,没有资源去做,也没有多
少钱途,因为nginx已经push到极限了,很难有余地做的更好
软件界什么功能往往都有一堆实现,但是大部分都很难没法用,因为随便什么人都可以
开始个项目,但那根本不是产品

发帖数: 1
37
刚刚用了golang official的http benchmark,得到跟algernon同样的结果,说明还是
golang的问题,即使用124个线程,性能也无法达到nginx在48核上98%的占用率,
golang http benchmark只有30%占用率。
https://github.com/golang/benchmarks/blob/master/http/http.go

发帖数: 1
38
为什么我测试的性能差别很大呢,难道哪里搞错了?
我现在用这个:https://github.com/golang/benchmarks/blob/master/http/http.go
48核30k RPS,nginx是400k以上

vs
s********k
发帖数: 6180
39
有几个人能有做出Nginx水平啊,广大人民群众的需求这点少的牛人满足不了啊
d***a
发帖数: 13752
40
如果用golang的syscall包,可以用SO_REUSEPORT吧。OS要支持SO_REUSEPORT。
这个比较对golang不太公平。golang可以做很多事情,nginx专长做web server。
s********k
发帖数: 6180
41
所以说就是golang的这个包并没有做event based loop,还是直接狂开goroutine,所
以肯定比不过专门针对epoll做的IO密集型nginx?

发帖数: 1
42
SO_REUSEPORT是Linux Kernel 3.9里面新加的,可以让多个process共享socket,减少
socket accept上的瓶颈。
golang不支持这个我挺吃惊的。NGINX 1.9就有了。对于业务繁重的HTTP服务器,或者
压力测试,SO_REUSEPORT必不可少。
感觉默认的goroutine blocking工作模式效率比non-blocking event poll低很多,虽
然编程更容易。
难道后端不应该都是non-blocking模式么?还有goroutine概念,给硬件加速带来负担
。不知道各种网卡traffic steering技术对golang有没有效果。
d***a
发帖数: 13752
43
你用的nginx和golang algernon是I/O intensive的workload。如果跑compute
intensive的workload,VM和裸机会很接近。
看起来你们用的硬件,对VM中的I/O部分的支持不好啊,不应该影响这么大。有可能是I
/O虚拟化的硬件支持不好。感觉你们的系统,要调的地方很多,工作量很大。:)

发帖数: 1
c****f
发帖数: 1102
45
现在只有很极致的公司才追求那10%的性能优化 更多的追求实用 短平快
人家根本不care这点区别 再堆机器就是了 机器多少钱 我请人回来弄类似nginx的
memory trick得花多少钱 以后怎么维护? 升级 更新怎么办?
就想之前碰到一个公司 所有的http服务都是in house的 结果碰到H2 自己做的基于LVS
的链接toss back不能用了不说 连H2的功能的prototype都要做好久
但是市场需求就是马上要H2 你怎么办? 只能去掉自己in house的LB
所有在用人成本 今后维护 各方面来说 真的可以追求那最顶点性能优化的公司也就没
几个
现在K8S这么热 大家都网上迁呢 谁在乎调度器和API被干爆了如何 多加几个就是了
w***g
发帖数: 5958
46
软件也是,c的性能被numpy糟蹋,numpy被pandas糟蹋,tensorflow被keras糟蹋,
pandas和keras用的人最多。下里巴人最好找工作。

:軟件設計太重要了,今天測試golang algernon http server靜態文件性能,比nginx
差了幾十倍以上。在我們硬件CPU領域,別說差幾倍,性能提升5%都叫大改進,可以更新
:一代架構了。
s*********y
发帖数: 6151
47
静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是nginx改吧
改吧 你提这种问题没意思的很
g****t
发帖数: 31659
48
Can we put go binary server behind the nginx ?

发帖数: 1
49
就是這種簡單到不行的功能,golang algernon都沒做好,我不是做互聯網的,老闆要
求用各種語言給CPU做benchmark,在golang上就選了algernon,結果性能弱爆了。這個
就像drystone測試,一般都選最簡單的應用。


: 静态文件下载 这种cdn业界早就做烂了 百分之90以上的cdn服务后端都是
nginx改吧

: 改吧 你提这种问题没意思的很

w***g
发帖数: 5958
50
可以的,但是该慢还是慢啊。我现在全线从apache2转nginx了。
1 2 3 4 5 6 7 8 9 10 下页 末页 (共10页)