If Magento cart code is too poorly written and you would never use it for your own store, why are you wasting your time here?
Do you think that person who uses open source technology are not serious???
C´mon, I think that you should review your concepts!
I’ve bodged the script that dumps all of these together, basically Variens version does not output contents (flush() for those php savvy) and instead read all the files into a string and then set appropriate headers (bodged in this version).
My version reads the same as Variens version, but instead of saving to a variable immediately dumps to the end user and flush()’s to the browser.
Limitations by my implementation:
* I by default do not accept different contentTypes that Varien have implemented but do not use (commented code)
2.6 secs Using Variens code
1.1 secs Using my adapted version of Variens code
Please note, i have tried multiple files instead (which can be achived doing the alteration as explained below (couldn’t find the admin function, bodge > all)::
Magneto is a very poorly written cart when you look past the pretty graphics it has. I would never use it for my own store. Any person serious about their online business would spend a few extra bucks to get a cart like volusion or interspire.
Volusion is ASP. Anyone suggesting ASP in the same breath as “professional” needs counseling. Interspire has some merit if its claims are true. Nasty price tag though. If I can get magento to be the magic bullet for my site, then one year after implementing it, I will stop by Varien’s offices in LA and give them $1000 (minus any $$$ I potentially pay Varien for tech support. ).
If you do a WHOIS of their domain, it comes up with with some reference info in Australia. The Wilshire address listed on that page may be just a virtual office address as far as I can tell. A ton of businesses come up when doing a search of that exact address with that exact suite number. Maybe I’m just paranoid
Really guys. I’ve seen a lot of posting on here about hosting Magento SimpleHelix is the best. They are also very user-friendly and help you whenever you need anything. I tried several other hosting companies and ended up using their 30-day cancellation guarantee. Have been with SimpleHelix since.
Speed varies greatly from hosts to hosts so I advise you to read some reviews on the boards or google for a fast magento hosting company.
Because, ofcourse, anything over 10 seconds is way too slow. -_-
I happened to look at the magentify.com site. The Best Selling products module links are 404 just like my demo installation. Only difference I can see is your thumbnails and images are working properly.
I don’t think hosting is where the speed solutions are going to come from. Has anyone got any tips for making images quicker, e.g. pulling them from a different url so that more than one http request can be made at a time? Also, why is so little cached when every caching option is turned on? Category pages *should* load in the blink of an eye if they have been loaded before, but they do not. Does anyone have a recommendation for max products in a category? Or total sku count (if using configurables)?
There is simply no ways around it: Magento is super slow. The main reason for this speed is its complex and overly architected data structure. I mean to save a new product you are talking about 200+ DB transactions, not including table locking… The only way to speed it up in its current form and current version is by turning caching WAY UP all around: Apache caching, PHP caching, browser caching, and DB caching.
I really hope that Magento is working on solving these issues because it may just be Magento’s achilles heel. Here are a few ways I can see how Magento team can actually speed up their product:
1. Allow more serious collection operations: for example: getAllProducts(), getAllCategories(), etc. but I mean GET ALL including all its attributes, stock items, etc. Same goes to the setAllProducts(), etc. I looked at the current collection structure and when you have a collection of products and run collection->save() all it does is go through each product and saves it. ok, this is great theory but bad practice. Modern DB’s are much faster when you give them all the instructions and data and have them do it for you.
2. Simplify Attribute Engine - yes, it is great that you have 5 tables for each entity or option but is it necessary? are you saving space? performance? none! just add another column ‘text’, ‘int’, ‘varchar’, etc to each record and you are done. Yes, waste space for each record but you will still save speed and space long run.
3. When saving multiple products, categories, attributes (at least when you eventually will implement it...) lock the whole operation as one, not the individual transactions.
4. Open easier and more direct access to your DB model, at least for the read operations. Many times I need to load a product, i.e. Mage::getModel(’catalog/product’)->load($outOfStockProductId) and it brings the ENTIRE product into memory I change only one attribute, like product price and save it. Why would I need all the rest of the data? inefficient.
5. This one will not solve any speed issues, only my headache - offer better documentation. Truth is, for developers you don’t offer much. I spent more time reverse engineering your product than any other. You have pretty code but please, document it as well!