I have setup a magento installation with a multi-store backup. However, lately we are dealing with some severe hosting/performance issues.
Everything is optimized for magento on the server-side and we are also using caching. However, especially when performing database-intensive operations (adding several products to the stores), we see that the performance of the server goes down.
I have been thinking what can go wrong and I guess it has to do with the number of stores we have on one back-end. In fact, currently 20 store-fronts are installed on the server.
Does anyone know whether there is a maximum in amount of stores that can be setup as multi-store on one Magento backend?
Just to answer your basic question no there isn't a maximum amount of stores that can be run on a multi-store backend. This database intensive slowness is probably not directly relevant to the amount of stores but instead is a result of re-indexing of prices when saving a product.
Take a look at these links, there are some solutions on how to resolve this issue:
http://www.magentocommerce.com/boards/viewthread/221229/P0/
http://www.magentocommerce.com/boards/viewthread/38818/P90/#t367525
Related
When I save a product in the Magento admin it is extremely slow. It can take around a minute for the product to save.
I found some information in Google that suggested this would be related to the indexing. I changed the indexing mode so it only updates manually but the problem persists.
For some reason if I select the product and use the 'Update Attributes' option it saves in a few seconds but updating an individual product is painfully slow.
Any ideas?
Inadequate system resources and need for MySQL optimization. Find a hosting provider that provides servers tuned for running Magento. 1 minute sounds about right for a shared server that's being choked off by settings that ensure that resources are being shared out equally among all the users on the system.
Generally in Magento to upload products use of data import/export is recommended.
Magento Backend is slow and you need a more powerful resource/server to process things faster.
Also as stated in above post you need to set indexing mode to manual which you have already done.
Also more number of attributes means higher sql query load so check for attributes sets etc.
Products saved fine until recently and I am on a semi dedicated server so this wasn't the problem.
However, I have now found the cause of the problem. It was an extension from channelunity.com. I have disabled that and saving products is back to taking a few seconds :)
I have contacted the extensions developer so hopefully they provide a fix.
Lately i have experienced something strange on my magento site. Sometimes my site is running slow and sometimes its acceptable.
Do you know some tools to test it a day long?My site is running on a VPS.
http://bit.ly/iefbw1
Love to know your results and reviews on the sites speed.
Thanks
To test the speed of a website + immediately get recommendations on what can be easily improved to reduce the loading time I use GTMetrix.
Some other pointers for speeding up Magento:
Install Varnish on your VPS + PageCache powered by Varnish
(Magento module)
Install APC for better caching
Make sure you have enabled Magento's default compilation feature
EDIT: As mentioned by ADM you must also optimize your MySQL and Apache (considering you are running apache2) configuration.
EDIT2: As general suggestion I suggest you to Google for "speed up Magento" and you will find hundreds of topics/articles covering this subject.
#Kenny you have a bit wrong approach, to start you have to check your apache config, unload all extra modules apache2ctl -M, same with php -m, then install apc or eaccelerator, then check your mysql config, it usually takes 2 days to see mysql real values, use mysqlreport perl script, it will show you whats going on with your database. then you go for Leverage browser caching, and only after you setup FPC. not sure if compilation 'must have' feature...
I have checked many Magento websites and find that most of them are very slow.
Have you ever checked why the Magento websites are very Slow. Let me show some reasons and the solution for making Magento Websites Faster.
Reasons why Magento websites are slower
Compilation Turned Off
Cache Problem
No Full Page Cache
Code looping
Flat Data not Enabled
Large Database
Memory Limit Too Low
Indexes are not updated
Not Using Memcached
Merge css and js files
Magento Htaccess Gzip, Mod_deflate, Performance Settings
Server
Solutions for Making Magento websites Faster
1. Compilation Turned Off : The Main reason due to the Installation of many modules.All activities of the system must go through modules and an action in Magento may involve some modules, thus the loading and running of Magento system are quite slow. So if you want to make your website faster then first enable the compilation.
Procedure for enabling the compilation
Login to the Admin panel
System -> Tools -> Compilation
-> Then Click on the Run Compilation Process
Cache Problem : Cache is not enabled in your system.
Procedure for enabling the Cache
System ->Cache Management
-> Select All -> then from action select options -> select Enable ->click Submit
No Full Page Cache : Full page cache is very important for any Magento based websites.
You can also use this free Magento extension for Full page Cache.
Lesti Full PAge Cache
Code looping : Their might be a reason for the Custom Code, may be some wrong code added so that it is looping and using the wrong code and looping database queries. If this is the problem then any developer can only solve the problem or use the default code.
Flat Data not Enabled : Flat Category and product data is very important for Magento Websites. Whether or not you should enable the Flat Data of Products and/or Categories varies depending on your Magento website structure.
If you have only dozens of products with many attributes, or have a few hundred products with only a few attributes/attribute variations, then flattening the products/categories may not impact the site speed significantly. On the other hand, if your website contained almost 1,000, or possibly several thousands of products, then it is almost always recommended to flatten your products. If these products are spread across multiple dozens of categories (and products aren’t duplicated across these categories), then flattening these categories would be suggested as well.
System -> Configuration -> Catalog -> Then in frontend tab you will find two settings as
Use flat catalog category and flat catalog product. Enables both the settings to yes.
Large Database : Due to large database size might decrease the performance of your server. So it is always recommended that you backup and delete the old and garbage data. If you have log enabled then what changes you will do every time in the Admin it will be stored ion the Admin, so if it is not necessary then either you can off the the record of the log or make the setting as it will delete all you logs at the end of the day or at the end of the week. if you have more than 1000 of visitors per day in your website then certainly it saved all the searched data in the database and other customer related info, if it is not so important then you can also delete and clean your database.
Procedure for enabling or disabling the logs in Magento
System -> Configuration -> Developer – > Click on log settings tab
Here you will find the setting for the log
Memory Limit Too Low : I have checked in some posts, they are saying that this may also be the reason and it should be improved to make Magento website faster.
There is a setting in your configuration files which sets the maximum amount of memory you can dedicate to PHP processes. Since Magento is a big memory hog, having this value be greater than 128mB can significantly bump up the time it takes Magento to perform operations.
what you are trying to do.
For more info about : Increasing Magento Speed and Loading Time
http://www.webtechnologycodes.com/increasing-magento-speed-and-loading-time/
I have a server which is running more than 15 Magento stores, but they are not performing well, though I have a giant server for hosting them. My server configuration is - 8 CPU's Quad Core 24GB RAM and 2 TB HDD.
My current page load is 1.6sec. I want it under 600ms. I have already installed APC, & eAccelerator and tuned Apache's parameters. I am using the latest Magento version.
Please suggest.
-Ramesh
You might look at enabling block caching as explained here. It should work pretty well on the category and product pages but you have to be extra careful to apply proper cache tags and identifiers to make sure the content you are displaying is always up to date...
First things first, what is actually bottlenecked? Optimization is always about tradeoffs, and you may just make things worse if you're looking in the wrong places. Make use of top (assuming you're on Linux here) and see what your processor/memory usage look like.
I'm going to take a stab in the dark here and say that, if you have already added an opcode, you may be waiting on other HTTP requests for page load. Use YSlow on Firefox and see if you are trying to load excessive amounts of data. Optimizing image size and setting proper caching parameters for images may solve the problem there.
If not, silvo's suggestion is a very good one. Using either block-level or page-level caching can really speed up a site. This topic has been covered previously, so see those posts, too.
Hope that helps!
Thanks,
Joe
I'm not sure that you will see a benefit of using APC and eAccelerator on the same server. They pretty much do the same thing.
A page load of 1.6 seconds is fairly typical for a Magento install. They easiest way to lower your page load time (after basic Apache and MySQL tuning and APC) is use a Full Page Cache. There are a few out on the market right now. We have written a Full Page Cache that has gotten page loads down to the .1 - .3 second range for most users, http://ecommerce.brimllc.com/performance/full-page-cache-magento.html
I am looking to set-up a Magento (Community Edition) installation for multiple clients and have researched the matter for a few days now.
I can see that the Enterprise Edition has what I need in it, but surprisingly I am not willing to shell out the $12,000 odd yearly subscription.
It seems there are a few options available to be but I am worried about the performance I will get out of the various options.
Option 1) Single install using AITOC advanced permissions module
So this is really what I am after; one installation so that I can update my core files all at the same time and also manage all my store users from one place. The problems here are that I don't know anything about the reliability of this extra product and that I have to pay a bit extra. I am also worried that if I have 10 stores running off this one installation it might all slow down so much and keel over as I have heard allot about Magento's slowness.
Module Link: http://www.aitoc.com/en/magentomods_advanced_permissions.html
Option 2) Multiple installations of Magento on one server for each shop
So here I have 10 Magento installations on one server all running happily away not using any extra money, but I now have 10 separate stores to update and maintain which could be annoying. Also I haven't been able to find a whole lot of other people using this method and when I have they are usually asking how to stop their servers from dying. So this route seems like it could be even worse on my server as I will have more going on on my server but if my server could take it each Magento installation would be simpler and less likely to slow down due to each one having to run 10 shops on its own?
Option 3) Use lots of servers and lots of Magento installations
I just so do not want to do this.
Option 4) Buy Magento Enterprise
I do not have the money to do this.
So which route is less likely to blow up my server? And does anyone have experience with this holy grail of a module?
Thanks for reading and thanks in advance for any help - Chris Hopkins
Let's get the non-options out of the way right away. You don't want to do #3 and #4 is a non-solution. Magento Enterprise Edition doesn't add any features that will let you run multiple customers from one store.
Now, onto possible options. As you state, #1 will allow you to update one version of the code, but of course this comes with some risks. As I understand it, your customers will need to access the stores? If you have multiple customers running on one database and one codebase, you will always run into issues with them affecting each other. For instance, who will control product attributes, which are by nature global? If one store deletes a product attribute, other stores may lose data as a result. If you solve this issue, what about catalog promotions and product categories, etc. Magento was built to handle multiple websites, but not to insulate them from each other, and you will experience problems because of this. As for performance, a large product catalog or customer base will tend to slow down the site, but you can mitigate this using the flat product catalog and making good use of caching.
For option #2, you can run multiple Magento stores, which brings up two main problems. First, as you state, is updating the sites. If you are using a vanilla installation of Magento and not modifying core files, this should be a nonissue. Magento's updater is pretty simple for those installations, with difficulty increasing as you do more mods and have to use more manual processes for upating.
As far as performance, running multiple magento sites might be slower, but it depends on how you structure them. Regardless of having one or multiple sites, you'll have to load data for each site, so database size won't be terribly different. File size on a server is pretty much a nonissue. In either case, when a customer requests a page, Magento has to spin up the entire framework to serve the request, which is where performance issues start to show themselves. One of the big mitigations for this is to use an opcode cache like Xcache, but with multiple machines you need to give Xcache much more memory to hold all the installations' code. Legitimate problem.
My recommendation? Start on one machine, multiple installs. Work your way up on number of installs, and when the server doesn't support any more, move on. Keep your code changes out of the core and use extensions that can be easily updated, so updates are easy. That should mitigate as many of the concerns as possible.
Hope that helps!
Thanks,
Joe
We handle a couple dozen magento "installs" using a single code base, but multiple databases. Essentially we've done a rough job of creating a multi-tenanted Magento.
Here's how we're doing it:
Use nginx as a reverse proxy to handle some basic routing rules, and to set some server variables (fastcgi_params) based on the request.
We hardcode routing rules into Nginx Config based on the requested domain, browser language, and visitor location.
Set a server variable using Nginx fastcgi_params as "client-id"
Make copies of the app/etc folder with the convention of app/[client-id]/etc
override Mage.php variable $etcDir to $etcDir = self::getRoot() . DS . $_SERVER['CLIENT_ID'] .'/' . 'etc'; (You'll have to apply some logic here, to ensure that this can fail elegantly)
Edit app/etc/[client-id]/local.xml to point to a fresh db with magento tables and base content already imported. (You'll have to also set the URL in the core_config table, or in the local.xml file for anything to work)
Modify the include path of app/code/local/ to be app/code/local/[client-id]/ in Mage.php (yes, shoot me for overriding core code, but it's the only way we could find)
Setup Session Handling to be done in a Redis db, with db # unique per client
Override getVarDir() in Mage_Core_Model_Config_Options to include [client-id] in the path. (This is to ensure that you aren't sharing cache between clients)
You probably get the gist so far.
Other things you'll want to consider:
Isolation of media by client-id,
Consolidating all "Admin Panel" urls, and asking Admin user to select [client-id],
Configuring Varnish in a way that is sensible,
Setting up CDN in a way that is sensible,
Modifying Magento installer to support this method, and handle basic configuration automatically.
I think getting a vps account and scaling it up when it becomes necessary will give you the best options for your cost requirements.
For my two cents I think you are going to run into more problems than pros by throwing everyone into a single installation of Magento with everyone bumping into one another. Not to mention Customer X on Website Y cant seem to figure out why he can't create an account on Website Z that he has never been to before (that is a configuration issue, but it could happen)
What I would recommend you do is setup a git repository that has your "base" Magento installation and then have all your clients on different versions setup that you could clone from that main install.
This will give you only one real code base to update (database changes are a different story) and everyone is separate.
We run multiple clients on a single Magento CE installation and use AITOC's Advanced Permissions module to control visibility for our different clients. The module works well, although it has several hiccups and lacks functionality in a handful of areas, which we've had to handle with our own in-house modules. It doesn't seem to have any noticeable effect on performance, as we've been running it this way for months now without any issues. (That said, we do use Amazon EC2 and auto-scaling.)
As I understand it, EE does provide advanced role permissions that would render AITOC's module useless. However, I have also heard that the EULA for EE requires only 1 client per installation. I haven't been able to find hard facts on this, but if it's true, it's truly a deal-breaker, as having an additional EE installation for each client would get tremendously expensive, tremendously quickly. (Maybe someone can confirm yes/no on this, though?)
In the beginning i built my site - bemcapaz.net - on Wordpress. But after having to hack the core and build lots of stuff through direct programming I decided to move on to Drupal.
Drupal besides being a CMS focused more on community websites is great for doing anything you can imagine in a really simple way, even a blog which was what I created.
My question now is, which one offers the best performance? I think Drupal looks to be really heavier than Wordpress but since I'm not an advanced programmer I have no idea how to evaluate which one offers the fastest MySQL requests and loading times of the web pages.
Thanks.
Drupal is definitely heavier in the sense that it runs more queries per page once you've customized it. Using modules like Views, you can also build your own dynamic queries to drive widgets and pages. Those can be as speedy or as slow as the underlying combination of joins allows.
On the other hand, Drupal does have much more robust caching controls. Full-page output caching for anon users, granular caching of widget output, and granular caching of any data retrieved by a Views query can all combine to help quite a bit. There are also plugin modules like "Boost" or "Memcached" that let you augment that underlying cache system with materialized HTML files in the filesystem (bypassing Drupal directly in favor of apache), or a memcached server that stores all the cached information in memory rather than the database.
If you're looking to discover hot spots in a Drupal site you should also install the Devel module; it allows you to get query counts and detailed query times for each page on the site, and track them down to the module that's running them.
Don't know about Drupal, but in WP you can estimate query time with following code:
Just add it to your footer, after any queries.
<?php echo get_num_queries(); ?> queries. <?php timer_stop(1); ?> seconds.
I suppose, performance for both CMS depends on numbers and complexity of queries and caching mechanism. If you are using them both wisely, your performance gonna be OK. I mean - ask your database only for info you really need ;)
If someone (like me) wants a raw and simple time-comparasion, I wrote the exact same App 3 times (with 3 frameworks), which's result will share below.
Note that I didn't do any heavy queries.
Or anything which would affect the results
(in favor of one framework over the other).
In my local with Core-i7 CPU, and SSD storage:
Drupal toke 5 seconds to show a simple page:
And that because of caching,
If I clear cache manually, takes 25 seconds (and recreates cache, so the next run takes 5 seconds again),
But don't worry a server's hosting-machine is far stronger than my local-host (>ლ)
While WordPress toke 17 seconds for same page (and that always).
Again, don't worry a server's host is far stronger than my local.
Rewriting with Laravel, same App takes 850 mili-seconds ;-)
So, if you don't have the time, money or knowledge to create a basic CMS with Laravel, then Drupal is the obvious winner (but harder to learn compared to WordPress).