There was a JS tweak in the support boards that many people said improved performance greatly. There also might have been a blog entry about that a while back.
I was always a big fan of actually having an HTML version that gets generated after any modifications, this way the HTML loads up Fast as can be, can handle 100k hits easily and people only go dynamic and slam the DB if they are in cart checking out. You do an Ajax shopping cart so they can browse HTML files still, everything on the file system so its pretty efficient. That worked for me in a previous cart where no matter what the server was getting slammed very bad and well with that workaround it was able to handle it without even flinching, only dynamic was people in cart, and that was fair enough.
We’ll be happy to help you make Magento work - you just must have reasonable expectations. Magento is not your standard ecommerce solution and as such it requires specific tuning. If you could provide your specs I am certain we can help to enhance your experience.
Thanks Crucial
My specs are dynamic, but i prefer centos dedicated server.
Ill install the stuff you tell me to install. Hardware is top of the bill server.
I have more then reasonable expectations, I want to be able to implement magento for small stores and larger stores.
Shopvisitors must become happy surfin and buying.
Shopowners must become happy administering their shop and not getting frustrated.
looks = 10
usability= 10
speed = 5
I want speed 8, is that reasonable?
You talk about clustering when more then 10.000 products used and other hardcore stuff, I think that big companies has got the budgets to develop a custom made store.
Small business entrepreneurs will look at open source solutions first.
And we developers can help them achieve their goals by implementing and customizing.
@Webtailor Mallorca - I suggest before you jump to conclusion you spend some time on the site reading users comments and going through the blog posts.
Dear Roy,
I dont want spend to much time reading, i just want to use this wonderfull product.
And that’s just what i did. On several platforms. And with 10 year php experience i think i am qualified enough to make this conclusion.
Offcourse I’ve looked what other people experienced, but i think the most people are overwelmed by the looks and the features.
Performance tuning can be somewhat of an art, but you must remember that the Magento PHP application is just one part of many things on your system that needs to be optimised. That said I’m amazed your shops are taking upwards of 5 seconds to add a product to the cart - I’ve installed the Magento sample data on a modest stock debian machine without any optimisations and I’ve never seen performance that bad.
There is already a wealth of information just a single search away that will help you speed up your Magento installation, and people are adding more all the time. There are also resources like the mysqlperformanceblog.com with even more tricks.
@Webtailor Mallorca - I suggest before you jump to conclusion you spend some time on the site reading users comments and going through the blog posts. A lot has been said about performance and optimization. In optimal environments, we are extremely pleased with the results and the product is more than ready for prime time. You will soon see enterprise grade clients launch on the platform - we’ll make the announcements once everything is ready.
Enough said from my end, I’ll let the community take over from here.
“optimal environments” please tell us the details. We have a new intel quad core and 8 gb ram. My grandmother run faster to a local shop an buy products
What kind of page generation times are you seeing on that hardware? To give you an idea, with just some basic optimisation I’m currently seeing 0.8-1.2 seconds to generate and deliver a catalogue page from the sample data store. This is on a dual-core AMD machine with 512MB RAM.
This is on a “server” with 2.2GHz Celeron (haha), 256MB RAM (HAHAHA), Etch LAMP + eaccelerator (check_mtime 0), Mage’s var dir on tmpfs (which I find useless, bacause system cache does the same), commented out Varien_Profiler::enable();
The machine is not supposed to host any production store of course and is located in Czech Republic.
nothing because you use sample data (under 500 products)
Koubas - 06 April 2008 06:55 AM
This is on a “server” with 2.2GHz Celeron (haha), 256MB RAM (HAHAHA), Etch LAMP + eaccelerator (check_mtime 0), Mage’s var dir on tmpfs (which I find useless, bacause system cache does the same), commented out Varien_Profiler::enable();
The machine is not supposed to host any production store of course and is located in Czech Republic.
It may not be apples to apples, but given his little server with “under 500” products is coming in at 3.3 seconds while my store with no products on the Grid Server is 16 seconds, I’d say he’s doing something right.
I’ve had some luck with the JS proxy.php change, but watching FireBug I can see it’s the creation and delivery of the large (~226KB) chunk of javascript which is killing the site load time. The page is often created and delivered in around 500ms which is great but it can take 5-10-20 seconds sometimes (on first visit) for the javascript be created and come down.
I do need to check the apache settings as it doesn’t seem to be compressing the concatenated script output, but I think a more aggressive caching of the concatenated output should happen - maybe something like the way the TinyMCE compressor works. I see the expires header is a year in the future, but browser/s don’t seem to be really obeying it. Secondly, should there be some packing of the scripts first? That might be worth a shot too.
Secondly, I’ve noticed on some pages (ie. compare the accounts pages to the front page) the size of the js changes as it’s delivering a smaller set of scripts. I’d have thought it’d be a better andm ore cachable design to have all the pages use the same set of scripts that way after one request its cached for everything else, otherwise you get a second performance hit.
Aside from that things seem to be going alright in a vanilla install incredible number of features - I think TinyMCE applied to the CMS pages is a must too.
I’m getting great to ok speeds on my test server at this link. Looks that with the right hosting, you can do wonders with it. This is a very little to none-tweaked server.
incredible number of features - I think TinyMCE applied to the CMS pages is a must too.
Sales: Call 800.374.8146 (N America)|757.278.0920 (International)
