Magento page loading taking too much time

Question

I have magento website. There are no any users (max 2-3 at time).

Our server is: CPU: 2000MHz RAM: 2048Mb HDD: 50000Mb.

I installed ZendServerCE (apc + memcached + Zend Optimizer + Zend Data Cache). I turned memcached off, because website loaded much worst. I set flat type structure, reindexed and cached data in admin console.

So I have apc + Zend Optimizer + Zend Data Cache.

1. The first problem is I checked runtime how does dispatch work. start_session() calling takes about 500-700ms. Seems its not good result. Why so long, I don't know.

2. I've read this one: http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_key_buffer_size and figured out optimal options for my server.

Per hour:

Key_read_requests = 8887
Key_reads = 252
Key_write_request = 187
Key_writes = 146 

You see that 252/8887> 0.01, but not too much. It's optimal value I have ever get. Other results started from> 6.

Here is my.cnf:

key_buffer = 48M
myisam_sort_buffer = 2M
sort_buffer = 2M
read_buffer_size = 2M
join_buffer = 2M
read_rnd_buffer = 2M
max_allowed_packet = 128M
thread_stack = 192K
thread_cache_size = 16
query_cache_type = 1
myisam-recover = BACKUP
max_connections = 50
table_cache = 256
#thread_concurrency = 10
query_cache_limit = 8M
query_cache_size = 98M

3. Memcached for some reason wasn't good. I turned it off. But zend data cache and zend optimizer still work.

4 . APC seems correct. To load controller action takes 3-4seconds for the first time (I set die() there to check it) and for the first time it take 1 - 1.3 seconds.

5 . After several minutes I've restarted mysql I got good result. Pages were loading from 1.5 to 2.5 seconds. But now (after several hours) it takes 6-10 seconds. I cannot find the reason.

So do you see some incorrect configuration here? May be my server doesn't suitable for magento?

UPDATE 1: about 600 categories and 1000 products today and about 20000 categories (for different webstores) and 1500-3000 products in the future.

There are not many attributes.

UPDATE 2 I've nocied that ssh console works too slow. I rebooted server and now it works fast. it means I have a problem with RAM. There are not enough space.

It's initial status whiout apache:

 total used free shared buffers cached
Mem: 2048 600 1447

UPDATE 3 I got it. Now it is loaded for 0.5-1.5 sec

Here is configuration: mysql

[mysqld]
key_buffer_size = 256M
tmp_table_size = 32M
max_heap_table_size = 32M
myisam_sort_buffer = 4M
sort_buffer = 4M
read_buffer_size = 4M
join_buffer = 4M
read_rnd_buffer = 4M
max_allowed_packet = 64M
thread_stack = 192K
thread_cache_size = 16
query_cache_type = 1
myisam-recover = BACKUP
max_connections = 20
table_cache = 1024
innodb_buffer_pool_size = 128M
query_cache_limit = 24M
query_cache_size = 256M

php

[apc]
apc.stat=1
apc.enabled=1
apc.optimization=0
apc.cache_by_default=1
apc.shm_segments=10
apc.shm_size=256M
apc.ttl=0
apc.user_ttl=0
apc.num_files_hint=10000
;apc.mmap_file_mask="/tmp/apc"
apc.max_file_size=5M
apc.enable_cli=1
apc.mmap_file_mask="/tmp/apc.XXXXXX"
apc.slam_defense=0
apc.user_entries_hint=10000

All works perfect, but one question remains. APC shows me this statisic: enter image description here

Why hits so small? Any ideas?

• Tim Bezhashvyly: It would be nice if you drop couple of lines about your Magneto installation (e.g. catalog size, modifications, extensions etc).
• Ben Lessani: There is no way someone can just post a series of configuration files for you to be able to properly set up your server. There are dozens of files; specific revisions of software and system level changes that need to be made to make the best of your available hardware.
• Anthony: Please descibe why do you set downvote
• Anthony: @Tim I updated question
• philwinkle: I would drop in xhprof and try to get a visualization of what is taking the most time to load. Is this a production server under load or merely for testing?

Answer 1

As the question seems to be not very magento centric, here is my not very magento centric answer.

OpCode caching and DB optimizations are a good way to accelerate your web applications to some extent. But the benefit will be relatively moderate. To get a real speed boost you should consider using varnish cache. It is open source, easy to configure and easy to integrate with magento thanks to freely available modules for magento.

There is also a good article with a brief overview of how it works: http://www.fabrizio-branca.de/make-your-magento-store-fly-using-varnish.html

Especially consider the chart:

pages/second

• Ben Lessani: Varnish is great if you've already got a fast store and want to offset resources. But it should never be used to hide the fact a store is slow. The pages still have to be generated in the first place - so they'll always be 6-10s page load times, regardless.
• Anthony: Seems it would be like memcached I've used before. I think I do smth wrong in mysql properties or server is too weak

Answer 2

If your business is reliant on your hosting performing well, why are you trying to administrate the server with no experience.

You surely would benefit just by contacting a specialist Magento host and letting them take care of the system administration, whilst you do what you are good at, managing your store.

Looking at your specs, you don't have enough RAM to be trying to run a Magento store. There is a load of similar questions like yours,

https://serverfault.com/a/400748/113375.
https://serverfault.com/questions/430565/magento-hosting-on-a-budget

• Anthony: Because our client has limit budget. I should pay for magento host more than 50 euro per mounth. We have a limit for host 150-200 euro per year-) Anyway thanks for the links
• user2935: Then the client can expect to make ~20ドル-40,000/yr revenue with 100% optimisation (hosting is 0.5-1% of revenue). Plenty of people here who can give you all the details and technical settings, but you are trying to do to much with too little. You might get it to work on the technical side, but on the business side it will fall flat. Unless your dynamic pages loads (without fpc) are under 3s you lose 56% of visitors, ideally targeting 1-2s - Google and visitor conversions will punish the site otherwise - tough call. Given the situation a 95-99% chance >3s page loads and/or site goes under.

Answer 3

Is this physical hardware or a virtual private server? You should probably move your database to its own dedicated server. This also gives you the benefit of being able to isolate whether your speed issues lie with Apache/PHP or with MySQL.

start_session() being slow means you are probably suffering from underpowered hardware. I don't know whether your technology choices mean that sessions are stored on disk or in RAM but 500-700ms almost certainly means they're being stored on disk and you're having I/O performance problems -- probably because your database is swapping to disk because it won't fit in RAM...but that's all speculation.

Good luck!

• Anthony: Thanks for your answer! I use VPS. It's not much suitable for magento but I have a task to optimizate it in this scope. Is it possible to check is database swapping to disk?
• Ralph Tice: free -m will tell you if you're using swap at all, and the very latest versions of the top command will tell you if press O and P to order by swap usage. Otherwise you have to fall back to using the process id of mysqld with something like this: awk '/^Swap:/ { SWAP+=2ドル } END { print SWAP" kB" }' /proc/$(pidof mysqld)/smaps All described here: dbasquare.com/2012/04/10/…

Answer 4

There is obviously no way to show you a 'working config' that will increase your performance, but Magento does actually attempt to do something like this and posts an example of a highly configured LAMP stack in their performance whitepapers. The methodology of these whitepapers applies to CE and EE. I highly recommend reading through both whitepapers completely as the ideas suggested there echo much of this thread and provided very specific Magento recommendations, directly from the source: http://www.magentocommerce.com/whitepaper/

Answer 5

Configuration

ZendFramework (zend optimizer and zend data cache) + APC + Memcache + Nginx

works perfect for me.

more than 30 concurent users can load page less than one second (~0.4s-0.6s)

I set nginx at 80 port ( as a proxy) and apache at 8080.

Thanks to @MattSchweers for the links. I forgot about it. It helps me to configure MySQL

• user587: no problem! I actually used those whitepapers for some MySQL tweaking myself this week - worked well.

Answer 6

in my experience litespeed server boosts performance 2 x well worth the 32ドル/month 1cpu license. I was told that you only need the 1cpu license since php runs seperate in litespeed.

• Ben Lessani: The web server isn't the bottleneck. PHP is, changing to Litespeed won't change anything at all.
• Preston: While I generally agree that Litespeed is a great choice for Magento, this answer probably won't fix the problem posed by the OP and it is outside of his stated budget.

Answer 7

When you have multiple webstores and multiple categories, Magento is essentially creating kind of a caretsian product of entries for all the webstore, categories and products, which is going to put a significant load on the Database. Your APC misses are quite high, and you'll need to look into it. However even if you do fix APC I think your performance problem may will persist especially if your traffic increases.To speed up your site you'll need to install an op cache, either Varnish or Full page cache (if Enterprise Edition).

Magento does a lot of read writes to the DB so you can also try to have your MySQl in a Master Slave replication mode had have all the magento reads from the slave, while the writes happen to the master.

Answer 8

I would try changing the following APC options and see if the hits pick up.

apc.shm_segments 1

apc.ttl 7200

apc.user_ttl 7200

On a live site you can use the following too.

apc.stat 0

This will stop APC checking if the file has changed since it was last compiled, giving you a nice speed boost. Just don't forget to flush your APC cache when you edit PHP files.

Answer 9

Couple other thoughts. You might want to increase your innodb_buffer_pool_size, 128M can be a bit low and even small sites can out grow that pretty quickly. The variable dictates how much of your data is kept in memory.

Magento uses this for all it's tables including the log tables which grow every quickly. You will want to make sure you limit the amount of this data you are keeping. Running "php shell/log.php --status" from the command line will give you an idea of where you are at and if it's getting out of hand. There are also options for cleaning the log tables with it.

2GB of RAM is not much to work with so you do need to be careful about where you allocate your memory.

Also a Full Page Cache + Cache Warmer can help keep your site's catalog and cms pages primed and fast. You can see ours here: http://ecommerce.brimllc.com/full-page-cache-magento.html