On Wednesday 15 February 2006 5:24 am, redhat wrote:
> Well, it looks like it might be a DNS issue or at least a routing issue
> after all. I hit the phpinfo page on the server from home (completely
> different ISP) and it loaded like I thought it should have - very fast -
> even for phpinfo. I g
On Tue, 2006-02-14 at 17:35 -0800, Micah Stevens wrote:
> On the server, you can use Dig - it's a pretty good DNS tool. On windows you
> can use nslookup I think.
>
> -Micah
>
> On Tuesday 14 February 2006 8:07 am, redhat wrote:
> > On Tue, 2006-02-14 at 18:06 +1030, David Robley wrote:
> > >
On the server, you can use Dig - it's a pretty good DNS tool. On windows you
can use nslookup I think.
-Micah
On Tuesday 14 February 2006 8:07 am, redhat wrote:
> On Tue, 2006-02-14 at 18:06 +1030, David Robley wrote:
> > Micah Stevens wrote:
> > > Not enough information there to make any sor
On Tue, 2006-02-14 at 18:06 +1030, David Robley wrote:
> Micah Stevens wrote:
>
> >
> > Not enough information there to make any sort of diagnosis, but here are
> > some things to try to narrow down the problem:
> >
> > 1) ssh into the server, and run 'top' to watch the process list. Then
> > wh
Micah Stevens wrote:
>
> Not enough information there to make any sort of diagnosis, but here are
> some things to try to narrow down the problem:
>
> 1) ssh into the server, and run 'top' to watch the process list. Then
> while watching that, hit reload in the browser to see if the HTTP process
Not enough information there to make any sort of diagnosis, but here are some
things to try to narrow down the problem:
1) ssh into the server, and run 'top' to watch the process list. Then while
watching that, hit reload in the browser to see if the HTTP process pegs out
while you're waiting