If anyone has been able to find ways to significantly speed up load times, I would love to hear how it was done (ideally without changing host as we have a lot of business built around the Mosso platform).
I don’t think there’s much you can do if you’re on shared hosting, even though it’s clustered. I’ve moved to a managed vps, with guaranteed ram and cpu, and the speed/load times are fine now.
I am in the early stages of playing with Magento (about 4 hours in!). Goes without saying that the product has great potential and is easy the most impressive I have seen…
but on my windows desktop box, page build times are around the 5 second mark, (yes I know it is only a desktop on windows, but it only has one user!)
I have profiled the homepage and at least half of that is this:
Well i gave up, I took a 4 week crash course in unix the hard way, download, install and pray,break it, reinstall it, break it some more, pray some more, reinstall, rinse/repeat.
after 4 weeks of stupid thing after stupid thing i finally managed to get the servers running fine (if i could program Cisco 7000 routers like hell i wasnt going to learn how to install Unix lol)
They are 2 R900 Dell Poweredge servers both running FreeBSD 7
On 1 box Iput up 2.2 apache and 5 php and on the other box i put 5.1.22 mysql so they are now 2 separate servers and ONLY running magento and nothing else, both linked with a gigabit fiber lan to each other, these boxes have NOTHING on them but the bare ports/packages required to run magento + the apc cache thing what ever that is.. aside that they are CLEAN 90,000 combined RPM from 6 15k RPM drives on dual failover Raid 5 controllers with 256mb hotram/hotswap cache built in HAVE to do something.....
Now… its still slow ..... ok not windows slow but definitely not crucialwebhost fast.....
could anyone explain to me what i might be doing wrong? or at the very least any tips on how to config the boxes so they run better? i cant believe these machines doing 5-6 secs loading a page.... its not right.
"sure fire! go here, press that, increase XXXX to 10 gigabites, change that config to add that package, copy that file and rename to X, change the order of YYY try increasing the ram cache on the mysql, etc etc etc.”
I’ve not changed much of the clean install of Magento. I’ve added 2 categories and 1 product. And it takes me a total of 20 seconds to reload the main page.
Am I having a slow webhost provider, or is this normal for Magento?
If this is normal, I would say the Magento is useless in terms of serving as a webshop. What customer wants to wait 20 second for each page they look at?
Personally I would give up, even before I see the first page.
i think i must to take leave Magento and come back with osCommerce, or Virtuemart on Joomla . Magento’s Speed id so slow.
Our Services , our Clients can’t be wait . Sorry Magento .
Magento is a beautifully crafted piece of work. A lot of attention went into the details, no doubt.
Unfortunately, there will be no significant speed improvements in Magento until the underlying database is reengineered.
The beauty (as in flexibility) and the agony of magento can both be attributed to the ambitions of the data architecture. It appears that the Magento team has created what I call a (partially) Adaptive Entity Framework where, unlike in traditional database designs, evolving the system to handle new types of information (entities) and new relationships between entities is a walk in the park. In these types of systems, once your entity management framework is up and running, creating flexible systems is a relative breeze.
The drawback to this kind of design is that there is some added overhead required to interpret and realize the entity types and relationships into complete working objects. The alternative is a traditional dtatabase design where tradeoffs between feature set and a working system must be made for development size and time-to-market reasons. Traditionally designed systems will operate faster, but are also much slower to evolve.
Magento’s approach is “partially” adaptive in that they didn’t take it the full mile. In a fully adaptive entity framework, in the rubric of a shopping cart, there would be no discrete customer, product, sale_order, etc., tables--only definitions of their types and relationships that also have to be interpreted for the shopping cart system paradigm to emerge from what would on the surface appear to be convoluted goo. However, going this further step would’ve added even more time to the process of getting the data to coalesce into true meaning and operable data.
I’m in my third iteration of designing such a fully adaptive entity framework and in this iteration I’ve engineered out the overhead. The first was when working on a medical systems project. I realized that the amount of data types and relationships was just too over the top--close to 175 tables with complex relationships (less than Magento’s current 193, but still, over the top, imo). I was able to condense all of the entity types and all of their relationships into just 8 tables. It created what could be described as a holographic data set where the data changed its shape and query results depending on the parameters fed into it. Instead of taking months to years to complete the system, the framework took three weeks, defining the entities and relationships took 1 week (with a full year of prior research to understand the needs of the profession), a flexible presentation scaffold was complete in less than a week, and a user-designed views facility was added in just another week. EVERYBODY was happy. Speed on that project, however, was not an issue as this was a desktop app. Again, I’m in my third iteration of such a framework and this time I’ve accounted for the needs of the web, scalability, availability, performance, and multi-tenant environments. The ultimate result of this will be a system that can allow the creation and execution of any system, even a Magento, with a designer/user programmable workflow engine and multi-mode multi-tenancy built into the design. My current targets are medicine, social networking, CRM, and a generalized platform-as-a-service (PaaS) where domain experts design systems to suit the needs of their profession without the need for programmers or for knowledge beyond their domain expertise. After a full two years of design, testing, and benchmarking I’m almost there and the ever-crucial speed benchmarks are looking great!
Why do I mention all of this? Because I can tell by looking at the data and code infrastructure of Magento that there are only two directions in which the developers can go to dramatically improve the speed of their system:
1) Re-architect to remove some of the abstract data handling, leading toward a more traditional db design.
2) Go fully adaptive/abstract and figure out ways to make the data jump quickly to attention in fully-formed ways upon demand. A fully adaptive architecture will allow one single-table query to replace the multiple queries, expensive joins and full-table scans that plague traditional solutions.
That said, I do see some areas where refactoring the code could help.
This post is not in any way intended as a slam. Quite the contrary. I actually admire the team’s work and attention to detail. My post is merely to express my thoughts as to the nature of the speed problem and its possible resolution.
I just checked out some of the demo stores at store.yahoo.com, Yahoo’s eccomerce solution, and discovered the following:
NOT NEARLY AS BEAUTIFUL AND FEATURE-RICH AS MAGENTO PRODUCT PAGES LOAD BLINDINGLY FAST ADD TO CART, HOWEVER, WAS COMPARABLE TO THE SPEED OF THE SAME FEATURE IN MAGENTO (on a shared-hosting plan on a busy Saturday afternoon. (Last night, at 1 a.m, my test site was presenting all pages and functions within 2 - 4 seconds. During higher use times that went up to 12 seconds.))
So… I’m going to eat, ohhh..., at least a wee portion of crow and alter my conclusion(s) a bit and say that Magento is state-of-the-art in every way.
Perhaps the key then to a fast, beautiful, feature-rich shopping site, as provided ONLY by Magento (as far as I’ve seen), is, as several others in this forum have mentioned, to try to advance your hosting plan to a dedicated solution where you can control ram and caching. Of course, you will have to balance the monthly cost of a dedicated-hosting plan with your monthly profits and earnings growth potential.
I do think that it would serve the Magento team, their current user base, and prospective users especially, if on the Magento site was posted the system requirements and estimated shopping experience performance per OS and type of hosting environment. Perhaps prominent links on the features list, download, and installation instructions pages would go a long way toward setting performance expectations and allowing shop owners and consultants to make informed decisions that currently only come about through time and experimentation.
In my final analysis, despite being slow when implemented in shared-hosting environments, I highly recommend Magento over everything else that’s going on in the world of ecommerce including pre-fab services from Yahoo, Microsoft, and Amazon, or other open source solutions such as Zen Cart, etc. The Magento folks have done a great job.
Mmmm… I didn’t know crow could taste so good. Must be the Magento sauce. Think I’ll have some more…
Yeah,i agree that Magento Features are better than others eCommerce. Magento Graphic Designs is good,too.
But with a eCommerce system, the speed is important . I can design a Skin ( template ) for VirtueMart which is more beautyful than Magento’s skin.Certainly,Virtuemart is faster than magento.
Now i must to use Virtuemart for my Store . In the furture,if Magento’speed is better than now,i will use Magento.
But not now.
i am coming from the World of asp.net an di am looking to go over to PHP open source i saw the functions that Magento if offering and i couldn’t believe it that we can get it all for free and open source but when i download it and start testing it i was really disappointed there is not way any one can put such a system in production the speed is so bad!!!!!!!!!!!!!!!!!!!! this will drive customers away forever from the Shop
i am really wondering if Magento has any plans on what they are going to do about it
Crikey.. I just logged into mysql administator and I am watching the number of SQL queries in real time. When I load a magento product category it spikes to around 120 queries. 120 mysql queries to load 4 products! what in the holy hell… can anybody explain this?
The EAV paradigm is great for fast system evolution and extensive end-user flexibility, but those benefits most often come at the cost of execution speed due to the cost of continuous interpretation of declarations to manifest the working environment and structures. Over time I imagine that Team Magento will improve caching as well as pre-materialize more critical portions of their implementation, perhaps by way of some sort of EAV compiler.
I justed set up magento on linux system. My pageload times are not really bad:
startpage : 0.9sec
cart: 1.6sec
Add to cat: 2.5sec
I have runing it on Dell Serversystem with Xeon 3230 and 4GB RAM.
If I am going to test concurreny I always get a bad result.
ab -n20 -c1 <magentoindexpage> : I get 6 requests per second
ab -n20 -c3 <magentoindexpage> : I get 4 requests per second
ab -n20 -c5 <magentoindexpage> : I get 3 - 3.5 requests per second maximum
If I increase from -c5 to -c.... I get everytime not more than 3 requests per second.
If I run ‘ab’ with these values against the same host but not on magento index page but on info.php (just <?phpinfo();?>)
I get values round about 190 requests per second.
I can see, that the context switch value is growing up to 400k per second, but I can not explain, why this happens.
Has somebody any help for me?
Ah, and I am changed from apc to xcache and get a really better performance. Also I use cachefiles in tmpfs + sessions in memcached.
