Virtuemarts scalability

[craigieb]

Hi guys,
I've been using Virtuemart for the past 12 months and have developed three sites using it - with www.pop-up-tent.co.uk being the most successful and receiving an average of 6000 visitors a month.

I've spent countless nights trawling for answers to fix things like the SEO issues with Sh404sef but on reflection I've found it to be a great platform.

Now, my next ecommerce project is to be for myself and to this end I am planning a site that I hope will be getting monthly visitors in the region of hundreds of thousands. To this end I'm curious if anyone has had this kind of exposure whilst using Virtuemart. Also - at what point is Virtuemart going to struggle when dealing with vast amounts of traffic?

I'm currently researching my opinions for this venture and would love to hear more from VM developers to get a feel for just how ambitious a project VM can handle.

Kind Regards
Craig

[dorjano]

100 of thousands? O boy! You should look at ASP not PHP script. As ASP final code is in c++ it's the fastest way of handling data.

Of course this kind of traffic does require a lot of resource - meaning a big investments. Ok, you may say that you will not aim at that kind of traffic from the beginning but you have to plan to that number. You see, it's quite impossible to change e-store later on.

I'm not a DEV of VM although, I just rewrite some partitions of VM, so you / we really should wait for a appropriate answer :-)

[craigieb]

Thanks for the response - I suppose the next logical question is "how many visitors would I need to be receiving before I would require to update my e-commerce solution"?

In terms of graphics I have a template for Virtuemart which is also available for Magento so porting the site look and feel is fairly straight forward & by that time I believe we have the funds to develop a much better platform (and make a substancial donation to VM ).

Any advice?

Cheers
Craig

[Scar]

I've heard a lot of people complain about Magento suffering heavily from performance issues. So was the brief test I did with Magento. So I would definitely go with VM.

In the Joomla forum there are several very interesting discussions about Joomla scalability (with your amount of traffic) and I'm pretty sure you could get it working like that with VM as well.

[dorjano]

My 2 cents about Magento. Magento really shows the limits of a e-store developed on PHP. PHP was not developed to run such a huge traffic. And beside that Magento has a very very complex structure... And yes it is sloooooow. I was disappointed too.

[Erik P]

My 2 cents about Magento. Magento really shows the limits of a e-store developed on PHP. PHP was not developed to run such a huge traffic. And beside that Magento has a very very complex structure... And yes it is sloooooow. I was disappointed too.

Magento has scaling problems, because of their use of an EAV database structure -- a database within a database. Its slow operation and very complex structure is also the result of that.

I've blogged about the EAV problem here:

http://sankuru.biz/en/blog/8-joomla-configuration-issues/35-the-cck-buzz-content-creation-kit-and-the-eav-problem.html

I also blogged about the massive performance issues that it creates for Magento installations, and other EAV-style databases:

http://sankuru.biz/en/blog/7-figuring-out-compiler-technology/42-the-eav-database-performance-problem.html

Virtuemart does not suffer from this problem, because it does not use an EAV-style database. This is the number one reason why Virtuemart is more scalable than Magento (but also less flexible).

These performance problems have nothing to with the use of Php or any other programming language. It has everything to do with the design method used to enable flexible database schemas.

The Php scripting language may not be perfect, but the dot.net languages in use for ASP.NET, such as C# and VB.NET are to be considered to be even more imperfect. I've blogged about the issue here:

http://sankuru.biz/en/jobs.html?start=6

The idea that one language such as C++, Java, or C# could cover the entire range of programming, from low- to high-level, is increasingly being abandoned. With the growing use of scripting languages such as Php, Python, Perl, Ruby, and Javascript, the market is finally vindicating Ousterhout:

http://home.pacbell.net/ouster/scripting.html

[Erik P]

As ASP final code is in c++ it's the fastest way of handling data.

Ceteris paribus, assembler will generate the fastest code, followed by C, and a few other similar bare-metal, statically-typed, non-object oriented languages. But then again, the speed of the algorithms very quickly trumps the speed of the code.

For example, looking up data in a hash or a btree, will eventually always outperform, scanning an entire array of the same data. Beyond a certain size, the program using a hash, even when written in the slowest possible language, will outperform the program scanning a table, written in the fastest hand-optimized assembler.

We can safely state that sites are almost never slow, because of the slowness of the language in which they were implemented, but because inefficient algorithms are being used in performance-critical points (deeply nested innermost loops).

Furthermore, CMS systems like Joomla and webshops like Virtuemart, spend most of their serverside CPU cycles inside the database, retrieving data through the SQL language. The database engine (MySQL) itself is written in heavily optimized C and uses relatively efficient algorithms (not always, though).

If you want to see massive performance gains in this kind of systems, the way to go is to look at whether the SQL queries are optimal in terms of performance, the recommended indexes are present, and whether caching is sufficiently well configured.

In my experience, the Joomla and VM queries are quite well done, and most of the recommended indexes present. I haven't seen any low-hanging fruit in that respect in the Joomla or VM source code. Concerning caching, it is up to site admin to configure this in a judicious way.

Magento's lacklustre performance and lack of scalability, however, cannot be salvaged. That thing will always and forever be slow, no matter what you try, and the more data you load, the worse it will get. Indexing hardly helps, because the queries generated in an EAV context are so complicated, that the database engine can hardly ever compute correctly what alternative access strategy would avoid the costly (entire) table scans, for which EAV databases such as Magento, have become notorious.

Facebook is written in Php and scales perfectly well, regardless of the fact that it is being pounded by 300 million users. As you can see, the problem is really not Php. As stated above, the problem is almost invariably elsewhere.

[proud.joomla.user]

okay, my two cents, there are some pretty big websites out there running VM, like anything in this world that comes out of the box. Start your business and be successful, when that time comes as it did for me and some of my clients, about 350,000 visitors a month, we had to approach this dilema with a a simple approach, VM offers the BEST platform for SEO, period, total control VIA components and plugins. VM also allows total flexibility and with some changes can do anything you want it too.

Our approach was simple, php up front does not ever really lag, as long as you are NOT on a shared server and do have a FAST connection none of this 20mb business. next, you need to make sure that you keep your files optimized as well as your server.

Next, we took special care of MySQL to make VM and the site FASTER and FASTER as well as some core changes to VM that allowed certain commands to be excuted quicker.

While also creating certain security needs, we made some changes along the way, however, we can upgrade to latest build with relative ease less than 15 minutes.

if you get to the point where scale matters so much, about $15,000 will get you someone to really improve the cart as well as mysql as well as a proper dedicated server. rackspace or pier1.

hope this helps