Thanks for your opinion .
grigori
But from 10 years ago , I use MySQL through socks and i didn't even has 1 bug .

Dennis
I don't think the problem is related to the connection type .

c2h5oh
You are right , sockets has a huge performance different from the TCP.

I hope to hear Jérôme answer soon .

Thanks ,
M.A.G

It is intriguing to me, why should we not use unix sockets?

Boyko

On Jun 16, 2010, at 3:22 PM, c2h5oh wrote:

> Well, I'd rather use sockets - I have experienced quite noticeable
> performance degradation if I don't.
>

Yeah - I was told sockets aren't an issue on modern systems but definitely had issues in the past...

I still use tcp because of that and never changed... I wanted to look into sockets instead but haven't had time and I haven't ever really had issues with tcp. So if it ain't broke...

On Jun 16, 2010, at 4:45 AM, "Dennis J." <djacobfeuerborn@gmail.com> wrote:

> On 06/16/2010 11:21 AM, grigori wrote:
>>
>> On 14 июн, 15:48, "M.A.G"<nginx-fo...@nginx.us> wrote:
>>
>>
>>> solotuions fail when our server go understress .
>>>
>>
>>> [error] 17863#0: *3161531 connect() to unix:/tmp/php-fpm.socket failed (11: Resource temporarily unavailable) while connecting to upstream, client: 94.99.125.115, server: XXXX, request: "GET /vb/u295.html HTTP/1.1", upstream: "fastcgi://unix:/tmp/php-fpm.socket:", host: "XXXX", referrer: "XXXX"
>>>
>> DO NOT use unix sockets on Linux. For MySQL as well.
>> There were enough discussions and explanations why.
>>
> Have these been documented in the FAQ in the wiki then? I've not been part of these discussions and I'd like to know what the actual problem with unix sockets is.
>
> Regards,
> Dennis

On 16 июн, 20:38, Michael Shadle <mike...@gmail.com> wrote:
> Yeah - I was told sockets aren't an issue on modern systems but definitely had issues in the past...

Here is a discussion between Igor Sysoev and Andrei Nigmatulin:
http://translate.googleusercontent.com/translate_c?hl=ru&ie=UTF-8&sl=auto&tl=en&u=http://www.lexa.ru/nginx-ru/msg18577.html&prev=_t&rurl=translate.google.com&twu=1&usg=ALkJrhhpoOFhf39sMIMwG0nuPhb3kz_LHQ

chek follow-ups - translation from Russian by google, but readable

regarding Mysql, I donno, there were complains and reports on the more
stable work with tcp

On Wed, Jun 16, 2010 at 12:45 PM, grigori <grigori.kochanov@gmail.com> wrote:

> Here is a discussion between Igor Sysoev and Andrei Nigmatulin:
> http://translate.googleusercontent.com/translate_c?hl=ru&ie=UTF-8&sl=auto&tl=en&u=http://www.lexa.ru/nginx-ru/msg18577.html&prev=_t&rurl=translate.google.com&twu=1&usg=ALkJrhhpoOFhf39sMIMwG0nuPhb3kz_LHQ
>
> chek follow-ups - translation from Russian by google, but readable

From 2008 though. It's middle of 2010... is this still an issue?

(Note: I trust Igor and Andrei's opinions very much - but technology
does change)

On 16.06.2010 23:45, grigori wrote:
>
> On 16 июн, 20:38, Michael Shadle <mike...@gmail.com> wrote:
>> Yeah - I was told sockets aren't an issue on modern systems but definitely had issues in the past...
>
> Here is a discussion between Igor Sysoev and Andrei Nigmatulin:
> http://translate.googleusercontent.com/translate_c?hl=ru&ie=UTF-8&sl=auto&tl=en&u=http://www.lexa.ru/nginx-ru/msg18577.html&prev=_t&rurl=translate.google.com&twu=1&usg=ALkJrhhpoOFhf39sMIMwG0nuPhb3kz_LHQ

This doesn't look very impressive to me.
You can always increase your backlog setting (that's exactly what listen.backlog controls) -
and voila! problem solved.

Got any other explanations?

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP

On Wednesday 16 June 2010 21:29:15 Antony Dovgal wrote:
> On 16.06.2010 23:45, grigori wrote:
> > On 16 июн, 20:38, Michael Shadle <mike...@gmail.com> wrote:
> >> Yeah - I was told sockets aren't an issue on modern systems but
> >> definitely had issues in the past...
> >
> > Here is a discussion between Igor Sysoev and Andrei Nigmatulin:
> > http://translate.googleusercontent.com/translate_c?hl=ru&ie=UTF-8&sl=auto
> > &tl=en&u=http://www.lexa.ru/nginx-ru/msg18577.html&prev=_t&rurl=translate
> > .google.com&twu=1&usg=ALkJrhhpoOFhf39sMIMwG0nuPhb3kz_LHQ
>
> This doesn't look very impressive to me.
> You can always increase your backlog setting (that's exactly what
> listen.backlog controls) - and voila! problem solved.
>
> Got any other explanations?

Setting a backlog to appropriate value is absolutely necessary thing for every
trafficked site.

However unix socket problem in subject can't be solved this way. Increase of a
backlog only decreases number of EAGAIN errors, not eliminates them
completely.

This is because tcp support re-transmission of packets, while unix is not. So
when the backlog is full (spike of web requests, for example) on unix socket
connect(2) will fail immediately giving 502 to user, while on tcp it will
retry till success or timeout. Which is more practical solution to me.


--
Andrei Nigmatulin
GPG PUB KEY 6449830D

Now I lay me down to sleep(3)
Pray the OS my core to keep
If I die before I wake
Pray the Disk my core to take

On 17.06.2010 01:03, Andrey Nigmatulin wrote:
> Setting a backlog to appropriate value is absolutely necessary thing for every
> trafficked site.
>
> However unix socket problem in subject can't be solved this way. Increase of a
> backlog only decreases number of EAGAIN errors, not eliminates them
> completely.
>
> This is because tcp support re-transmission of packets, while unix is not. So
> when the backlog is full

That's it, that's what I'm talking about.
If I set it to a value high enough, the backlog won't overflow.
Therefore, problem will be solved.

>(spike of web requests, for example) on unix socket
> connect(2) will fail immediately giving 502 to user, while on tcp it will
> retry till success or timeout. Which is more practical solution to me.

It is.
But I'd still like to see more arguments against unix sockets, this one doesn't impress me much.

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP

> But I'd still like to see more arguments against unix sockets, this one doesn't impress me much.

Afaik it's the only one - under heavy load unix sockets are less
reliable than tcp.

2010/6/17 c2h5oh <maciej.lisiewski@gmail.com>:
>> But I'd still like to see more arguments against unix sockets, this one doesn't impress me much.
>
> Afaik it's the only one - under heavy load unix sockets are less
> reliable than tcp.

I'd say that under heavy load, you'll better have to separate your
services on different servers. In this case, there is no more
discution on unix vs tcp.

LOL .
My topic got converted into TCP VS Sockets discussion .
I want to see your tests to use php-fpm under stress with Socks or TCP .
Best Regards ,
M.A.G

Please paste a dump your sysctl
Also please run ulimit commands and verify limits for all users. I
want to see output pastes.


On Jun 16, 10:44 pm, "M.A.G" <nginx-fo...@nginx.us> wrote:
> LOL .
> My topic got converted into TCP VS Sockets discussion .
> I want to see your tests to use php-fpm under stress with Socks or TCP .
>
> Best Regards ,
> M.A.G
>
> Posted at Nginx Forum:http://forum.nginx.org/read.php?3,97959,99203#msg-99203

Also, run ab and report what the request level saturation point is
when the fpm socket dies. In case suggestions or recommendations are
made you can track positive or negative performance.

Wouldn't hurt to also report on free mem during the ab and paste the
results.

On Jun 16, 10:44 pm, "M.A.G" <nginx-fo...@nginx.us> wrote:
> LOL .
> My topic got converted into TCP VS Sockets discussion .
> I want to see your tests to use php-fpm under stress with Socks or TCP .
>
> Best Regards ,
> M.A.G
>
> Posted at Nginx Forum:http://forum.nginx.org/read.php?3,97959,99203#msg-99203

Sorry for digging up the topic.

M.A.G, any solution to the problem?

I have the same config (and same mistakes).