Nginx, from connected to first byte

i set up a nginx server with php fastcgi last month, but i found a
little problem with it.
my frontpage is loaded in 8-10 seconds, but there is 7 seconds waste
from the time when connected server, to the time when start to send the
first byte. the real time which is used by the process of connection and
transmission is short, i can’t find a solution, could anybody help me?

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,182805,182805#msg-182805

On Mon, Mar 14, 2011 at 10:09:15AM -0400, digginchina wrote:

Hi there,

i set up a nginx server with php fastcgi last month, but i found a little
problem with it.
my frontpage is loaded in 8-10 seconds, but there is 7 seconds waste from the
time when connected server, to the time when start to send the first byte. the
real time which is used by the process of connection and transmission is short, i
can’t find a solution, could anybody help me?

The debug log will probably show what nginx thinks is happening during
the full 8-10 seconds. Look either side of the 7-second gap to see
whether you are better off examining nginx, the nginx-fastcgi
connection,
or the fastcgi-application interaction.

Good luck with it,

f

Francis D. [email protected]

hi Francis,
thanks a lot for the reply, i disable debug when compile the nginx, need
i re-compile? i don’t know the exact meaning of “debug log”, whether
it’s a general nginx log or another log? and one more question, how to
check the status of nginx-fastcgi connection and the fastcgi-application
interaction?
btw, i use unix file pid to connect fastcgi, could you please tell me
whether this method or network port method is better?
thanks a lot.
regards
solo

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,182805,182963#msg-182963

On 15 Mar 2011 04h05 WET, [email protected] wrote:

hi Francis, thanks a lot for the reply, i disable debug when compile
the nginx, need i re-compile? i don’t know the exact meaning of
“debug log”, whether it’s a general nginx log or another log? and
one more question, how to check the status of nginx-fastcgi
connection and the fastcgi-application interaction? btw, i use unix
file pid to connect fastcgi, could you please tell me whether this
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Do you mean UNIX sockets? There’s no PID involved.

method or network port method is better? thanks a lot. regards
solo

There’s no harm in trying to use TCP sockets.

— appa

On Tue, Mar 15, 2011 at 12:05:52AM -0400, digginchina wrote:

Hi there,

thanks a lot for the reply, i disable debug when compile the nginx, need i
re-compile? i don’t know the exact meaning of “debug log”, whether it’s a general
nginx log or another log?

Debug log: http://nginx.org/en/docs/debugging_log.html

Must be enabled at compile time.

and one more question, how to check the status of nginx-fastcgi connection and
the fastcgi-application interaction?

nginx-fastcgi: nginx is the client, your fastcgi server is the
server. Debug log shows the nginx side; tcpdump or something similar
can show the traffic between the two; and your server may have a “debug”
mode to show its idea of the interaction.

fastcgi-application: your fastcgi server and your application. Maybe
extra sleeps and prints can show what is going on?

btw, i use unix file pid to connect fastcgi, could you please tell me whether
this method or network port method is better?

If the fastcgi server is on a different machine, the network port method
is better because it works.

If nginx and fastcgi are on the same machine, the connection method
shouldn’t matter (much). Unix sockets should be better from an
access-control view. But there are suggestions on this list recently
that the combination of “sendfile on” and unix sockets on at least one
OS has problems with largish uploads.

The two options seem close enough to me, that if your testing doesn’t
show a good reason to pick one over the other, then choose either and
don’t worry about it.

Good luck with it,

f

Francis D. [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs