我已经实现了一个系统，人们可以通过 http post 将文件上传到 htdocs 中的 LAMP Stack 文件夹/目录。像这样的图像上传系统是否需要 CPU 功率多于内存功率，反之亦然？
我问这样我可以在 Google Cloud Compute Engine Bitnami Lamp Stack 中的高 CPU 或高内存机器类型之间做出更好的选择。
【问题讨论】：
标签： memory google-cloud-platform cpu-usage lamp bitnami
最佳答案需要您的问题提供的更多详细信息。有多少同时用户？上传量有多大？平均上传速度是多少？下载流量呢？服务器还执行了哪些其他任务？
有几个因素需要考虑。影响网络带宽的 CPU 选择；内存大小影响缓存；存储类型和大小会影响带宽和 IOPS。
在详细说明之前，作为一般规则，一旦您达到n1-standard-1 或更大的实例大小，内存和磁盘大小比 CPU 速度更重要。网络数据传输不是 CPU 周期的高消耗者，直到您持续达到每秒数十或数百兆比特。
CPU 选择
Google Compute Engine 虚拟机实例会根据实例大小限制网络速度。 Google 为每个 CPU 内核提供高达每秒 2 Gbit 的速度。您只能在同一 VPC 的同一专区中的两个实例之间实现此性能水平。 vCPU 内核越多，可能的带宽就越高。小于n1-standard-1 的实例具有共享的 vCPU，并且没有带宽规格。
内存选择
作为一般规则，您拥有的内存越多，性能就越好。但是，这在很大程度上取决于您的软件设计。在写入磁盘之前，您会在内存中缓存上传（通常情况下）吗？如果是这样，那么您将需要足够的内存来处理同时上传的数量乘以平均大小。
存储选择
磁盘 I/O 性能直接取决于磁盘类型和磁盘大小。小磁盘没有高性能。你需要多少性能？这取决于上面提出的问题。
总结
我建议创建一个基准来模拟您需要获得的内容。然后选择实例大小、内存大小、磁盘类型和磁盘大小。然后运行基准测试。监控 CPU 使用率、内存使用率、磁盘容量等。然后调整 VM 实例以微调这些数字。请记住始终在每个类别中保留额外的容量。试图利用 100% 通常意味着遇到性能瓶颈，一切都崩溃了。
【讨论】：