Php DigitalOcean服务器上的Magento

我在Digital Ocean服务器上运行Magento store时遇到问题

这是我的液滴配置：

2GB Ram | 40GB SSD Disk | New York 2 | Ubuntu Ubuntu 12.04.3 x64

max_execution_time  30
max_file_uploads    20  20
max_input_nesting_level 64
max_input_time  60
max_input_vars  1000    
memory_limit    512M

当我使用Magento商店时，它正常工作，除非我尝试创建帐户或进行购买

然后需要2分钟完成购买

我在本地下载了整个站点（使用db），订单和创建帐户只需几秒钟

我尝试过将droplet升级到4GB内存，但还是一样

这是我的php配置：

2GB Ram | 40GB SSD Disk | New York 2 | Ubuntu Ubuntu 12.04.3 x64

max_execution_time  30
max_file_uploads    20  20
max_input_nesting_level 64
max_input_time  60
max_input_vars  1000    
memory_limit    512M

我不知道如何继续调试这个。有人能给我一些建议吗

更新#2（基于MageWorx的UPD）： 根据MageWorx（更新）的建议，我在服务器上运行了mysqltunner。结果如下：

[OK] Logged in using credentials from debian maintenance account.
[OK] Currently running supported MySQL version 5.5.38-0ubuntu0.12.04.1
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM 
[--] Data in MyISAM tables: 25K (Tables: 28)
[--] Data in InnoDB tables: 36M (Tables: 1386)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[--] Data in MEMORY tables: 0B (Tables: 68)
[!!] Total fragmented tables: 1387

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 49s (338 q [6.898 qps], 71 conn, TX: 181K, RX: 51K)
[--] Reads / Writes: 92% / 8%
[--] Total buffers: 832.0M global + 2.7M per thread (100 max threads)
[OK] Maximum possible memory usage: 1.1G (54% of installed RAM)
[OK] Slow queries: 0% (0/338)
[OK] Highest usage of available connections: 2% (2/100)
[OK] Key buffer size / total MyISAM indexes: 32.0M/178.0K
[!!] Query cache efficiency: 12.9% (30 cached / 233 selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 12 sorts)
[OK] Temporary tables created on disk: 25% (57 on disk / 222 total)
[OK] Thread cache hit rate: 97% (2 created / 71 connections)
[OK] Table cache hit rate: 25% (1K open / 6K opened)
[OK] Open file limit used: 1% (104/8K)
[OK] Table locks acquired immediately: 100% (248 immediate / 248 locks)
[OK] InnoDB buffer pool / data size: 512.0M/36.8M
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Enable the slow query log to troubleshoot bad queries
Variables to adjust:
    query_cache_limit (> 4M, or use smaller result sets)

以下是ApacheBody的结果：

Your server has 2002 MB of memory
The largest apache process is using 39.78 MB of memory
The smallest apache process is using 15.04 MB of memory
The average apache process is using 17.32 MB of memory
Going by the average Apache process, Apache can potentially use 433.00 MB RAM (21.63 % of available RAM)
Going by the largest Apache process, Apache can potentially use 994.50 MB RAM (49.68 % of available RAM)

Generating reports...
### GENERAL REPORT ###

Settings considered for this report:

    Your server's physical RAM:     2002MB
    Apache's MaxClients directive:      25
    Apache MPM Model:           prefork
    Largest Apache process (by memory): 39.78MB
[ OK ]  Your MaxClients setting is within an acceptable range.
    Max potential memory usage:         994.5 MB

    Percentage of RAM allocated to Apache   49.68 %

---

我对各种Magento开发/登台站点使用了精确的Digital Ocean配置（就RAM和SSD而言，我的配置在Centos上，并带有默认的PHP.ini配置），它们工作正常，所以我认为服务器配置不是问题。它必须是模板或模块中效率低下的代码

我会为它开始分析

我仍然使用AOE探查器模块，我认为它使生活更轻松

我也会运行n98，看看是否有模块冲突

---

然后，如果您仍然找不到它，请切换到默认主题，并开始禁用模块以查看它是哪一个。

我敢认为问题是由于缺少mysql设置优化造成的。关键是，如果不优化mysql，您将无法提高网站速度，因为mysql不会使用100%的服务器资源

以下是2Gb水滴（/etc/mysql/my.cnf）的基本设置：

由于这些是基本设置，您可以使用该应用程序进一步优化mysql。

UPD:

从mysqltuner的结果中可以看出，您需要尝试以下设置：

skip-networking
query_cache_limit = 4M
query_cache_size = 256M

thread_concurrency = 4
table_open_cache = 4096
innodb_buffer_pool_size = 512M
join_buffer_size = 1M

还要注意，在对my.cnf文件进行更改后，不要忘记重新启动mysql

sudo service mysql restart

---

应用设置后，测试网站一段时间，然后启动mysqltuner查看结果

嗨，谢谢你的评论。我检查了站点代码，因此它肯定与代码无关。因为，我尝试在共享主机上使用相同的代码。我在服务器上创建的mysql或php配置可能有错误。我还检查了该服务器上的fresh Magento安装，结果相同。啊，我很遗憾，我没有理解你关于在本地将其拉下来并在那里正常的观点。我会把这个答案留给一般的调试链接。好的，谢谢，我投票选了你的链接，因为它对Magento的调试很有用。无论如何，谢谢你。嗨，MageWorx，谢谢你的回复。我用MysqlTunner结果更新了我的问题。我看到这个项目上有两个感叹号：Total fragmented tables。我应该做点什么吗？你有什么建议吗？谢谢，谢谢你的更新。我更新了那些设置，但还是一样。我还添加了来自mysqltunner的新结果。我应该对碎片表的总数做些什么吗？也许这就是导致它变慢的原因。就mysql而言，您需要运行命令“mysqlcheck-u username-p--auto repair--check--optimize--all databases”，我还建议您将php的max_input_vars设置增加到5000I做了所有这些，但结果仍然相同。我联系了digital ocean以获取更多信息。我还安装了ApacheBody，并从中添加了结果。仍然是相同的行为。要回答这个问题，我们需要获得以下详细信息：您使用什么作为邮件服务器？（SMTP还是内部）？从你的工作电子邮件发送的电子邮件是否到达收件人？您使用的是哪个版本的Magento？你网上商店的产品数量是多少？您在商店中使用的扩展是什么？邮件服务器是解决方案！所以一开始我并没有做任何事情来设置邮件服务器，这就是为什么发送一封邮件需要2分钟的原因。所以，我刚刚设置了Postfix邮件服务器，它就像一个符咒。你能添加电子邮件答案，这样我就可以接受了吗？