Renoir Boulanger Un geek social et Linuxien de nature

Some steps you can look for if you feel your web application is slow

A peer asked for opinion about things to consider to use cloud computing services. I assumed then that he meant that he wishes to use what some vendors sells as "flip the switch" scaling.

It all started by a discussion thread in a mailing list. A guy who developed a shopping cart and payment gateway using a CMS.

My first reflex, before thinking of scaling the server I thought I should give some pointers on things that can hog the site, before going to think to scaling solutions.

That was all before continuing talking on the cloud that I answered later that I answered later on that blog post.

The thread started as follows:

> (…) I have a Magento modified into a e-commerce site (…) that
> me and my client feels slow, my client has asked about Amazon hosting. They
> do everything else, CDN, the works, shouldn’t their hosting
> be superior?
>
> What would be worth for a test drive, I’d say, if you think
> your site’s performance issues can be addressed by
> throwing CPU, memory, storage, etc (…)

My answer

I doubt that you need bigger hosting for a e-commerce site.

Not for the “first  thing to improve performance” action point though.

Unless your site has to provide (real) HEAVY traffic. Non stop.

It is most likely something somewhere down the execution of the web application that requires to be looked at.

Performance slowing factors

Some common explanations for slow execution time could be basically due because of one or many of the following:

  1. Network latendy
  2. Process communication problem (connection, zombie process, etc)
  3. Application architecture
  4. Hardware/Software performance

Now talking about application architecture.  This one can be a real can of worms!

Some Application architecture bottlenecks

I currently seriously doubt the order here should matter. But this is the ones that pop into my mind at first.

  1. Web service/database queries/files access across network … packetloss could also be a cause
  2. Database queries processing that could require some well picked indexes
  3. Heavy queries and frequent read write or some sleep() hidden here and there to wait other result set
  4. No http/view caching
  5. No code caching/precompiled code at all (can be config, whatever that can be pre-compiled and served into basic arrays of calculated data frequently used)
  6. No memcached/keystore service
  7. No read-only data store

An analogy

So. To my opinion, if you are using a “unpack to install” web based software such as WordPress, then add plusings without testing and looking if all of them works well together.

You are likely to be trying to make a Cheetah kitten into a humanoid Android.

As in,  you can install a lot of metal patches. Doesn’t mean it will have a full AI system and be self sustainable.

That is to illustrate, what it is lie, you should look to alternatives. At least with something closer to a droid :)

Seriously enough.

My professionnal recommendation would be to work with each “application architecture buttolenecks” proposal list before “going cloud”

Comments are closed.