First thank you for all the members of this great community.
I have some awkward problem. This page http://www.tophebergeur.com/hebergement/perl/ has TTFB of more than 40 seconds.
These are the info from http://www.webpagetest.org/result/150625_AS_188H/1/details/
Error/Status Code: 200
Client Port: 2034
Request Start: 0.426 s
DNS Lookup: 367 ms
Initial Connection: 59 ms
Time to First Byte: 34765 ms
Content Download: 21 ms
Bytes In (downloaded): 14.2 KB
Bytes Out (uploaded): 0.4 KB
But when I filter this list by country the problem of TTFB is gone /hebergement/perl/canada/
I was looking in the server logs but couldn't find where is the problem
Thanks in advance
The problem has been solved. Apparently it was a problem of Cache. I'M using CDN that failed to load the cache of this page. THank you all. And I apprecited your help :)
Related
Attempting to open the JBoss EAP 7.3 admin console ends with blank white page with no errors in cmd terminal window.
Steps I did:
unzip jboss-eap-7.3.0.zip
run c:\AppServers\jboss-eap-7.3\bin\add-user.bat
update admin user and enter valid password
start local server c:\AppServers\jboss-eap-7.3\bin\standalone.bat
open http://127.0.0.1:9990/console/index.html
result blank page
DevTools Console output
hal-0.js:10804 GET http://127.0.0.1:9990/management 401 (Unauthorized)
hal-0.js:10803 GET http://127.0.0.1:9990/keycloak/adapter/wildfly-console 404 (Not Found)
hal-0.js:10811 11:30:43.262 ERROR o.j.h.c.b.endpoint.EndpointManager Keycloak adapter 'http://127.0.0.1:9990/keycloak/adapter/wildfly-console' doesn't exist - status: 404
hal-0.js:5706 POST http://127.0.0.1:9990/management 401 (Unauthorized)
hal-0.js:10811 11:30:43.281 ERROR o.j.h.c.bootstrap.HalBootstrapper Bootstrap error: Authentication required.
DevTools Network panel output
index.html 304 document Other 95 B 8 ms
polyfill.min.js 200 script index.html (memory cache) 0 ms
external.min.js 200 script index.html (memory cache) 0 ms
hal.nocache.js 200 script index.html (memory cache) 0 ms
hal.min.css 200 stylesheet index.html (disk cache) 5 ms
BD3BC5E1B9793E31D587DA5F8EC8FBDE.cache.js 200 script hal.nocache.js:10 (disk cache) 36 ms
OpenSans-Regular-webfont.woff2 200 font hal.min.css (memory cache) 0 ms
management 401 xhr hal-0.js:10804 429 B 4 ms
worker.js 200 javascript Other (disk cache) 2 ms
favicon.ico 200 x-icon Other (disk cache) 2 ms
wildfly-console 404 xhr hal-0.js:10803 206 B 3 ms
pouchdb.min.js 200 javascript worker.js:16 (disk cache) 3 ms
management 401 xhr hal-0.js:5706 773 B 4 ms
Same steps in home environment don't cause any issues.
I don't have any GET requests to keycloak/adapter/wildfly-console
I can open jboss console and login as admin.
The difference highly likely is in corporate security setup.
And I have to know exactly what to ask security department. Could you give me any idea what to look for?
i have a Ubuntu 16.04.5 server with Vesta CP.
I checked the server on https://dnsflagday.net, and I got this report:
domain.cl. #123.456.78.90 (ns1.domain.cl.): dns=ok edns=ok edns1=ok edns#512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=timeout optlist=ok
domain.cl. #123.456.78.90 (ns2.domain.cl.): dns=ok edns=ok edns1=ok edns#512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=timeout optlist=ok
I do not know what edns512tcp = timeout means and I have not had much luck looking for a solution on internet.
Can someone help me? thanks
For that tool, any kind of "timeout" error is a problem, it means some server did not reply or the message (either query or reply) was eaten by some active element on the path, so it needs to be fixed.
edns512tcp is when the testing software does an EDNS query with a buffer of 512 bytes and over TCP.
If you go to https://ednscomp.isc.org/ednscomp/ for your domain you will have the full test results.
For that specific error it is:
EDNS - over TCP Response (edns#512tcp)
dig +vc +nocookie +norec +noad +edns +dnssec +bufsize=512 dnskey zone #server
expect: NOERROR
expect: OPT record with version set to 0
See RFC5966 and See RFC6891
So you can see which DNS query was done with dig, that you can reproduce it (+vc is an old flag name that is an alias for +tcp). The test expects to get a NOERROR code back and an OPT record. Your servers did not reply at all, so the test failed.
It seems that your servers did not reply to that at all, which is wrong. Maybe they do not reply to TCP queries at all which is even more wrong. In all cases you will need to contact the entity responsible for maintaining those servers and point it to the test results so that they start to fix the problem.
thanks for your help.
I read more about it and I could detect that port 53 was being blocked by the firewall, I added the rule to the firewall to allow TCP connections on port 53.
Everything it's fine now
I've been searching and testing for days now without any rational explanation for the following to happen:
I have a mail server which serves all our users and everyone is happily running on IMAP/POP3 access. I need to develop a utility to check POP3 e-mail and started getting errors retrieving mail. I set up the same pop account on my outlook and windows live mail and they couldn't download the e-mails either. I tried another PC and it downloaded just fine. After much debugging and searching, I found out that after sending the RETR command, there wasn't an "+OK" response on my pc but there was on the other pc. So I went down to telnet and sure as day my PC wasn't getting the +OK response on RETR, just the actual mail but I was getting it from every other pc I tried. I even booted up my win XP virtual pc and it has the same result as my pc. Here is an excerpt of the logs from mine and my test pc:
RETR with +OK:
+OK Welcome to MailEnable POP3 Server
USER devtest#x.com
+OK
PASS <Removed>
+OK
LIST
+OK 3 26743
1 2118
2 23949
3 676
.
UIDL
+OK
1 BE1F75CAE417453581CF11F16CF09989
2 846882DB63B54C9E91C4643AA5CCA1F5
3 A7BAFC28B04A493689A150F6D4CD7FD0
.
RETR 1
+OK 2118 octets
Received: from x ([x.x.60.10]) by x.net with MailEnab
le ESMTP; Sun, 28 Dec 2014 11:30:16 +0200
RETR with +OK missing:
+OK Welcome to MailEnable POP3 Server
USER devtest#x.com
+OK
PASS <Removed>
+OK
LIST
+OK 3 26743
1 2118
2 23949
3 676
.
UIDL
+OK
1 BE1F75CAE417453581CF11F16CF09989
2 846882DB63B54C9E91C4643AA5CCA1F5
3 A7BAFC28B04A493689A150F6D4CD7FD0
.
RETR 1
Received: from x ([x.x.60.10]) by x.net with MailEnab
le ESMTP; Sun, 28 Dec 2014 11:32:53 +0200
I'm now going to place another hard drive in my pc and install windows and telnet client and see what it does but I was hoping someone might have had some experience with this. It's only that one time that the +OK is missing, every other command has it showing as well as it being there on every other PC I try it on so it's only on my pc that it's missing.
Appreciate any thoughts or assistance!
Well loading a new hard drive worked perfectly as expected which led me to the fact that it must be something installed on my pc itself. Disabled the usual suspects (firewall and AV) and when that didn't work, I proceeded to close down every app running on my pc which possibly works with Ports and eventually narrowed the culprit down to the Fortinet VPN Client running on my PC. I don't have it's AV component enabled so I'm rather at a loss as to how it could be the reason for a single line on port 110 to go missing but if it's running then the +OK line is missing and if it's shut down then it appears.
I'm going to leave this question here in case it can help someone else and will also try post something to Fortinet as well.
we're running centos/cPanel on a good size dedicated server with only one website. we need speed and ability to upload files under 'nobody'. that means suPHP and DSO are out. so the php handler is mod_fcgid. from time to time apache error logs will show mod_fcgid: read data timeout in 40 seconds. we assume it means mod_fcgid is not properly configured when installed using easyapache.
after reading up on g about how to fix we found two tidbits. one deals with MPM. the other, surprisingly, shows how to increase the timeout response (normally increasing timeout response is bad thing as there is something worse inside the server).
should we use MPM event, prefork, and/or worker with mod_fcgid? we currently have prefork configured.
if we do increase the timeout should we use the following settings:
IPCConnectTimeout 20
ProcessLifeTime 120
IdleTimeout 60
IdleScanInterval 30
MaxRequestsPerProcess 499
MaxProcessCount 100
OR
FcgidProcessLifeTime 8200
FcgidIOTimeout 8200
FcgidConnectTimeout 400
FcgidMaxRequestLen 1000000000
And if we do use either of these settings where should they be set: 1) in php.fcgi script, or 2) FastCGI configuration in Apache.
My tested solution, same issue
target config file :
/usr/local/apache/conf/includes/pre_virtualhost_global.conf
target value :
FcgidIOTimeout
applying changes :
/scripts/rebuildhttpdconf
/etc/init.d/httpd restart
reference :
https://wiki.mikejung.biz/Fcgid#FcgidMaxRequestLen
/etc/apache2/mods-enable/fcgid.conf
*/mods-available/fcgid.conf
*/sites-enable/site.com.vhost
<IfModule mod_fcgid.c>
AddHandler fcgid-script .fcgi
IdleTimeout 300
BusyTimeout 300
ProcessLifeTime 7200
IPCConnectTimeout 300
IPCCommTimeout 7200
</IfModule>
I'm running Dancer and found it slow -- pages took a long time to render.
This is the example code from Dancer::Introduction:
#!/usr/bin/perl
# make this script a webapp
use Dancer;
# declare routes/actions
get '/' => sub {
"Hello World";
};
get '/hello/:name' => sub {
"Hello ".param('name');
};
# run the webserver
Dancer->dance;
It takes my browser 10 seconds to get&render the response( using firebug in firefox ).
And Dancer message:
[20734] core #0.000228> request: GET / from 192.168.1.101 in /usr/lib/perl5/site_perl/5.8.8/Dancer/Handler.pm l. 57
[20734] core #0.000809> [hit #44]trying to match `/' against /^\/$/ in /usr/lib/perl5/site_perl/5.8.8/Dancer/Route.pm l. 84
[20734] core #0.000953> [hit #44] --> got 1 in /usr/lib/perl5/site_perl/5.8.8/Dancer/Route.pm l. 101
[20734] core #0.001645> [hit #44]response: 200 in /usr/lib/perl5/site_perl/5.8.8/Dancer/Handler.pm l. 175
[20734] core #0.000135> request: GET /favicon.ico from 192.168.1.101 in /usr/lib/perl5/site_perl/5.8.8/Dancer/Handler.pm l. 57
[20734] core #0.000873> [hit #45]response: 200 in /usr/lib/perl5/site_perl/5.8.8/Dancer/Handler.pm l. 175
Why is Dancer so slow? Did I miss something?
Is the computer connected to internet? I got the same problem when testing from a computer not connected to internet; fixed it by deleting
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js" type="text/javascript"></script>;
from main.tt
As you can see from the debugging log, it took Dancer 0.6ms to serve the request. The problem is somewhere else in the stack. A frequent culprit is reverse DNS — the webserver tries to reverse-lookup the remote IP address for access logging purposes, and if your DNS is misconfigured, that can take quite a while (sometimes 30 or 60 seconds) before it fails.
Use Dancer::Plugin::NYTProf to profile your application. From the documentation:
By simply loading this plugin, you'll have the detailed, helpful
profiling provided by Devel::NYTProf.
Each individual request to your app is profiled. Going to the URL
/nytprof in your app will present a list of profiles.
Or, if it's a browser-side issue, you can use an extension like Firebug to see what part of a page load is slow.