My website is build with Laravel and for the most part, works perfectly fine. However, there is an occasional issue where the website comes to a complete stop and page loading takes almost 5+ minutes. I have had this issue previously and it was because there was page on the website that was performing a loop of thousands and thousands of queries depending on what the user inputted into a form. If the user entered the number 5,000 then the page would perform 5,000 queries. Once I fixed that then everything was working perfectly again. I have my suspicion that something similar has happened again however I'm having trouble pinpointing exactly what could be causing it.
Is there anything that I can do, site-wise, to monitor this and help me locate the issue? Perhaps there is something that can be done on the operating system itself (I'm using Ubuntu)? It would be great if there was some monitoring system that allowed me to see which pages took the longest to complete all of its queries to the database.
Thank you.
If you want to track all queries/events/errors for all users with traces etc. then maybe
Laravel Telescope
is what you want. It is an UI for inspecting and debugging everything in Laravel. If your Laravel version is above 5.7.7 you can install it right away
Related
Evening All,
At by absolute wits end and hoping someone may be able to save me! I am in the process of migrating a number of PHP applications into Azure. I am using:
Linux based App Service running PHP 7.4 (2 vCPUs, 8Gb RAM) at a cost of £94 a month.
Azure Database on MySQL 8.0 (2 vCPUs) at £114 a month.
My PHP apps run well, decent load time of under 1 second per page. Wordpress performance however is awful. I am going from a 1 second page load to around 10 seconds, particularly on the back end. I have read all of the Azure guides and have implemented the following obvious points:
Both the App Service and the MySQL install are in the same data center
App Service is set to 'Always On'
Connection Redirection is set to Preferred and tested as working
The same app runs fine on a very basic £10 or so a month shared hosting package. I have also tried the same setup in Amazon Web Services today and page load is back to a second or so.
In Chrome Console, the delay is in TTFB. I have disabled all the plugins and none stand out as making a huge difference. Each adds a second or so page load, suggesting to me a consistent issue when a page requires a number of database calls.
What is going on with Azure and the awful Wordpress performance?! Is there anything else I can investigate or try? Really keen to stay with Azure but can't cope with the huge increase in cost for a performance hit.
The issue turned out to be the way the file system runs in the app service. It is NOT an issue with the database. The App Service architecture is just too slow at present with file read/writes, of which Wordpress uses a lot. Investigated the various file cache options but none improved enough.
Ended up setting up a fairly basic, and significantly cheaper, virtual machine, running with the same database and performance is hugely improved.
Not a great answer, but App Services are not up to Wordpress at present!
The comments below are correct. The "problem" is the database. You can either move MySQL to a Virtual Machine (which will give you a better performance) or you can also try to use cache plugins such as WP Super Cache as well decrease the number of requests.
You can find a full list of tips in the following link:
https://azure.microsoft.com/en-us/blog/10-ways-to-speed-up-your-wordpress-site-on-azure-websites/
PS: ignore the date, it's still relevant
I have a website (wordpress) published and it works perfectly, but from time to time it gets stuck. You try to enter the page and the server is like blocked, processing, and then for some minutes the website doesn't load.
I even added a cache system and performance optimizations, and the website is much faster now, but that keeps happening, from time to time (several times per day) the web is white, blank, loading for a long time.
I don't know what it is: a plugin? my code? it doesn't happen at a specific moment or action. So I can't identify when or where or why it happens.
So, can I somehow log the php code to know what is being executed at that moment? Where is the code stuck?
BTW, I already disabled the wp-cron. That's not it. And the web is huge so I can't start looking into every file for a loop or something, I need something faster.
I recommend checking on some query monitor which plugins / themes are responsible for the bottleneck. You can use GoDaddy's P3 Profiler plugin, which although it is not having updates, remains one of the best options for profiling a WordPress.
If you use cPanel, check the resource usage and try to identify patterns. For example, is the site slow at a specific time? On specific days of the week?
If you have access to Awstats or similar, you can check if there is any bot that accesses your site at some specific time.
If you treat only the symptom (slowness) you will continue to have the same problem. You need to find the source and then solve it at once.
Also check the access logs for detecting anomalies:
https://www.tecmint.com/find-top-ip-address-accessing-apache-web-server/
Looking on Google, I found some services that I think can help:
https://goupcloud.com [complete optimization and identification of bottlenecks (treatment in the cause and not symptom)]
https://www.wpfaster.org/ [full optimization]
https://www.wpspeedfix.com/ [full optimization]
We have Magento EE 1.14.0.1. recently we moved to new AWS EC2 server and ElasticCache Redis server. then some random products start disappearing in the frontend. They exist on backend and configured correctly ( visible , enabled , in stock , etc .... ). And only after you save the product in backend it will show up again in frontend even without flushing any cache.
Is this issue related to Redis cache ?
and if its how to fix it ?
Any input would be appreciated to direct me to a solution.
Thanks
Update: I marked everything under Index Management to Update on Save. so I revert that back to update on schedule. and I think that fixed the issue. but still I want to keep my store inventory up to date.
"It's an index issue, every time you update data (product, stock) from database, you have to manually re-index Magento."
That is true for Community Edition, not Enterprise Edition. In addition, there can be some extra issues when migrating to AWS. After 4 months of troubleshooting on an inherited server migrated into AWS I found a number of issues/solutions.
EE issues
Enterprise Edition indexing is asynchronous for many of the indexes. In addition, not all EE indexes are configured in the typical place.
On the Admin menu, select System > Configuration. In the panel on the left, under Advanced, select Index Management.
http://docs.magento.com/m1/ee/user_guide/system-operations/index-configuration.html
Even when set to "update on save" in my experience it frequently does not update on save.
AsyncIndexing was unstable in versions prior to 1.14.3.x .
Upgrade! It was possible for the partial process to break in such a way as to make it impossible for indexing to proceed. One way this will occur is if you are running PHP for the website[typically via PHPFPM] with a different userid and group then you run the cronjobs[shell access]. Indexing depends on the creation of a file to 'lock' the process - the file may only be written/deleted by the user which creates it.
I have found that for performance reasons, it is best to set ALL indexes to "update manually". Do not schedule a periodic reindex all process, it is useless due to async indexing. Just make sure your cron is running and everything should be fine.
The AsyncIndex process uses MySQL triggers...which have an issue when trying to migrate a magento database from one server to another. The way they are created initially, they can ONLY be used by the database user that when the triggers where first created. If you change the database user for the new server, the triggers will not migrate. Even worse, there is almost no indication that this occurred and everything except indexing runs perfectly so how can you tell?
Lastly, "reindex all" does not always reindex all. Thanks to various posts on the internet, I created a shell script to make Magento think all the products were updated and the index needs to be rebuilt:
https://gist.github.com/gamort/5dc5e16bdec00a8bb3b922fc463af17c
AWS issues
Using AWS Elasticache Redis has a hidden gotcha - the default zone it is launched in may be different then your server zone. In my case, the server was in USEAST-1a while Redis defaulted to USEAST-1b. This resulted in occasional timeouts when looking up data from the cache. While the website code can usually recover, the indexing code does not. This leads to the index cron process being in a broken state.
Almost as importantly, you will pay a trivial amount per GB for data transfer from zone 1a to 1b. But when your cache is working, this "trivial" amount can amount to a lot! We had a recurring $10+/day [$500-$600 a month] intrazone data transfer fee! Launch a new redis server in your actual zone, use the redis cli on your web server to make sure you can connect[we had firewall configuration issues] and then only THEN update your configuration.
AWS RDS server also have a hidden gotcha[hope your not too overwhelmed yet]. Migrating the database from another server to Amazon RDS has issues where there was an extremely slight change in what MySQL considers valid SQL for a specific function...which Magento EE just happens to use. :-) . I ended up installing a new copy of Magento EE and using Navicat to sync the database structures.
Solr issues
Suffice to say, there are Solr issues as well. Mostly due to the schema, but I also found that wiping the solr database and letting it reindex helped.
Magento Rewrite/Form issues
This issue occurs when you upgrade to 1.14.3 - which of course you should do since it fixes so many indexing issues. Version 1.14.3.x added form keys to a number of forms, including the customer sign up form. So if you created your own custom phtml templates for the logon they will not work! You need to add that form key field to your customization. Not a big deal though, since you documented what template file you copied it from initially right?
All in all, I would estimate going through the checklist for migration to be a good 20 hours, and possibly up to 80 depending on what issues you run into. And at the end of the day, since the fixes are mainly in cron jobs which are not easily visible the website owner will be hard pressed to tell how they benefitted from all that work. In my case, disappearing products had already been an issue for over a year before we inherited the site the client was understanding about the difficulties.
It's an index issue, every time you update data (product, stock) from database, you have to manually re-index Magento. If you don't do that, you'll have corrupted data on index and you'll lose SQL join on product request list.
We have been running a local application for a bit over a year now and this problem has never come up.
We have a section of our application where a user will add a note to an account. Very simple table structure includes an account_id, user_id (who added the note) and a date.
The notes are still being added into the database just fine; however, when viewing the page, it is hit or miss on whether or not the note will actually display using PHP to query the database.
The only way I can get these notes to show up is by clearing the computer cache (again, doesn't always work) or clearing MySQL cache (which doesn't always work, either)
The application is being accessed from outside of our local network, as well, and this issue does not seem to happen from anybody using this method.
I think it is a cache issue, but I am honestly not familiar with this and have not run into this issue with anything before. Server is latest version of CentOS and we are running very simply MySQL queries via PHP.
Thanks, in advance, for any assistance you can provide.
I’ve been working on a php project where I’m trying to create a cards game.
That obviously needs to be updated in real-time, so, having almost finished the underlying server logic, I went for the naiive/obvious solution for fetching the data from the server - heartbeats or periodic ajax requests - and was thrilled to see the page working through that.
Misery began when I started thinking there could be a less "stressful" way, that’s when I found a couple of conversations here (and in other websites) about "Comet" and “AJAX PUSH” or “Server Push” which I’ve read about intensively.
I found a demo in zeitoun.net which was very simple and ridiculously easy to make it work on my localhost.
As I was writing this question I've gone through the "similar question" panel. and to be honest it's very confusing which option to go with.
Which would you recommend, knowing that I wanna make sure the website can serve up to 2000 users, and that I'm using PHP on Apache?
Keep using the current method, periodic client ajax requests (I've refined the server response to that, and it actually returns nothing most of the time unless a change was to be sent, but still I'm worried about the amount of hits per second the server is going to recieve).
Go for the "too good to be true" solution at zeitoun.net.
Use APE which will require me to switch my operating system to Linux (which I'm willing to do if it turned out to be a promising solution).
Take a deeper look into https://stackoverflow.com/questions/4262543/what-are-good-resources-for-learning-html-5-websockets and go for HTML5 Websocket instead (regardless of browser-support and used fallbacks).
None of the above?