My drupal 7 site takes more.. time to node add (node/add) and update (node/edit). Please anyone help me to reduce the time of node add and edit
Normally I'd do this:
Try disabling modules you installed recently. Or revert/switch off new functionality. I assume when you say takes more.. time you compare it to some time in the past when it was better. Try to recall what were the changes to the website configuration or modules set since then and roll them back one by one.
On your local copy of the website enable Devel module and look at the amount of queries executed while adding or updating a node. look at the most slow ones. It may lead you to some more narrow question.
The last resort I'd say - profiling code with xdebug but I'm not sure how deep you are with PHP development and debugging. This one requires skills in configuring your web-server, and using a PHP IDE or at least an xdebug profile reader (e.g. webgrind)
Try installing fresh Drupal 7 on same server (i.e. create staging sub-domain) and see will on it adding/updating also take long time. If so, problem is with server obviously.
If it's fast with fresh Drupal then problem is on your site - try turning off modules one by on (again on staging domain preferably) until it starts working at normal speed. Must be that some module is causing the problem.
Related
I don't know exactly why my drupal 7 website became suddenly slow last week, after few days in production.
With xhprof, i see that at each page load,the system_list_reset() function triggers a call to cache_clear_all() function.
I deactivated all cache features.
I've read that it may due to missing files in modules and/or themes, but I didn't find missing files (except a wrong issue in 'missing module message fixer' module that indicates a missing module in view_export sub-module of view module).
I manually searched them , I didn't find where drupal can list these missing files.
Or maybe it's due to another problem.
Regards,
Open page inspector of your browser and in network tab check what files have unusually long loading time. It maybe be that some external service is causing this. Also it can be that your site is hacked...
Check most banal reason, the storage space - maybe disc of your server is full?
Check if file paths drupal is using are writable. Go to Configuration -> Median -> File system and just click Save. If some path is not writable it will get red outline.
Go to Reports -> Recent log message and check if some issue is maybe logged there. Also check for web server/php logs.
Try updating modules and drupal core - maybe some bug caused that and it's hopefully fixed in module update.
If not, try disabling modules one by one and see will that still happen. If you don't find problematic module try the same method with your theme. Would be good not to try this in production development and/or make backup before doing this.
thanks a lot,
by disabling module one by one, and by "datamining" in drupal DB, i've found that ADVAGG module was guilty.
The clean was difficult, because some entires remains in some tables of Drupal DB afther the module removing, but I hope it Ok.
BEWARE OF ADVAGG MODULE !
Funny :-/ with 'top', I've found a mining soft in /var/tmp/
systemd-private-a5422b1e6694466bbb0b63203573cad1-apache2.service-jMBN4U : nullcrew (from https://github.com/xmrig/xmrig)
I will investigate how it could land on my webserver
Best regards,
A relative asked me to fixed a Joomla website (v2.5.16) who has been hacked last year, probably due to lack of update (is up to date now), unfortunately I have no information about this. The issue is that the front end take 2~ min to load. The administration is loading normally so whatever the issue is, it depend of the front end. I already disabled all modules one by one and switched the template with another one to make sure that thebug is not in template or plugins folders, without success.
I must add that the problem is "probably" more recent than the hack, according to this person. So maybe there was a script somewhere reaching a random server which may not work anymore.
PS : the website is on a shared hosting. I have the FTP access but no ssh.
I know that I don't give any details which can lead to resolve this, but I need more a method to track what can go wrong and where than a solution.
Thanks in advance,
We have written a lengthy post explaining why a website might be slow: http://www.itoctopus.com/20-questions-you-should-be-asking-yourself-if-your-joomla-website-is-slow
From the looks of it, it might that the website is still hacked. Try overwriting the Joomla files with a fresh Joomla install and see if that addresses the problem.
Solving this issue will probably involve some or all of the following:
updating Joomla and all third party extensions to the latest versions
checking for and fixing malicious files using http://myjoomla.com or
https://sucuri.net or similar
analysing the performance of the website using http://gtmetrix.com
(it's free) or similar to pinpoint and fix what is taking the most time to
load
If the website has been hacked, you may need to reset passwords etc once the malicious files have been removed. See https://joomla.stackexchange.com/a/180/120 for more information about securing the website once it is fixed.
I have developed 9 multiple websites/stores in one magento installation. On DEV server it is ready and working good. Now my client wants to launch first 3 websites in next month, then after we will make some modifications in other websites based on feedback from first 3 websites. Then launch other websites one by one.
One thing which I am worried about is how we make modification and further development. Because magento files and db is one installation, if we launch first three which means we are launching whole system, and if we make DEV work in live site that is not good because if anything breaks etc. LIVE sites will go down.
What is the best and logical procedure in magento to launch multiple stores one by one. What approach we can follow for such situations.
Please help, thanks!
To my eyes, the fact that you have 9 different websites/stores running off the install is of minor importance. You will encounter the same issues that any dev / live Magento set-up will encounter. At the point the site launches you will need to create a second copy of your database / code for use as a development environment. With regards to the code, I would hope that you are using some kind of VCS such as Git or SVN, if you aren't you should seriously consider it.
The database is the slightly trickier side of things. It is also going to be the issue exacerbated by the fact you have 9 different websites, since you will have a lot of different configurations. There will likely be 3 different types of configuration changes to be made.
1.) A setting that needs changing for the live websites.
2.) A setting that needs changing for a future website to be launched.
3.) A setting that needs changing in order to make your development site work.
The 3rd type is the easiest to deal with. You can simply change them in the database and forget about them. These will include things like setting the base_url values in core_config_data.
The 2nd type should ideally be made with migrations rather than through the UI. If you are using Source Control these migrations would be kept in a branch that will get merged into your master branch at the point you wish to launch the website they effect (at the point the code is merged, you may have to do some tinkering with the version numbers based on how you deal with type 1.
The 1st type can be handled in one of two ways, a migration is a favourable option as it means all installs of you code dev / staging / live can be kept in sync. If needs be, simply ensuring you update your dev database at the same time as the live one, would suffice.
Some of the things you need to change won't necessarily be the easiest things to achieve through migrations, but doing so should prevent any errors from arising whereby you forget to update a single value on one of your servers.
So, we had the hosting service set up a dev site with the intentions to then upgrade our live site once that was done. After a ton of back and forth the hosting service bailed on us, and we're left with an updated dev site and not much of a clue on how to update the live site.
While I'm not asking for a foolproof way of updating the live site, I do need something that won't impact sales by being down....or something that won't be a problem to roll back on in case there's issues.
any guidance / tutorials would be a big help. when I set up our original site we weren't live yet, so I could grind away without losing $$$. That's not the case now.
Thanks!
There are two things that happen for upgrades: new functionality from the updated / additional files themselves, and database upgrades which are triggered by each module's version.
Above all, it may be advisable to find a freelancer or shop with a good Magento track record and experience in 1.3 to >= 1.4 upgrades. They should be able to set you up for the clearest upgrade path moving forward. That said, here's a procedure:
Backup database and filesystem.
Perhaps, make another backup.
Create your own dev environment from this backup: install files, duplicate database, change the db settings in app/etc/local.xml. You likely will need only to change the base_url settings in the core_config_data table: SELECT * FROM core_config_data WHERE path LIKE %base_url).
Check the big core files: Diff your app/code/core/, js/, lib/* files with a known-good copy of the 1.3.2.4 or 1.3.3 (there is no 1.3.4) - check Mage::getVersion(). Any changes will need to be accounted for. And slap whoever changed them :-)
Once you've verified that you have a healthy core / fixed your core, you are ready to test the upgrade. Simply copy the files from 1.5.1 over.
Make sure that you have set a substantial timeout if you have lots of orders.
If you have issues with this upgrade, you may opt to step through versions. Particularly, you can go from 1.3.2.4 to 1.4.0.0 to 1.4.2.0 to 1.5.1.0. At the very least, this might help you spot where along the upgrade sequence things are going to pot.
Also, you will need to fix your templates. Between 1.3 and 1.4 Magento implemented a base design package and default theme; other themes should build from this. You'll almost certainly need to merge your changes from your layout templates (under template/page/; 1column.phtml, etc.).
I want to create a component that will allow me to install other components, modules, and plugins that i personally use all the time. I will need to be able to change these modules, components, and plugins at anytime but updating the components and etc.. that i use and be able to add more plugins and etc as well. I would like this Component because it takes too much time to install them all individually and on multiple sites as a web designer. I also would need to have some instruction on how to add subtract plugins, modules, components, and etc. I am ok with not a total integration i would like to be able to just host the install file on my server with a link to my server where the file is located.
If anyone can help with this please do.
this is not a direct answer more of a personal workaround ( I do this on local host).
I create a site for example Joomlabase, when it asks for DB name call it Joomlabase then add my extensions
then when I need a copy
1) copy and paste the folder named Joomlabase in Windows Explorer to a new name.
2) go into Phpmydmin copy the joomlabase DB to the same name as the new site name.
3) DO a search and replace of Joomlabase to new site name in config.php file (there should be 5 changes) and your done.
For me it saves a lot of time because in admin alone I use at least 12 different extensions
There is a Joomla admin component called "Akeeba". It creates a snapshot of your files and database which you can easily deploy to another server. I use it often when pushing a new site to production from a QA server.
http://www.akeebabackup.com/download/akeeba-backup-core-for-joomla/index.html
Your question is way too broad, and the simple answer is that it would take much much much more work to maintain this 'super component' than you are currently spending simply installing the extensions separately when you need them.
The other answers here don't answer your question, but they provide some decent solutions to your actual problem.