Grunt tasks are slow in yeoman application - ruby-on-rails

I have an angular project build with yeoman, talking to a rails api backend.
Everything works fine, except that grunt tasks are very slow.
When I run grunt server --verbose:
Execution Time (2014-01-15 13:37:55 UTC)
loading tasks 14.3s ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 26%
server 1ms 0%
preprocess:multifile 11ms 0%
clean:server 13ms 0%
concurrent:server 34.3s ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 63%
autoprefixer 1ms 0%
autoprefixer:dist 369ms ▇ 1%
connect:livereload 17ms 0%
watch 5.8s ▇▇▇▇▇▇▇▇▇ 11%
Total 54.8s
Some of my Gruntfile:
'use strict';
module.exports = function (grunt) {
require('time-grunt')(grunt);
require('load-grunt-tasks')(grunt);
require('time-grunt')(grunt);
grunt.initConfig({
...
});
grunt.loadNpmTasks('grunt-preprocess');
grunt.registerTask('server', function (target) {
if (target === 'dist') {
return grunt.task.run(['build', 'connect:dist:keepalive']);
}
grunt.task.run([
'preprocess:multifile',
'clean:server',
'concurrent:server',
'autoprefixer',
'connect:livereload',
'watch'
]);
});
grunt.registerTask('test', [
'clean:server',
'concurrent:test',
'autoprefixer',
'connect:test'
//'karma'
]);
grunt.registerTask('build', [
'preprocess:multifile',
'clean:dist',
'useminPrepare',
'concurrent:dist',
'autoprefixer',
'concat',
'copy:dist',
'cdnify',
'ngmin',
'cssmin',
'uglify',
'rev',
'usemin'
]);
grunt.registerTask('default', [
'jshint',
'test',
'build'
]);
};
Size of project:
vagrant#vm ~code/myapp/app/scripts
$> find -name "*.js" | xargs cat | wc -l
10209
I am running on MacOS 10.8 with i7 processor, 16GB ram, SSD... It is normal that is takes so long ? What makes the grunt task (and especially "loading tasks") so slow ?
Note: I am ssh'd inside a vagrant machine and running the grunt commands from there. If I run the grunt command on my native system, it's much faster (loading tasks takes 1.6s instead of 14.3).
So the shared filesystem might be an issue. But why...

I had exactly same problem with Vagrant and Yeomans angular-generator. After running grunt serve it took almost 30 seconds to compile sass, restart server etc.
I already used NFS but it was still slow. Then I tried jit-grunt, just-in-time grunt loader. I replaced load-grunt-tasks with jit-grunt and everything is now a lot faster.
Here's a good article about JIT-Grunt:
https://medium.com/written-in-code/ced193c2900b

I am using grunt inside a Vagrant virtualbox. (ubuntu 12.04). My native files are on my host machine (OSx). Because the grunt tasks are io-intensive, and they are run through file sharing, this make them quite slow.
This can be improved by adding nfs to Vagrant (http://docs.vagrantup.com/v2/synced-folders/nfs.html). This will make Vagrant share files with nfs instead of the default Vagrant file sharing. It will be a bit faster, but not much.
For comparison, on my machine:
For running the subtask loading grunt tasks
natively: 1.2s
with nfs: 4s
vagrant file sharing: 16s
If only a specific task is taking a lot of time, this specific task might be the problem. To troubleshoot, use time-grunt: https://npmjs.org/package/time-grunt.

I've had issues as well, and have found:
nospawn: true
To be the fastest option. I went from ~20s to ~1s to concat, minify, and uglify JS.

I had the same problem with Yeoman's ngbp generator and Vagrant. Even with nfs, a simple change on a template took about 30s to be seen in the browser.
Using jit-grunt caused time to be reduced to 10s. After using spawn:false, even though there was no reduction at the first load, changes took less than 1s (0.086s) to propagate to the browser! (Yes!)
The changes I've made to Gruntfile.js:
I commented all the grunt.loadNpmTasks but grunt.loadNpmTasks('grunt-contrib-watch') [That's because of a task rename ngbp does later on];
I added require('jit-grunt')(grunt); after grunt.loadNpmTasks('grunt-contrib-watch');
I added spawn: false to delta: { options: {livereload: true, spawn: false} ...}.

Related

Deploying smart contract using truffle on private blockchain node on docker

I am facing problems deploying a smart contract on my private blockchain network. I created my blockchain network on three VMs (miners) using puppeth on a fourth VM (controller) by following the steps in this blog: https://medium.com/#collin.cusce/using-puppeth-to-manually-create-an-ethereum-proof-of-authority-clique-network-on-aws-ae0d7c906cce
Afterwards, I installed truffle on one of the miners VMs and i initialized truffle using the command:
truffle init
Then I wrote a simple hello world smart contract, compiled it and deployed it on truffle development blockchain and it worked. However, I tried to deploy it on my private blockchain but I can't connect to the network.
The admin.nodeInfo command in geth console returns the folowing output:
docker exec -it 954cd3955065 geth attach ipc:/root/.ethereum/geth.ipc
Welcome to the Geth JavaScript console!
instance: Geth/v1.9.25-unstable-ead81461-20201123/linux-amd64/go1.15.5
coinbase: 0xe8cc4bea2cfdfd14cddefe1141bedd109576b9a9
at block: 78558 (Tue Dec 01 2020 22:01:02 GMT+0000 (UTC))
datadir: /root/.ethereum
modules: admin:1.0 clique:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0
To exit, press ctrl-d
> admin.nodeInfo
{
enode: "enode://7206ca3c62f6db47e1230dcf14a765d4c9b4870a66470dbb21fcc5ed2fab2167d6bcc47eec8044c42037b3e6e0017aeb8ddfc3580471da54a6c7274a0c1fe46b#10.100.2.32:30303",
enr: "enr:-Je4QGXlVAESp8r2s1uHBJxoDLWQo8IvZsbe5sX2YRBb0un9Gdlt8nfDKQBR_j0lDPtaoCCuis4cJJlqtEHfa4tLO2EIg2V0aMfGhG5b-B6AgmlkgnY0gmlwhApkAiCJc2VjcDI1NmsxoQNyBso8YvbbR-EjDc8Up2XUybSHCmZHDbsh_MXtL6shZ4N0Y3CCdl-DdWRwgnZf",
id: "027a351994ac1b127df56180b6210310cc0164f17f1b12c167cb167c4ffaa122",
ip: "10.100.2.32",
listenAddr: "[::]:30303",
name: "Geth/v1.9.25-unstable-ead81461-20201123/linux-amd64/go1.15.5",
ports: {
discovery: 30303,
listener: 30303
},
protocols: {
eth: {
config: {
byzantiumBlock: 0,
chainId: 1515,
clique: {...},
constantinopleBlock: 0,
eip150Block: 0,
eip150Hash: "0x0000000000000000000000000000000000000000000000000000000000000000",
eip155Block: 0,
eip158Block: 0,
homesteadBlock: 0,
istanbulBlock: 0,
petersburgBlock: 0
},
difficulty: 98201,
genesis: "0x17f752387c901db617cf0594ecd2cb9811dfcd666318c2e0e7cb0239471da979",
head: "0xf8a37d0390558746901faa55463c127c553f02cf2d23ce0cb469fcd470c810f9",
network: 1515
}
}
}
I tried adding the network configuration in truffle-config.js like this:
devnet2: {
host: "localhost",
port: "30303", //port where the node is
network_id: "*",
from: 0x91cd7b879fefff34259d577a56d290b3315bf9b3 // Treats this network as if it was a public net. (default: false)
}
then, when deploying using the command truffle deploy --network devnet2 i always get this error:
Compiling your contracts...
===========================
> Everything is up to date, there is nothing to compile.
/usr/local/lib/node_modules/truffle/build/webpack:/packages/provider/index.js:56
throw new Error(errorMessage);
^
Error: There was a timeout while attempting to connect to the network.
Check to see that your provider is valid.
If you have a slow internet connection, try configuring a longer timeout in your Truffle config. Use the networks[networkName].networkCheckTimeout property to do this.
at Timeout.setTimeout (/usr/local/lib/node_modules/truffle/build/webpack:/packages/provider/index.js:56:1)
at ontimeout (timers.js:436:11)
at tryOnTimeout (timers.js:300:5)
at listOnTimeout (timers.js:263:5)
at Timer.processTimers (timers.js:223:10)
I tried extending the timeout limit but it didn't work. I also tried using Web3 Providers (HTTPProvider and IPCProvider) but without any luck (i can give more details, if needed).
Any help is well appreciated because i spent a lot of time on it without getting anywhere. Unfortunately, i couldn't find anything on deploying smart contracts to a node that is running on docker. If needed, i can gladly give more details about what i did.
I managed to run smart contracts on a private network, not using docker however. Some things come to mind. did you run a miner on your network? you will need to run a miner so that the contract gets migrated. Did you make sure that the gaslimit is met when running the contract? the miners will wait for the max gas limit to be reached before processing any request.
Did you already deploy the contract? in the migration scripts you either create a new migration script by bumping the version or use the reset flag to run all migration scripts again.

ChromeHeadless giving timeout when running GitLab CI pipeline with Docker Centos 7.5 image

So I am trying to run Karma tests for an Angular 6 application on a docker image with Centos 7.5 using a pipeline for GitLab CI.
The problem is
30 08 2018 07:09:55.222:WARN [launcher]: ChromeHeadless have not
captured in 60000 ms, killing.
30 08 2018 07:09:55.244:INFO [launcher]: Trying to start ChromeHeadless again (1/2).
30 08 2018 07:10:55.264:WARN [launcher]: ChromeHeadless have not captured in 60000 ms, killing.
30 08 2018 07:10:55.277:INFO [launcher]: Trying to start ChromeHeadless again (2/2).
30 08 2018 07:11:55.339:WARN [launcher]: ChromeHeadless have not captured in 60000 ms, killing.
30 08 2018 07:11:55.355:ERROR [launcher]: ChromeHeadless failed 2 times (timeout). Giving up.
ERROR: Job failed: exit code 1
I run the tests with ng test --browsers ChromeHeadlessNoSandbox --watch=false --code-coverage
Karma conf :
browsers: ['Chrome', 'ChromeHeadlessNoSandbox'],
customLaunchers: {
ChromeHeadlessNoSandbox: {
base: 'ChromeHeadless',
flags: [
'--no-sandbox',
'--disable-setuid-sandbox',
'--disable-gpu',
'--remote-debugging-port=9222',
],
},
},
Also on the Image the docker file I install the latest chrome stable:
RUN wget https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm
RUN yum -y localinstall google-chrome-stable_current_x86_64.rpm && yum clean all
Do you have any idea about why its giving timeout? In the local environment, it runs perfectly.
I have resolved the same issue. My test suits runs perfectly in my local machine but when running these tests in a docker container, it fails due to connection timeout. (i'm using Gitlab runner also, and My docker image is based on circleci/node:8.9.2-browsers)
After investigating this issue, i found that the chrome bin variable path was missed in the docker file. so i fixed the issue by adding:
export CHROME_BIN=/usr/bin/google-chrome
to my .gitlab-ci.yml in before_script
# TESTING
unit_test_client:
stage: test
before_script:
- export CHROME_BIN=/usr/bin/google-chrome
script:
- npm run test:client
You can also fix your issue by setting the CHROME_BIN by
process.env.CHROME_BIN='/usr/bin/google-chrome' in the top of your karma config file.
In this case, you need to handle the case that you are running the test in your local machine, probably it should match the same chrome path
We had the same issue and resolved it by adding the following flag in the karma.config.js
headlessChrome: {
base: "ChromeHeadless",
flags: [
"--no-sandbox",
"--no-proxy-server",
"--disable-web-security",
"--disable-gpu",
"--js-flags=--max-old-space-size=8196", // THIS LINE FIXED IT!!!
],
You might want to check the console output before Karma attempts to launch the browser. I got stuck for hours on constant timeouts when there were invalid import paths in my Angular application. Karma prints such errors in the console but continues by launching the browsers as if the errors had no importance. This is a bit misleading, but worth checking before blaming the browsers.
Second, machine performance: Every once in a while you might get a timeout at the first launch attempt, but the next attempt will then liekly succeed. Dockerization might decrease your performance, but not much. A headless Chrome should run fast even with minimal setup.
If your browser would not be installed or addressable, then there should be some output regarding that as well.
Hi i solved this issue this way:
In my case the client had a proxy-blocker to manage the networking configurations. So i provided the proxy as server in the customLauncher flag and works perfectly, but only in the pipeline, locally the tests stopped. but it's just take off the proxy that runs locally.
Before: This way the tests runs locally, but do not works in the jenkins pipeline (npm run test)
browsers: ['MyChromeHeadless'],
customLaunchers: {
MyChromeHeadless: {
base: 'ChromeHeadless',
flags: [
'--no-sandbox',
'--proxy-auto-detect'
]
}
}
After: This way the tests runs in the pipeline, but do not works locally cuz i'm not under the client networking with access to the proxy provied, if you are, should work.
browsers: ['MyChromeHeadless'],
customLaunchers: {
MyChromeHeadless: {
base: 'ChromeHeadless',
flags: [
'--no-sandbox',
'--proxy-bypass-list=*',
'--proxy-server=http://proxy.your.company'
]
}
}

CouchDB 1.3.1 on Centos 6.4

I compiled CouchDB and installed. It seems to work great except when I use views on the database, then it just spins the wheel and nothing happens and the cpu load spikes to 100% and slowly it eats away all memory and starts to swap a lot which in return increases the cpu load.
I have tried both with the js-1.70-12 that comes with centos 6.4, as well as build and install my own js-1.85-1. All erlang packages are installed from epel :
erlang-crypto-R14B-04.2.el6.x86_64
erlang-syntax_tools-R14B-04.2.el6.x86_64
erlang-mnesia-R14B-04.2.el6.x86_64
erlang-ssl-R14B-04.2.el6.x86_64
erlang-cosProperty-R14B-04.2.el6.x86_64
erlang-asn1-R14B-04.2.el6.x86_64
erlang-cosEventDomain-R14B-04.2.el6.x86_64
erlang-eunit-R14B-04.2.el6.x86_64
erlang-erl_docgen-R14B-04.2.el6.x86_64
erlang-toolbar-R14B-04.2.el6.x86_64
erlang-debugger-R14B-04.2.el6.x86_64
erlang-tools-R14B-04.2.el6.x86_64
erlang-typer-R14B-04.2.el6.x86_64
erlang-megaco-R14B-04.2.el6.x86_64
erlang-oauth-1.1.1-1.el6.x86_64
erlang-stdlib-R14B-04.2.el6.x86_64
erlang-hipe-R14B-04.2.el6.x86_64
erlang-kernel-R14B-04.2.el6.x86_64
erlang-runtime_tools-R14B-04.2.el6.x86_64
erlang-snmp-R14B-04.2.el6.x86_64
erlang-public_key-R14B-04.2.el6.x86_64
erlang-inets-R14B-04.2.el6.x86_64
erlang-ibrowse-2.2.0-4.el6.x86_64
erlang-cosEvent-R14B-04.2.el6.x86_64
erlang-cosNotification-R14B-04.2.el6.x86_64
erlang-edoc-R14B-04.2.el6.x86_64
erlang-otp_mibs-R14B-04.2.el6.x86_64
erlang-cosFileTransfer-R14B-04.2.el6.x86_64
erlang-cosTransactions-R14B-04.2.el6.x86_64
erlang-inviso-R14B-04.2.el6.x86_64
erlang-jinterface-R14B-04.2.el6.x86_64
erlang-erl_interface-R14B-04.2.el6.x86_64
erlang-diameter-R14B-04.2.el6.x86_64
erlang-gs-R14B-04.2.el6.x86_64
erlang-tv-R14B-04.2.el6.x86_64
erlang-appmon-R14B-04.2.el6.x86_64
erlang-odbc-R14B-04.2.el6.x86_64
erlang-wx-R14B-04.2.el6.x86_64
erlang-et-R14B-04.2.el6.x86_64
erlang-observer-R14B-04.2.el6.x86_64
erlang-sasl-R14B-04.2.el6.x86_64
erlang-dialyzer-R14B-04.2.el6.x86_64
erlang-common_test-R14B-04.2.el6.x86_64
erlang-os_mon-R14B-04.2.el6.x86_64
erlang-examples-R14B-04.2.el6.x86_64
erlang-compiler-R14B-04.2.el6.x86_64
erlang-erts-R14B-04.2.el6.x86_64
erlang-xmerl-R14B-04.2.el6.x86_64
erlang-orber-R14B-04.2.el6.x86_64
erlang-cosTime-R14B-04.2.el6.x86_64
erlang-ssh-R14B-04.2.el6.x86_64
erlang-docbuilder-R14B-04.2.el6.x86_64
erlang-percept-R14B-04.2.el6.x86_64
erlang-parsetools-R14B-04.2.el6.x86_64
erlang-ic-R14B-04.2.el6.x86_64
erlang-pman-R14B-04.2.el6.x86_64
erlang-webtool-R14B-04.2.el6.x86_64
erlang-test_server-R14B-04.2.el6.x86_64
erlang-reltool-R14B-04.2.el6.x86_64
erlang-R14B-04.2.el6.x86_64
erlang-mochiweb-1.4.1-5.el6.x86_64
Every thing configures and makes and installs as expected. You can dump data into the database, you can create documents and all that. But I can not run any view, temporary or not.
The only error I see in the logs is like this one, and it is a lot of these errors :
[Sun, 18 Aug 2013 23:10:38 GMT] [error] [<0.124.0>] {error_report,<0.30.0>,
{<0.124.0>,crash_report,
[[{initial_call,
{mochiweb_socket_server,init,['Argument__1']}},
{pid,<0.124.0>},
{registered_name,[]},
{error_info,
{exit,eaddrinuse,
[{gen_server,init_it,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[couch_secondary_services,couch_server_sup,
<0.31.0>]},
{messages,[]},
{links,[<0.93.0>]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,987},
{stack_size,24},
{reductions,459}],
[]]}}
But I have no idea what they mean.
Do I need to compile and install erlang as well ? All the above packages or just erlang ?
Your compilation and installation looks fine. At least your error (note: eaddrinuse in traceback) is about that there is some process that listens same address and port as your CouchDB try to. Check other listening processes with netstat -anp command or change CouchDB's listen port to different.

live reload not working after upgrading yo grunt-cli bower

I Just built Nodejs and installed 0.10.6 then uninstalled yo+grunt-cli+bower+generator-webapp and reinstalled to latest using npm -g,
yo webapp
But now live reload doesnt work, cant see any errors either in chrome devtools
yo -v: 1.0beta5
grunt-cli v0.1.8 and grunt v0.4.1
bower -v: 0.9.2
node -v: 0.10.6
npm -v: 1.2.18
grunt server shows the watch task: time + the name of file changed
tried : changing the port number in Gruntfile to.. LIVERELOAD_PORT = 34729; nogo :(
my older webapp projects still work fine
Lost..
Thanks
--------------------- UPDATE
1. moved lrSnippet to 1st position in Grunfile.js
2. in index.js moved
end.call(res, res.data, encoding);
outside the if Block
Now it works Partially :
summary :
1. changes to index.html > reloads ok
2. changes to main.scss > reloads ok
3. changes to my.sass > Not OK
after 3rd step
1. changes to index.html > Not OK
2. changes to main.scss > Not OK
4. changes to hello.coffe > Not OK
After step 4
1. changes to index.html > ok
2. changes to main.scss > ok
//------------------------------------- index.html
Changes to index.html
reload ok
grunt server window logs change and issues reload command
grunt server window grab =
Running "watch" task
Waiting...OK
>> File "app/index.html" changed.
Running "watch" task
... Reload app/index.html ...
Completed in 0.002s at Sat May 18 2013 12:47:58 GMT+0530 (IST) - Waiting...
//------------------------------------- main.scss
Changes to main.scss
reload ok
grunt server window grab =
>> File "app/styles/main.scss" changed.
Running "compass:server" (compass) task
overwrite .tmp/styles/main.css
unchanged app/styles/my.sass
Running "watch" task
Completed in 1.906s at Sat May 18 2013 12:48:24 GMT+0530 (IST) - Waiting...
OK
>> File ".tmp/styles/main.css" changed.
Running "watch" task
... Reload .tmp/styles/main.css ...
Completed in 0.002s at Sat May 18 2013 12:48:24 GMT+0530 (IST) - Waiting...
//------------------------------------- my.sass
changes to my.sass
reload not ok (not reloading)
grunt server window grab =
Running "watch" task
Waiting...OK
>> File "app/styles/my.sass" changed.
Running "compass:server" (compass) task
unchanged app/styles/main.scss
unchanged .tmp/images/generated/design-s65ab268e46.png
overwrite .tmp/styles/my.css
Running "watch" task
Completed in 0.602s at Sat May 18 2013 13:00:19 GMT+0530 (IST) - Waiting...
//-------------------------------------
After the my.sass is changed
changes made to index.html or main.scss r not shown in grunt server window
the Watch command doesnt log anything.
changes r not reloaded
//-------------------------------------
Restarted Grunt Server
//------------------------------------- hello.coffee
grunt server window grab =
OK
>> File "app/scripts/hello.coffee" changed.
Running "coffee:dist" (coffee) task
File .tmp/scripts/hello.js created.
Running "watch" task
Completed in 0.011s at Sat May 18 2013 13:34:56 GMT+0530 (IST) - Waiting...
//-------------------------------------
There is a bug with the current livereload/yo setup. Here are the details alongside a fix for the problematic dependency (connect-livereload).
https://github.com/yeoman/generator-webapp/issues/63
Three things which you can make sure to diagnose the issue further.
Make sure you're on the latest version npm update -g yo
You shouldn't be using LiveReload plugin explicitly, it conflicts with Yeoman watch command while running
Your port (in gruntfile.js) might be using by some other process, try to exit from the terminal, change the port and it see it works or not.
The problem is yeoman doesn't change the port automatically in the current version, that's where it stopped working if you close it forcefully in the current terminal session.
The same issue has been discussed here - https://github.com/yeoman/yeoman/issues/938
If you still see the issue then try to run the following command and past the output here.
yo --version && echo $PATH $NODE_PATH && node -e 'console.log(process.platform, process.versions)' && cat Gruntfile.js
A commit was made to solve this problem.
https://github.com/yeoman/generator-webapp/pull/67
We'll see an update soon I guess.
in the meantime what you can do is modify your Gruntfile.js. Look near the line 61 for the connect option for livereload and replace the configuration for this snippet.
livereload: {
options: {
middleware: function (connect) {
return [
lrSnippet,
mountFolder(connect, '.tmp'),
mountFolder(connect, yeomanConfig.app)
];
}
}
},
Also, is a good idea to update the module connect-livereload to 0.1.4.
Just run npm install connect-livereload on your project directory.
I added live reload as an option under watch in the Gruntfile.js:
watch: {
options: {
nospawn: true,
livereload: true
},
Setting the livereload:port instead of livereload:options:port worked for me:
livereload: {
port: 35728
}

Phantomjs loads pages slowly

I'm new into phantomjs, trying it on a standard centOS server (with httpd etc installed, but no modified settings apart from nameservers set to 8.8.8.8 and 8.8.4.4).
I'm using the default loadspeed.js file (be it renamed). However, page speeds appear to be extremely slow. Here's an example:
$ phantomjs phantomjs.js http://www.google.com/
starting
Loading time 90928 msec
$ phantomjs phantomjs.js http://173.194.67.138/ #(one of google's public ips)
starting
Loading time 30204 msec
When I load any url on the server (such as http://something.be ), loadtime is 141msec:
$ phantomjs phantomjs.js http://something.be
starting
Loading time 141 msec
Does anyone have a clue what causes my connection to be this slow? The connection itself is fine, wget takes seconds to download a file of several MB.
Also, when I run the exact same script on OSX locally for Google, this is the output:
phantomjs phantomjs.js http://google.com/
starting
Loading time 430 msec
Found it - seems like ipv6 was the culprit.
I disabled it temporarily by running the following:
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6
Testing confirms:
$ phantomjs phantomjs.js http://google.com
starting
Loading time 230 msec
Well, in my case, the page was waiting for some GET requests and was not able to reach the requests' server and it kept waiting for long. I could only figure it out when i used the remote debugger option.
phantomjs --remote-debugger-port=9000 loadspeed.js <some_url>
and inside the loadspeed.js file
page.onResourceRequested = function (req) {
console.log('requested: ' + JSON.stringify(req, undefined, 4));
};
page.onResourceReceived = function (res) {
console.log('received: ' + JSON.stringify(res, undefined, 4));
};
and then loading localhost:9000 in any webkit browser (safari/chrome) and seeing the console logs where i could figure out it was waiting for some failed requests for a long time.
TO BYPASS THIS - REDUCE THE TIMEOUT:
page.settings.resourceTimeout = 3000; //in secs
and things were very quick after that. Hope this helps

Resources