Laravel可以处理高流量的应用程序吗? [英] Can Laravel handle high traffic apps?

查看:93
本文介绍了Laravel可以处理高流量的应用程序吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在研究一个PHP/MySQL社交网络项目,该项目将包含许多模块/部分,包括:

I am working on a PHP/MySQL social network project that will consist of many module/sections including:

  • 用户系统(权限,配置文件,设置等...)
  • stackoverflow样式标记和信誉点系统
  • 墙上/好友信息流
  • 论坛
  • 消息系统
  • 作品集
  • 博客
  • 代码段
  • 书签
  • 和其他几个部分...
  • user system (permissions, profiles, settings, etc...)
  • stackoverflow style badge and reputation point system
  • Wall/stream of friends posts
  • forums
  • message system
  • portfolio
  • blog
  • code snippets
  • bookmarks
  • and several other sections...

最初,我计划使用Laravel框架构建所有内容,因为它非常棒,并且已经完成了很多工作.

Originally I had planned to build everything using Laravel framework since it's simply awesome and also does a lot of the work already.

我现在正在质疑.我尚未开始任何代码,因此这并不是决定的因素.

I am now questioning that though. I have not began any code yet so that is not a factor in the decision.

构建网站/应用程序的任何部分所花费的时间也不会超过性能.

Also my time that it takes to build any part of the site/app does not out-weigh performance.

因此,如果Laravel导致性能较之于从头开始构建时有所降低,但可以节省大量时间.然后,如果它意味着更好的性能和更好的长期性能,我宁愿花大量的时间从头开始构建.

So if Laravel leads to less performance vs building from scratch but saves a ton of time. I would then prefer to spend a ton of extra time building from scratch if it means better performance and better long term.

大约在2006年左右,我建立了MySpace和Facebook的社交网络混合体,并且没有使用任何框架.随着网络规模和流量的增长,我能够真正地调整和优化所有内容,它使我对所有内容的各个方面都拥有100%的控制权,并获得了更高的性能.我认为您在使用大型框架时会失去一些低级的优化功能?

Back around 2006 I built a social network hybrid of MySpace and Facebook and did not use a framework. It gave me 100% control of every aspect of everything and greater performance as I was able to really tweak and optimize everything as my network grew in size and traffic. I think you lose some of that low level optimizing capability when using a big framework?

我的问题很容易被误解为基于观点的问题.但是,从某种程度上来说,如果性能是构建的优先重点,那么从理论上讲是更好的方法应该是合法的.

My question could easily be mistaken as an opinion based question. To some extent it is however the core of it should be legit as far as which in theory would be the better route if performance is the priority over time to build.

我只使用Laravel这样的框架构建了低流量应用程序,所以我没有使用Laravel这样的框架构建高流量应用程序的经验,所以我不知道它们与没有框架相比性能如何.

I have only built low traffic app with a framework like Laravel so I have no experience building a high traffic app with a framework like Laravel so I do not know how well they perform compared to without a framework.

我所有的高流量应用程序都没有框架.

All my high traffic apps have been without a framework.

基于我上面列出的模块/部分的类型. Laravel可以在高流量和大规模级别上处理这类应用吗?

Based on the type of modules/sections I listed above. Can Laravel handle these type of apps on a high traffic and large scale level?

推荐答案

这个问题有点含糊-首先,您对高流量的定义是什么?

This question is a little vague - for a start, what's your definition of high traffic?

在我工作的地方,我们结合了从头开始编写的代码和laravel应用程序所服务的区域的组合(该代码嵌入在主站点中,并且与其余旧应用程序代码一样提供大量流量)

Where I work we run a combination of hand built from the ground up code, and areas that are served by a laravel application (this is embedded in the main site and serves as much traffic as the rest of the old application code).

使用laravel构建的区域丝毫没有减慢速度(使用了相同的数据库源,并且在相同的Web服务器上运行-很有用,以进行基准测试).

There's been no slowdown in the areas built with laravel at all (same database sources are used and it runs on the same web servers - so useful to benchmark on).

注意事项:

原始的手工构建的代码较旧,并且并不总是利用新的PHP方法/设计类型.这意味着它效率不高.这样一来,laravel可能就没有必要做/总是想做的事情.

The original hand built code is older, and doesn't always take advantage of newer PHP methods / design types. This means that it's not as efficient as it could be. Then you have overhead with laravel doing things you might not always need/want to have going on.

总结

其结果是在laravel中模拟您认为将是应用程序中最重的部分的模型,然后再次使用自定义的基础代码.然后对废话进行基准测试.

What it comes down to is to mockup what you think would be the heaviest part of your application within laravel, and then again with custom ground up code. Then benchmark the crap out of it.

您很有可能会发现(好的)手工制作的工作将会更快.值得毫秒吗?那么多数民众赞成在个人选择. Laravel具有处理大量流量的能力,但可以肯定的是,不使用它可能会节省少量时间.

You'll more than likely find that (good) hand built work is going to be quicker. Is it worth those milliseconds? Well thats down to personal choice. Laravel is more than capable of handling large volumes of traffic, but sure, you might shave a small amount of time by not using it.

那对您正在做的事情有多重要?如果有什么使它变慢并导致您在Laravel中出现问题,请进行更改.毕竟它是开源的.

Just how important is that to what you're doing? If something is slowing it down and causing you problems within Laravel - change it. It's open source after all.

供参考(由您自己决定,如果您认为点击量不高-我会这样做)

For reference (up to you if you count this as high traffic or not - I would):

这是英国的SASS,通常为英国的游客提供服务.今晚晚上9点(星期五晚上,这实际上是我们最安静的时间之一),我们目前正在进行大约250,000个活动的PHP会话.

This is a UK based SASS that generally serves UK based visitors. At 9pm tonight (Friday evening - actually one of our quietest times) we currently had around 250,000 active PHP sessions going on.

通过6个Web服务器为该系统提供服务 [用于冗余,流量负载等] (负载均衡)用于PHP应用程序.

The system is served via 6 web servers [for redundancy, traffic loads etc] (load balanced) for the PHP application.

这篇关于Laravel可以处理高流量的应用程序吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆