I have a small VUE project with 25 entries which is created by vue-cli.
During the development, when HMR is on, the rebuild time is about 10s now.
I use --profile --progress to start webpack-dev-server and the output is as following:
webpack: Compiling...
308ms building modules
50ms sealing
0ms optimizing
0ms basic module optimization
6ms module optimization
3ms advanced module optimization
53ms basic chunk optimization
0ms chunk optimization
0ms advanced chunk optimization
0ms module and chunk tree optimization
0ms chunk modules optimization
1ms advanced chunk modules optimization
13ms module reviving
0ms module order optimization
5ms module id optimization
6ms chunk reviving
3ms chunk order optimization
10ms chunk id optimization
44ms hashing
5ms module assets processing
76ms chunk assets processing
39ms additional chunk assets processing
0ms recording
418ms additional asset processing
0ms chunk asset optimization
8396ms asset optimization
95% emitting
DONE Compiled successfully in 9512ms
+ 52 hidden assets
[466] (webpack)/hot nonrecursive ^\.\/log$ 170 bytes {5} [built]
[] -> factory:1ms dependencies:0ms = 1ms
[499] ./node_modules/moment/locale ^\.\/.*$ 2.88 kB {5} [optional] [built]
[] -> factory:0ms building:0ms dependencies:1ms = 1ms
[1048] ./src/module/user/userCredit/userCredit.vue 1.57 kB {7} [built]
[] -> factory:0ms building:1ms dependencies:5318ms = 5319ms
[1050] ./node_modules/css-loader?{"minimize":false,"sourceMap":false}!./node_modules/vue-loader/lib/ style-compiler?{"vue":true,"id":"data-v-4eeb260f","scoped":true,"hasInlineConfig":false}!./node_modules/sass-loader/lib/loader.js?{"sourceMap":false}!./node_modules/ sass-resources-loader/lib/loader.js?{"resources":"/Users/linxi/Develop/maitao/h5-refactor/src/common/scss/variables.scss"}!./node_modules/vue-loader/lib/ selector.js?type=styles&index=0!./src/module/user/userCredit/userCredit.vue 4.01 kB {7} [built]
[] -> factory:0ms building:0ms dependencies:1ms = 1ms
[1060] ./node_modules/babel-loader/lib!./node_modules/vue-loader/lib/selector.js?type=script&index=0!./src/module/user/userCredit/userCredit.vue 5.69 kB {7} [built]
[] -> factory:1ms building:44ms dependencies:14ms = 59ms
[1061] ./node_modules/vue-loader/lib/ template-compiler?{"id":"data-v-4eeb260f","hasScoped":true,"transformToRequire":{"video":"src","source":"src","img":"src","image":"xlink:href"},"buble":{"transforms":{}}}!./ node_modules/vue-loader/lib/selector.js?type=template&index=0!./src/module/user/userCredit/userCredit.vue 3.15 kB {7} [built]
[] -> factory:1ms building:58ms = 59ms
+ 1156 hidden modules
I have no idea what's going on during asset optimization phase.
Is there any options that can reveal the inner procedures?
Thanks.
I am a bit late to the party but I debugged it with webpackers ProfilingPlugin https://webpack.js.org/plugins/profiling-plugin/. You enable it quickly by suppling these flags --plugin webpack/lib/debug/ProfilingPlugin
Related
I run an action two times, and the second time takes very little time to run, so I suspect that spark automatically cache some results. But I did find any source.
Im using Spark1.4.
doc = sc.textFile('...')
doc_wc = doc.flatMap(lambda x: re.split('\W', x))\
.filter(lambda x: x != '') \
.map(lambda word: (word, 1)) \
.reduceByKey(lambda x,y: x+y)
%%time
doc_wc.take(5) # first time
# CPU times: user 10.7 ms, sys: 425 µs, total: 11.1 ms
# Wall time: 4.39 s
%%time
doc_wc.take(5) # second time
# CPU times: user 6.13 ms, sys: 276 µs, total: 6.41 ms
# Wall time: 151 ms
From the documentation:
Spark also automatically persists some intermediate data in shuffle operations (e.g. reduceByKey), even without users calling persist. This is done to avoid recomputing the entire input if a node fails during the shuffle. We still recommend users call persist on the resulting RDD if they plan to reuse it.
The underlying filesystem will also be caching access to the disk.
Time to first byte on www.netdyrlaege.dk is really big.
This is unfortunately an issue that is beyond my skills.
I have optimized everything as well as possible and now I get on only one F webpagetest.org
The TimeToFirstByte is crazy large!
I'm on a virtual private server, bought a big one, it is not a server issue.
No, it is something within Joomla. I've been able to reduce loading times from up to 12 seconds to something like from 3-5 seconds. That is still not okay.
I tried Joomla debug and here are these results. AfterDispatch is from 0.7 to 1.8 seconds depending on the browser! What is this and why?
How do I fix this?
Profile information
Application 0.001 seconds (+0.001); 1.34 MB (+1.336) - afterLoad<br>
Application 0.075 seconds (+0.075); 10.53 MB (+9.196) - afterInitialise<br>
Application 0.162 seconds (+0.087); 23.64 MB (+13.113) - afterRoute<br>
Application 0.747 seconds (+0.585); 34.98 MB (+11.336) - afterDispatch<br>
Application 0.808 seconds (+0.061); 37.29 MB (+2.309) - beforeRenderModule <br>mod_customerswhobought (Customers Who Bought...)<br>
Application 0.815 seconds (+0.007); 37.35 MB (+0.062) - afterRenderModule mod_customerswhobought (Customers Who Bought...)
Application 0.819 seconds (+0.004); 37.36 MB (+0.013) - beforeRenderModule mod_vm_prod_cat_full (Butik menu all left)
Application 1.065 seconds (+0.247); 37.51 MB (+0.141) - afterRenderModule mod_vm_prod_cat_full (Butik menu all left)
Application 1.065 seconds (+0.000); 37.51 MB (+0.007) - beforeRenderModule mod_vm_s5_column_cart_AJAX (Kurv med billeder)<br>
Application 1.426 seconds (+0.360); 47.91 MB (+10.393) - afterRenderModule mod_vm_s5_column_cart_AJAX (Kurv med billeder)<br>
Application 1.427 seconds (+0.001); 47.90 MB (-0.010) - beforeRenderModule mod_breadcrumbs (breadcrumbs)<br>
Application 1.432 seconds (+0.005); 47.94 MB (+0.041) - afterRenderModule mod_breadcrumbs (breadcrumbs)<br>
Application 1.433 seconds (+0.002); 47.93 MB (-0.004) - beforeRenderModule mod_vm_prod_cat_full (Butik menu all)<br>
Application 1.646 seconds (+0.213); 47.98 MB (+0.050) - afterRenderModule mod_vm_prod_cat_full (Butik menu all)<br>
Application 1.647 seconds (+0.001); 47.99 MB (+0.011) - beforeRenderModule mod_menu (Top Menu)<br>
Application 1.653 seconds (+0.006); 48.15 MB (+0.154) - afterRenderModule mod_menu (Top Menu)<br>
Application 1.654 seconds (+0.000); 48.06 MB (-0.085) - beforeRenderModule mod_virtuemart_mini_cart (mini kurv)<br>Application 1.658 seconds (+0.004); 48.08 MB (+0.021) - afterRenderModule mod_virtuemart_mini_cart (mini kurv)<br>
Application 3.524 seconds (+1.866); 49.01 MB (+0.927) - afterRender<br>
On
first of all disable debug on your site: end-users will question the stability of the site and attackers gain plenty of info.
In order to achieve optimization you should:
perform all configuration tasks that will allow you to gain speed (mainly, setup and use cache properly!)
see the modules in the debug list, and ensure they use cache; load the page twice and see if at least the second time it loads under one sec.
(Now you should be down to 1 second rendering time)
Then, the tough part begins:
examine your site's debug, and identify the plugins slowing down the site. The modules are already listed;
starting from the slowest, ponder if you can live without it, or get your hands on the code and fix it;
(Now you should be down to 100 - 300 ms)
configure the server to perform optimally
evaluate external cache solutions
(Now you should be below 50ms)
The more you optimize, the harder it will be to obtain substantial results. I bet I could get you down to 200ms in less than 3 hours, but then it would take days to get to 20ms.
And don't forget this is just rendering time, you also might want to optimize your page, you're using many libraries, making many calls that can be saved, graphics could be combined... and that's affecting the speed too.
Your site's homepage currently runs 900 queries in the homepage. This is way more than you need, there must be some pretty poorly optimized extensions there.
I have used Yslow and PageSpeed to find the cause, but I can't seem to figure out why my blog http://www.fotokringarnhem.nl sometimes loads blazing fast (cached files I guess), and other times takes about 10 seconds or longer to load.
I am on a shared server, but haven't had problems like this with other websites on shared servers.
I'm using cloudflare to speed up my blog to speed things up, but to no avail.
Am I missing something?
Pingdom reports of last 30 days (also see http://stats.pingdom.com/hseaskprwiaz):
Response time average: 7.620 ms
Slowest Average: 18.307 ms
Fastest Average: 4.237 ms
Uptime: 96,24%
Edit 1:
from basicstate.com
diagnostics
+dns
+connect
-request
-response
So I guess it fails on the requests. Options to narrower it down?
Edit 2:
I used P3 (Plugin Performance Profiler) to determine which plugins caused the most loadtime. Turns out that User Access Manager caused about 60% of load time, so I deleted it.
This did something, I now get way less time outs, but it still takes a long time for anything to popup on the screen.
I used the plugin SQL monitor and determined there are 82 queries being executed on request which takes about 10 seconds!!!!
If you have a static site with not millions of users and performance is highly variable, your host is probably to blame. I have tried about 8 different hosts and researched a dozen others, I highly suggest Media Temple (mt). Best customer service and performance you can get for the money.
Also, check out a speed test tool by WP Engine: http://speed.wpengine.com/ - great insight into why your site is slow. Takes a few hours to generate a report.
Use the P3 plugin
and use this article to further optimize your website: http://andbreak.com/articles/guide-speed-wordpress/
when all else fails, try switching providers
Edit
Turns out that deleting all automatically saved backups of pages and post as well as the concepts was the key. This dramatically cuts my query time to the server.
Now at lightning speeds!
Here is the report from the last few days:
uptime: 99,21%
overall average: 3.322 ms
There is a usefull plugin for WP to also limit the number of autosaves and concepts for posts and pages: Revision control
Results weren't instant by the way. Took a day to take effect.
Basicstate results (clearly showing the improvement when I deleted the revisions and concepts on the 11th of 12th (not sure which)).
date uptime dns connect request ttfb ttlb
2012-09-18 98.97 0.031 0.047 0.047 0.353 0.475
2012-09-17 100.00 0.031 0.047 0.047 0.389 0.810
2012-09-16 100.00 0.029 0.045 0.045 0.342 0.499
2012-09-15 93.81 0.029 0.045 0.045 0.739 1.035
2012-09-14 98.97 0.053 0.068 0.068 0.387 0.565
2012-09-13 100.00 0.058 0.074 0.074 0.499 0.853
2012-09-12 95.00 0.030 0.046 0.046 5.994 7.024
2012-09-11 96.97 0.051 0.096 0.096 9.707 9.949
2012-09-10 73.15 0.027 0.043 0.043 6.765 6.952
2012-09-09 43.48 0.027 0.121 0.121 3.652 3.724
2012-09-08 31.82 0.028 0.045 0.045 2.757 2.867
2012-09-07 71.93 0.026 0.042 0.042 5.917 6.091
2012-09-06 60.49 0.027 0.043 0.043 4.590 4.751
I'm somewhat newbie for WEB development based on JVM stack, but future project will require specifically some JVM-based WEB engine. So I started looking on some ground to make things quickly and turned to try Grails. Things looked good from the book, but beeing impressed by really long startup time (grails run-app) I decided to test how this works under load. Here it is:
test app: follow few instruction here to make it from ground (takes 2 mins assuming you already have Grails and Tomcat installed):
_http://grails.org/Quick+Start
test case (with Apache benchmark - comes with Apache httpd - _http://httpd.apache.org):
ab.exe -n 500 -c _http://localhost:8080/my-project/book/create
(Note: this is just displays 2 input fields within styled container)
hardware: Intel i5 650 (4Core*3.2GHz) 8GB Ram & Win Server 2003 x64
The result is ..
Grails: 32 Req/Sec
Total transferred: 1380500 bytes
HTML transferred: 1297500 bytes
Requests per second: 32.45 [#/sec] (mean)
Time per request: 308.129 [ms] (mean)
Time per request: 30.813 [ms] (mean, across all concurrent requests)
Transfer rate: 87.51 [Kbytes/sec] received
(Only 32 Req/Sec with 100% of CPU saturation, this is a way too below my expectations for such hardware)
... Next - i tried to compare it for example with similar dummy JSF application (i took one here: _http://www.ibm.com/developerworks/library/j-jsf2/ - look for "Source code with JAR files", there is \jsf-example2\target\jsf-example2-1.0.war inside),
test case: ab.exe -n 500 -c 10 _http://localhost:8080/jsf/backend/listing.jsp
The result is ..
JSF: 400 Req/Sec
Total transferred: 5178234 bytes
HTML transferred: 5065734 bytes
Requests per second: 405.06 [#/sec] (mean)
Time per request: 24.688 [ms] (mean)
Time per request: 2.469 [ms] (mean, across all concurrent requests)
Transfer rate: 4096.65 [Kbytes/sec] received
... And finally goes raw dummy JSP (just for reference)
Jsp: 8000 req/sec:
<html>
<body>
<% for( int i = 0; i < 100; i ++ ) { %>
Dummy Jsp <%= i %> </br>
<% } %>
</body>
</html>
Result:
Total transferred: 12365000 bytes
HTML transferred: 11120000 bytes
Requests per second: 7999.90 [#/sec] (mean)
Time per request: 1.250 [ms] (mean)
Time per request: 0.125 [ms] (mean, across all concurrent requests)
Transfer rate: 19320.07 [Kbytes/sec] received
...
Am i missing something? ... and Grails app can run much better?
PS: I tried profiling my running Grails app with VisualVM, but got endless loop of messages like ...
Profiler Agent: Redefining 100 classes at idx 0, out of total 413
...
Profiler Agent: Redefining 100 classes at idx 0, out of total 769
...
And finally app just stopped working after few mins - so, looks like profiling Grails is no the choice for good diagnose.
Update - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
First of all I have to admin, yes i need to RTFM - i.e. 'grails run-app' is not the correct way to run Grails for performance measurement. After compiling WAR and deploying it to Tomcat performance is not that awfully low - it is just low. The metrics below are for concurrency of 1 user (I just wanted to check what is MAX performance of the framework in one thread and with no heavy load) and while reading other related posts here i came to "http://stackoverflow.com/questions/819684/jsf-and-spring-performance-vs-poor-jsp-performance" and decided to check Apache Wicket mentioned there - its performance is also included.
Use case is:
- ab.exe -n 500 -c 1 _http://localhost:8080/...
- server is Tomcat7 in vFabric tcServer Dev edition with 'insight' running on background
---------------------- tcServer Plain Tomcat 7 -c 10
/Grails/book/create 77 req/sec 130 req/sec 410 req/sec
/jsf/backend/listing.jsp 133 req/sec 194 req/sec 395 req/sec
/wicket/library/ 870 req/sec 1400 req/sec 5300 req/sec
So ... anyway there is something wrong with Grails. I have made some profiling using tcServer (thanks Karthick) - it looks like it is able only to trace 'Spring-based' actions and internal stacktrace for Grails is like following (for 2 requests - note: metrics are not stable - i bet accuracy of tcServer far from beeing perfect, but can be used just for inforamtion)
Total (81ms)
Filter: urlMapping (32ms)
-> SimpleGrailsController#handleRequest (26ms)
-> Render view "/book/create" (4ms)
Render view "/layouts/main.gsp" (47ms)
Total (79ms)
Filter: urlMapping (56ms) ->
-> SimpleGrailsController#handleRequest (4ms)
-> Render view "/book/create" (38ms)
Render view "/layouts/main.gsp" (22ms)
PS: it may happen that the root cause for bad performance in Grails are underlying 'Spring' libs, will check this in more details.
Are you running it with run-app?
http://grails.org/Deployment states:
"Grails should never be deployed using the grails run-app command as this sets Grails up in "development" mode which has additional overheads. "
try deploying your sample app to tomcat. grails run-app is for development only.
in which environment did you start the app? prod? dev?
do you use scaffolding?
i've tried it on my machine (core i7-2600k). a login page with 4 input fields, dynamic layouts and some other things. i've got 525 requests per second in the slower dev environment.
Yeah this is a benchmark by someone who doesn't know alot about grails or his environment; first he is running on Windows know for being bad at resource management which is why most web serves/app serves run in Linux environments.
Second, if he is using 'ab' to benchmark, then he doesn't have his proxy cache setup because after the first hit, the remainder of the hits would be cached and the he is now benchmarking his cache from my understanding of his setup.
So this all just looks like the benchmarking of a bad setup and a poor understanding of Grails. No offense intended.
Im wondering how the performance of th ESI module is nowadays? I've read some posts on the web that ESI performance on varnish were actually slower than the real thing.
Say i had a page with over 3500 esi includes, how would this perform? is esi designed for such usage?
We're using Varnish and ESI to embed sub-documents into JSON documents. Basically a response from our app-server looks like this:
[
<esi:include src="/station/best_of_80s" />,
<esi:include src="/station/herrmerktradio" />,
<esi:include src="/station/bluesclub" />,
<esi:include src="/station/jazzloft" />,
<esi:include src="/station/jahfari" />,
<esi:include src="/station/maximix" />,
<esi:include src="/station/ondalatina" />,
<esi:include src="/station/deepgroove" />,
<esi:include src="/station/germanyfm" />,
<esi:include src="/station/alternativeworld" />
]
The included resources are complete and valid JSON responses on their own. The complete list of all stations is about 1070. So when the cache is cold and a complete station list is the first request varnish issues 1000 requests on our backend. When the cache is hot ab looks like this:
$ ab -c 100 -n 1000 http://127.0.0.1/stations
[...]
Document Path: /stations
Document Length: 2207910 bytes
Concurrency Level: 100
Time taken for tests: 10.075 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 2208412000 bytes
HTML transferred: 2207910000 bytes
Requests per second: 99.26 [#/sec] (mean)
Time per request: 1007.470 [ms] (mean)
Time per request: 10.075 [ms] (mean, across all concurrent requests)
Transfer rate: 214066.18 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 11 7.3 9 37
Processing: 466 971 97.4 951 1226
Waiting: 0 20 16.6 12 86
Total: 471 982 98.0 960 1230
Percentage of the requests served within a certain time (ms)
50% 960
66% 985
75% 986
80% 988
90% 1141
95% 1163
98% 1221
99% 1229
100% 1230 (longest request)
$
100 rec/sec doesn't look that good but consider the size of the document. 214066Kbytes/sec oversaturates a 1Gbit interface well.
A single request with warm cache ab (ab -c 1 -n 1 ...) shows 83ms/req.
The backend itself is redis based. We're measuring a mean response time of 0.9ms [sic] in NewRelic. After restarting Varnish the first request with a cold cache (ab -c 1 -n 1 ...) shows 3158ms/rec. This means it takes Varnish and our backend about 3ms per ESI include when generating the response. This is a standard core i7 pizza box with 8 cores. I measured this while being under full load. We're serving about 150mio req/month this way with a hitrate of 0.9. These numbers suggest indeed that the ESI-includes are resolved in serial.
What you have to consider when designing a system like this is 1) that your backend is able to take the load after a Varnish restart when the cache is cold and 2) that usually your resources don't expire all at once. In case of our stations they expire every full hour but we're adding a random value of up to 120 seconds to the expiration header.
Hope that helps.
This isn't first-hand, but I'm led to believe that Varnish's current ESI implementation serialises include requests; i.e., they're not concurrent.
If that's the case, it would indeed suck for performance in the case you mention.
I'll try to get someone with first-hand experience to comment.
Parallel ESI requests are available in the **commercial** version of varnish: https://www.varnish-software.com/plus/parallel-esi/. The parallel nature of the fragment requests apparently makes the assembly of a page comprised of multiple fragments faster.
(this would be a comment but I have insufficient reputation to do that)