The app is not even big,but it takes over 5 seconds to reload some pages,i don't think that is normal eventhough I read that laravel is pretty slow,but this is unusable,I've installed debugbar and it is showing that booting takes over 3.5 seconds while loading of the app is over 2.5 seconds,I've been following a course and instructor's app loads instantly,can someone tell me what effects the booting and load time?
Since this is a general question without specific detail here's a general answer:
Your first step should be to install the Laravel debug bar (which you say you have) and then look at the query time or controller time and narrow down the culprit. Based on that, you can ask more pointed questions on StackOverflow with the details of the specific queries that are slow, or if it's a controller that's slow, you can post the contents of that controller file. From there we can make recommendations in terms of what changes you can make.
One other thing to try is on the same machine try out a vanilla Laravel app and see what the baseline load times are. Maybe there's nothing wrong with your app at all and instead it has something to do with whatever is serving it.
Alright,I think I've got it fixed,was using XDebug for PHP lectures for collage and that is why app was running so slowly,so I've disabled it.
If anyone else will have similar problem here is the solution,but be aware that this will disable your xDebug:
Open XAMMP -> Click on config button for Apache -> Open PHP (php.ini).
Inside of that file look for "[xDebug]" and comment out all the commands that enable it ( in front of commands put ";" and space (" ") ) . It should look like this:
; [xDebug]
; zend_extension = C:\xampp\php\ext\php_xdebug-2.9.8-7.2-vc15-x86_64.dll
; xdebug.remote_enable = 1
; xdebug.remote_autostart=on
And then restart the server
If you need xDebug,then check out this post - PHP on Windows with XAMPP running 100 times too slow
Related
when I try to run Jekyll (C(base) cXXX-macpro:website cXXX$ jekyll serve) on my MAC via the terminal, I receive the following output:
Configuration file: /xxx/website/_config.yml
Source: /xxx/website
Destination: /xxx/website/_site
Incremental build: disabled. Enable with --incremental
Generating...
AutoPages: Disabled/Not configured in site.config.
Pagination: Complete, processed 1 pagination page(s)
done in 3.629 seconds.
Auto-regeneration: enabled for '/xxx/website'
Server address: http://127.0.0.1:4000
Server running... press ctrl-c to stop.
Then, when I try to load the Website via the Browser, it takes up to 2-3 minutes (sic!) to load the site. Finally, when the site is loaded and I try to click on the links on this site, it takes again 2-3 minutes to load the respective page.
Can anyone tell me why this is the case and how to solve this problem?
I finally solved the problem, after two weeks of searching for a solution and posting this question yesterday.
I found the solution here: Page loading suddenly super slow #372.
There seems to be a problem with https://gitcdn.xyz/... in the file head.html in the _include folder. Just change the URL to https://gitcdn.link/ and it works!
I'm trying to use sw-precache, but I must be doing something wrong!
I'm mostly using the demo code available from the github repo and can't seem to get updates to the app to come through. Once it's cached the first time, it never checks for new versions.
I was expecting that when I publish a new service worker, the browser would request the new service worker and update the cache accordingly in the background. Then using the registration code in the example, I would be able to prompt the user to refresh and get the latest version from their newly refreshed cache.
Would really appreciate if someone could please point me in the right direction.
Example
To demonstrate the problem, I've created an isolated example here:
https://github.com/stevenocchipinti/sw-precache-demo
The example uses a basic skeleton from create-react-app which has a built in build task which take care of fingerprinting the filenames, etc.
I suspect the problem is with me caching everything by using the following sw-precache config:
{
"staticFileGlobs": [ "build/**/*.*" ],
"stripPrefix": "build/"
}
There are more accurate steps in the repo's readme, but the basic steps I'm taking to reproduce the problem are as follows (with my probably incorrect expectations).
Steps and Assumptions
Browse to the app for the first
I should see Content is now available offline! in the console
Reload the page
The message in the console should not appear again because the service worker is installed, but the page should still work.
Go offline and reload the page
The page should still work
Make a visible change to the source code
Rebuild (run the build task and sw-precache)
This is where my understanding must be wrong
Reload the page
The service worker should update the cache in the background
When its done, you should see New or updated content is available. in the console
The actual visible changes should not be visible until the next reload
Reload the page again
The browser will use the new cache this time around
The changes should be visible now!
There shouldn't be any messages in the console
The problem
Once the app has been cached initially, it will never update unless you unregister the service worker or force a reload.
I'm not sure how to make this work - any help would be greatly appreciated!
After replicating your development hosting environment, I can see that you're serving your service-worker.js file with a browser HTTP cache lifetime of one hour:
There's more information as to why this is leading to the behavior you're seeing, along with best practices, in this previous answer. As mentioned at the top of that answer, browsers plan on changing their behavior to stop honoring the HTTP cache for the service worker file by default, mainly due to the type of confusion that you're experiencing here. For the time being, though, the production versions of both Chrome and Firefox continue to honor those headers.
i am new in laravel. I did worked in codeigniter for more than 40 projects but did not faced any load issue. Now in new project we are working in laravel, where i just setup and checked laravel then it founds that it load some time in first load. Once load then it works ok, but each time when new session is start after open browser then it takes some time approx 2 seconds evenif there is simple hello page. Any suggestion to improve this ?
1- check the console for any errors , maybe there is a loop not closed.
2- second : you can install some debugging packages like
https://github.com/barryvdh/laravel-debugbar
I've got a Laravel app setup locally with (what seems to me) very poor performance as you can see below:
My setup:
W8 on a pretty fast laptop with SSD
XAMPP 3.2.1
Laravel 4.1.*
Clockwork 1.* (only added the controller event as desribed in the docs)
Debug mode true
The scenario described:
A logged in user access a page with a list of prospects : 1216ms
Then the user logs out : 1164ms
Finally the user is redirected to the login page : 1165ms
As you can see in every single request the bottleneck is the "Router Dispatch" event. What can I do to dig further, and most importantly what can I do to improve its duration?
Or maybe because this is a dev environnment these are expected numbers? (I don't believe so, but I might be wrong).
After updating my XAMPP to the latest and Laravel to 4.2, this just got fixed by itself.
I have a really annoying problem with a deployed Grails application on tomcat 7
I created a tool in my website that basically allows the site admin to edit message.properties files so that he can change the messages for a certain language as he desire.
All the changes are saved successfully to the file he edited.
In development, while running the website from STS (Soring Source Tools Suite; somethng like eclips) I just refresh the website in the browser and I see the changes instantly, all the changes that made to the message.properties file for the selected language is taking effect correctly.
But in the deployed application (same code same config no errors) the admin do the same thing, edit the resources in the same way as before, the message.properties file is saved with the new values correctly, but, I dont see the changes in the browser, unless I restarted tomcat, or after number of hours!
I've disabled the tomcat 7 caching, and I still face the same problem.
I've spent more than 4 days googling, but all the results are not related to my problem, and most of them are related to hibernate caching.
So, my question simply is as follows:
I want to go to a message.properties file in my deployed grails application, lets say message_en.properties, change lets say default.welcome.message=Welcome to default.welcome.message=Hello, World!
And then open any browser, and see Hello, World! instead of Welcome
Thanks in advance for any help =')
As they say, some big questions have a very simple answer!
Depending on a post I found, in my resources editor tool, I added this code in my action with other few changes in the bootstarp (see link at the end of the answer):
def messageSource
def saveMessageResources={
.
.
.
//my action logic
.
.
.
messageSource.clearCache()
}
and it worked :)
References: http://jira.grails.org/browse/GPAPPENGINE-44
Deployed application will not pick up changes until you restart it. Changes are reloaded on-thy-fly only in development mode for your convenience. It is called "hot-deployment" because only parts that are changed (messages.properties in your case) are applied.
If you want to edit messages in deployed application you can apply alternative solution - localisation plugin that keeps your messages in database.