我们的专用服务器正在运行一个大型Magento商店，其大小约为250MB。
服务器规格被列为具有5个Xeon 2Ghz处理器（4MBcaching）和12GB的内存。
我本来以为上面的规范足以让Magento很快地运行，不过虽然网站速度不是很慢，但实际上并没有那么快。
目前的MySQL my.cnf文件如下：
skip-innodb ft_min_word_len=3 query_cache_limit = 4M query_cache_size = 16M ## 32MB for every 1GB of RAM query_cache_type = 1 max_user_connections = 50 max_connections = 50 interactive_timeout = 300 wait_timeout = 200 connect_timeout = 200 thread_cache_size = 32 key_buffer_size = 64M ## 128MB for every 1GB of RAM join_buffer_size = 1M max_connect_errors = 20 max_allowed_packet = 12M table_cache = 1024 record_buffer = 1M sort_buffer_size = 1M ## 1MB for every 1GB of RAM read_buffer_size = 1M ## 1MB for every 1GB of RAM read_rnd_buffer_size = 1M ## 1MB for every 1GB of RAM thread_concurrency = 4 ## Number of CPUs x 2 myisam_sort_buffer_size = 32M tmp_table_size = 16M max_heap_table_size = 12M [safe_mysqld] open_files_limit = 2048 [mysqldump] quick max_allowed_packet = 12M 我已经看到一个build议my.cnf一个magento dedcidcated数据库服务器（2GB内存）：
query_cache_size = 512M
query_cache_limit = 256M
tmp_table_size = 256M
key_buffer_size = 64M
read_buffer_size = 128M
read_rnd_buffer_size = 128M
bulk_insert_buffer_size = 64M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 128M
myisam_max_extra_sort_file_size = 128M
myisam_repair_threads = 2
myisam_recover
innodb_additional_mem_pool_size = 256M
innodb_log_buffer_size = 128M
innodb_log_file_size = 128M
innodb_log_files_in_group = 2
innodb_flush_log_at_trx_commit = 0
innodb_buffer_pool_size = 512M
innodb_data_home_dir = / var / lib / mysql /
innodb_data_file_path = ibdata1：256M：autoextend
innodb_autoextend_increment = 32
我想知道是否有人能够build议给我们的规范my.cnf参数的最佳值？
另外如果有什么我应该知道的时候修补他们，如：设置这个太高，并期望灾难性的失败。
任何想法将不胜感激。 干杯。
当您对个人用户进行性能testing时，MySQL通常是Magento商店的最后一个瓶颈。 不过， my.cnf对于Magento商店来说看起来并不是最佳的，对于那个服务器规范来说也不是那么理想。 我在这里写了关于Magento的MySQL负载的详细答案，
https://serverfault.com/a/367856/113375
目前，您的最大努力将是通过其他方式（改变主机/优化模板等）来改善您的页面加载时间，并最后处理数据库。 这实际上仅用于并发testing和事务负载。
从 http://docs.sonassihosting.com/go_dedicated.pdf
根据你的CPU和总线速度的架构 – 使用下面的数字，你将能够实现的是0.8s的PHP页面渲染时间（不包括images / js / css）。
给你一个粗略的select硬件的概念
select服务器时需要记住两个数字，并发和页面加载时间。 并发性是您的服务器可以随时支持多less客户。 单个页面加载时间是单个客户页面实际加载的速度。
有可能有：
- 缓慢的页面加载时间和低并发支持（低时钟速度CPU（GHz），less量内核）
- 一个快速的页面加载时间，但低并发支持（高时钟CPU（GHz），less核心）
- 缓慢的页面加载时间，但高并发支持（低时钟速度CPU（GHz），大量的核心）
- 快速的页面加载时间和高并发支持（高时钟速度CPU（GHz），大量内核）
你可以根据这个select你的硬件。
并发
a）一个标准的Magento演示商店能够每小时提供大约230个每GHz的唯一身份。
b）一个典型的networking商店，pipe理员用户活动，开发活动，产品添加/删除可以看到这个降低了100％左右，每小时115个独特的频率。
c）build模较差/模板较大的商店可以将这一数字进一步降低100-200％，每小时每GHz降低50个。
当我们引用数字时，我们使用选项b）。
个人页面加载时间
一个标准的Magento演示商店（CE或EE – 当FPC被禁用时）能够加载主页：
0.7 seconds 2.4GHz CPU 0.6 seconds 2.8GHz CPU 0.51 seconds 3.3GHz CPU 0.48 seconds 3.46GHz CPU但是，再次，一个糟糕的/沉重的模板将导致这个数字呈指数增长。 当我们引用数字时，我们使用示例数据的演示商店模板作为示例。
上面的源代码摘自http://docs.sonassihosting.com/go_dedicated.pdf
我假设你有5个CPU – 你使用的是VPS（云或者其他），如果是这样的话，I / O可能会成为你的瓶颈，无论是磁盘还是networking。 不幸的是，由于VPS的冲突本质 – 它们从来都不是Magento托pipe的理想select，除非pipe理人员/公司对Magento优化有深入的了解，而且硬件没有竞争。
Magento的VPS下行
每个用户都有root权限。 这意味着系统上的其他VPS节点可以启动bonnie / iperf / hping，然后敲击无法分区/拆分的资源 – HDD I / O，networking或中断。 所以，即使你有保证CPU / RAM – 你是受共享子系统。
你有有限的CPU和内存 。 是的，您可以向上/向下扩展 – 但是在一天结束的时候，一个小型的Magento商店可以利用分配给MySQL实例的最less2GB内存，以及1GB RAM /逻辑CPU内核的经验法则。 所以至less，VPS应该有3GB内存和1个CPU内核 – 对于一个交易的Magento商店来说， 最多 （当经过适当调整的话）每天可以为大约1500位独立访问者提供服务 – 假设没有HDD I / O或networkingI / O瓶颈。
你必须自己pipe理它。 奇怪的是，现在一个电子商务网站的所有者和运营商也应该负责build立，监控和pipe理他们的托pipe基础设施。 店主应该把重点放在他们擅长的事情上 – 运行他们的业务，而不是试图解决错误，调整性能或者pipe理命令行Linux服务器。 最糟糕的情况是，当某些事情发生错误时，他们根本没有处理的经验，导致盲目的恐慌。
为了更好/更准确的答案，张贴一些关于你的商店的更多细节 –
我会跳过我可以写的大量文本，并获得直接点。
看看这些片刻：
max_user_connections = 50 max_connections = 50
Apache默认运行500个连接。 目前，如果有50个请求转到MySQL / MySqlI，将会被拒绝。