Hello all,
We did some test of Magento front page opening time for different configurations regarding CGI/mod_php/NFS/caching. You may find the results interesting. See:http://byte.nl/blog/2008/09/03/speeding-up-magento/
Best regards,
Wojtek Burakiewicz
I came across these good pages to optimise MySQL on the net and was wondering if anybody had any bad thoughts about it before i try it!
This one does make a lot of sense as to why a query would be better than other ones…
They must match byte for byte: so SELECT and select
wil not be reported the same, thus tiying more ressource to it instead of grabing it from the cache. An d did you know that the Default cache size gfor MySQL is 0M. I did not if this guy is said true.
Yes - Chrome executes scripts etc. 2x faster, so that will make a diiference. But then - you can not expect the majority of your visitors to suddenly start using Chrome.
What we need is Varien to step up and optimise Magento. For all browsers.
WOW! Guys, at least this little web adress is giving a super good heads start on what params to add in the my.cnf SQL file in order to optimise the whole server.
Here is the output that this file gave me:
—MYSQL PERFORMANCE TUNING PRIMER --
- By: Matthew Montgomery -
MySQL Version 5.0.45 i686
Uptime = 0 days 15 hrs 14 min 53 sec
Avg. qps = 1
Total Questions = 56984
Threads Connected = 2
Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations
To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL’s Enterprise Monitoring and Advisory Service
SLOW QUERIES
The slow query log is NOT enabled.
Current long_query_time = 10 sec.
You have 0 out of 57007 that take longer than 10 sec. to complete
Your long_query_time may be too high, I typically set this under 5 sec.
BINARY UPDATE LOG
The binary update log is NOT enabled.
You will not be able to do point in time recovery
See http://dev.mysql.com/doc/refman/5.0/en/point-in-time-recovery.html
WORKER THREADS
Current thread_cache_size = 0
Current threads_cached = 0
Current threads_per_sec = 1
Historic threads_per_sec = 0
Your thread_cache_size is fine
MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 2
Historic max_used_connections = 7
The number of used connections is 7% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory
See “MEMORY USAGE” section to make sure you are not over-allocating
MEMORY USAGE
Max Memory Ever Allocated : 36 M
Configured Max Per-thread Buffers : 268 M
Configured Max Global Buffers : 17 M
Configured Max Memory Limit : 286 M
Physical Memory : 1007.05 M
Max memory limit seem to be within acceptable norms
KEY BUFFER
Current MyISAM index space = 22 M
Current key_buffer_size = 7 M
Key cache miss rate is 1 : 6
Key buffer fill ratio = 0 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere
QUERY CACHE
Query cache is supported but not enabled
Perhaps you should set the query_cache_size
SORT OPERATIONS
Current sort_buffer_size = 2 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine
JOINS
Current join_buffer_size = 132.00 K
You have had 311 queries where a join could not use an index properly
You should enable “log-queries-not-using-indexes”
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.
Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.
OPEN FILES LIMIT
Current open_files_limit = 1024 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine
TABLE CACHE
Current table_cache value = 64 tables
You have a total of 939 tables
You have 64 open tables.
Current table_cache hit rate is 0%, while 100% of your table cache is in use
You should probably increase your table_cache
TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 4461 temp tables, 34% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your
ratio of on disk temp tables.
TABLE SCANS
Current read_buffer_size = 128 K
Current table scan ratio = 12 : 1
read_buffer_size seems to be fine
TABLE LOCKING
Current Lock Wait ratio = 1 : 59505
Your table locking seems to be fine
Anyone else have tips on improving magento’s speed? My site is still terribly slow. Specifically, some operations such as saving a category. That seems to be because every category save requires the entire category cache to flushed (takes 7 seconds on my test server to do this).
However, even normal page loads take up to 10 seconds. Any speed improvements coming in 1.1.7?
-minify js
-serve gzipped css files and php pages
-enable cache in the store
-DO NOT USE THE DEFAULT THEME IMAGES - optimise them ALL
-use css sprites if possible
-remove the default XML Layout Update (Under Custom Design) from the home page CMS
-check with Yslow/Firebug (add etags, expire headers etc)
Anyone else have tips on improving magento’s speed? My site is still terribly slow. Specifically, some operations such as saving a category. That seems to be because every category save requires the entire category cache to flushed (takes 7 seconds on my test server to do this).
However, even normal page loads take up to 10 seconds. Any speed improvements coming in 1.1.7?
I noticed that this insane page load time may occur when you serve Magento using mod_php.
I traced it a bit using xdebug and this is my theory:
Magento files belong to some user/group (say UID1:GID1) that can be read by the webserver.
When the frontpage opens, Magento does some crazy computations (one function is called 17000 times) and I think it then fails to save the result, so it is recomputed every time. This is because PHP scripts run by mod_php have the uid/gid of the webserver, like www-data:www-data and cannot write to directories belonging to UID1:GID1.
Switching to CGI mode reduces the time (I added “AddType application/cgi-php5 .php” to VirtualHost definition) from 5-10seconds to 2-4.
That’s because Magento then runs with UID1:GID1 and can write everywhere it should.
lisali, what do you mean by:
-remove the default XML Layout Update (Under Custom Design) from the home page CMS
It may have something to do with the issue described above as the most called functions come from
Varien_Simplexml_Element (asNiceXml,extendChild).
Have a look in the admin. CMS>>Manage Pages>>Home>>Custom Design
The “Layout Update XML” box is pre-populated with functions and calls, all of which can be removed without any apparent problems (in my case). Not sure why they are there in the first place.
Can someone with more knowledge try this extension for php if this helps, I lack the knowledge of getting it to load, i just get an Undefinen function… error:
I see where you are going with the UID and GID theory - however I have not been able to configure my server to run in cgi mode - I need to rebuild my httpd.conf file for that.
Can I set all my files and directories to apache.apache for uid and gid or would that be morally wrong?
Sales: Call 877.832.5289 (N America)|310.295.4144 (International)
