关于效率的问题 [英] A question about efficiency
问题描述
我正在开发一个非常有活力的网站。大多数显示的
内容将来自数据库（MySql）通过PHP。
某些类型的页面会经常更改（类似于论坛页面
总是添加新内容）而其他人每天只会更改一次（新增一项新闻等等）。
虽然我可以优化我的查询和我的PHP脚本，但是一旦有大量人开始，网站仍有可能会出现拥挤的情况。
b $ b访问它。
问题是如何确保它表现良好？我可能会考虑几个
选项，例如：
- 什么都不做，但依赖于服务器缓存。是PHP / Apache缓存
有什么好处吗？
- 定期发布我的PHP生成的页面为平面HTML页面并提供
而不是PHP。
- 其他东西？
有什么想法吗？
-
Stephen Oakes
Stephen Oakes写道：
我正在开发一个非常动态的网站。大多数显示的内容将来自数据库（MySql）通过PHP。
某些类型的页面会经常更改（类似于论坛页面
，总是有新的添加的内容）和其他人每天只会更改一次（添加新的新闻等）。
虽然我可以优化我的查询和我的PHP脚本，但是一旦有很多人开始访问它，网站仍然有可能变得拥挤。
问题是如何确保它表现良好？我可能会考虑几个选项，例如：
- 什么都不做，但依赖于服务器缓存。 PHP / Apache缓存是否有用？
- 定期发布我的PHP生成的页面是平面HTML页面，而不是PHP提供它们。
- 其他的东西？
任何想法？
- -
Stephen Oakes
嗨Stephen，
我不确定你对第一个解决方案的期望。
Apache / PHP有什么方法可以缓存依赖于
databasecontent的请求，这些请求一直在变化？
我不这么认为，但也许我错了。 （每天都会发生。：P）
你的第二种方法很容易实现，并且易于理解。
之前我做过，它的工作非常简单。
我选择的方法与你描述的方法略有不同，但
类似：
1）我确定了页面中的一堆很少改变但需要很多
的数据库查询。
2）所有这些部分都是包含文件。没有什么花哨的，只是一个简单的
包括。
3）我在相关的''触发器''（不是数据库触发器）上编程了地方
修改includefiles的地方（主要是由管理员更改了数据库中的
）。这些触发器简单地称为例程，即
重建了包含的文件。
这样你就：
- 不需要cronjob或类似的东西那个。
- 所有的包含文件都是最新的。马上。
当然，由您来决定您网站上的哪些部分是合适的
这种方法。
只需2美分。
问候，
Erwin Moller
" Erwin Moller" < SI ******** @ spa.com>写道...- 什么都不做，但依靠服务器缓存。 PHP / Apache缓存有什么好处吗？
- 定期发布我的PHP生成的页面是平面HTML页面，而不是PHP提供它们。
- 其他东西？
我不确定你对第一个解决方案的期望。
我也是，这就是我问的原因。我真的不太了解
服务器/ mysql缓存是如何工作的，知道我是否需要做额外的事情。
你的第二种方法很容易实现，而且很容易理解。
我之前做过，它的工作非常简单。
我选择的方法与你描述的方法略有不同，
但是类似：
...
是的，这是我想到的基本方法，尽管更多的是基于每页
比部分页面。这个想法在某些地方可能会有所帮助。
当然，由您来决定您网站上哪些部分适合这种方法。
您是否注意到速度有任何改善？
-
Stephen Oakes
Stephen Oakes写道：
Erwin Moller < SI ******** @ spa.com>写道...- 什么都不做，但依靠服务器缓存。 PHP / Apache是否有任何好的缓存？ - 定期发布我的PHP生成的页面是平面HTML页面，而不是PHP提供它们。 - 其他什么？我不确定你对第一个解决方案的期望。
我也是，这就是我问的原因。我不太了解服务器/ mysql缓存是如何工作的，知道我是否需要做额外的事情。
所以也许有很好的解决方案在那里工作得很好，我们都不知道
。
:-)
第二种方法很容易实现，很容易理解。
之前我做过，它的工作非常简单。
我选择的方法与你描述的方法略有不同，
但是
类似：
...
是的，这是我想到的基本方法，虽然基于每页更多的基础而不是部分-页。这个想法在某些地方可能有所帮助。
在我的情况下，我有一些列表（top10喜欢的东西）出现在几个
页面上。因此，在我的
情况下，包含HTML中的一小部分HTML是最有意义的。
当然，您的情况可能会有所不同，并且您需要完整的页面：但是
原则是一样的，我希望。
当然，您可以决定您网站上的哪些部分是合适的
这种方法。
你注意到速度的任何改进吗？
是的。
一些查询我需要花费很多时间（因为生成top10列表需要相当复杂的
计算）。
我想补充一下上面的内容解决方案非常容易实现。
而不是将html写入输出，只需将其放入相应的
文件中。
当然用户PHP / WWW-data / nobody /在您存储这些文件的
目录中需要writepermission。这就是为什么我为它制作了一个特殊的
目录，因为我不希望那个用户在我的所有文件上都有写入许可
，所以在安全漏洞的情况下，损坏将是
限制在那些包含文件。
希望这对你有所帮助。
问候，
Erwin Moller
-
Stephen Oakes
I am developing a site which will be very dynamic. Most of the displayed
content will come from a database (MySql) via PHP.
Some types of pages will change frequently (something like a forum page
which is always having new content added to it) and others will only change
once a day (a new news item gets added, etc.).
Although I can optimise my queries and my PHP scripts, there is still the
potential for the site to get congested, once a large number of people start
accessing it.
The question is how do I make sure it performs well? There are several
options I might consider, such as:
- don''t do anything, but rely on server caching. Is PHP / Apache caching
any good?
- Periodically "publish" my PHP-generated pages to flat HTML pages and serve
them up instead of the PHP.
- Other things?
Any thoughts?
--
Stephen Oakes
Stephen Oakes wrote:
I am developing a site which will be very dynamic. Most of the displayed
content will come from a database (MySql) via PHP.
Some types of pages will change frequently (something like a forum page
which is always having new content added to it) and others will only
change once a day (a new news item gets added, etc.).
Although I can optimise my queries and my PHP scripts, there is still the
potential for the site to get congested, once a large number of people
start accessing it.
The question is how do I make sure it performs well? There are several
options I might consider, such as:
- don''t do anything, but rely on server caching. Is PHP / Apache caching
any good?
- Periodically "publish" my PHP-generated pages to flat HTML pages and
serve them up instead of the PHP.
- Other things?
Any thoughts?
--
Stephen Oakes
Hi Stephen,
I am unsure what you expect from the first solution.
Is there any way Apache/PHP can cache requests that depend on
databasecontent that changes all the time?
I don''t think so, but maybe I am wrong. (Happens daily. :P)
You second approach is easy to implement, and easy to understand.
I did it before, and it works realy easy.
The approach I choosed was a little different from the one you describe, but
similar:
1) I identified a bunch of pieces in pages that seldom change but need a lot
of Database-querying.
2) All those pieces were made include-files. Nothing fancy, just a plain
include.
3) I programmed on relevant ''triggers'' (Not database-triggers) on places
where the includefiles were modified (mostly by an admin that changed
something in the database). These triggers simply called a routine that
rebuilded the included files.
In this way you:
- do not need a cronjob or anything like that.
- And all your includefiles are always up to date. Immediately.
Of course, it is up to you to decide which pieces on your site are suitable
for this approach.
Just my 2 cents.
Regards,
Erwin Moller
"Erwin Moller" <si*****************************@spa.com> wrote...- don''t do anything, but rely on server caching. Is PHP / Apache caching
any good? - Periodically "publish" my PHP-generated pages to flat HTML pages and
serve them up instead of the PHP. - Other things?I am unsure what you expect from the first solution.
Me too, that''s why I asked. I don''t really know enough about how
server/mysql caching works to know whether I need do anything extra.
You second approach is easy to implement, and easy to understand.
I did it before, and it works realy easy.
The approach I choosed was a little different from the one you describe,
but
similar:
...
Yes, that''s the basic approach I had in mind, although more on a per-page
basis than part-page. That idea might help in some places.
Of course, it is up to you to decide which pieces on your site are
suitable
for this approach.
Did you notice any improvements in speed?
--
Stephen Oakes
Stephen Oakes wrote:
"Erwin Moller" <si*****************************@spa.com> wrote...- don''t do anything, but rely on server caching. Is PHP / Apache
caching any good? - Periodically "publish" my PHP-generated pages to flat HTML pages and
serve them up instead of the PHP. - Other things?I am unsure what you expect from the first solution.
Me too, that''s why I asked. I don''t really know enough about how
server/mysql caching works to know whether I need do anything extra.
So maybe there are great solutions out there that work great, we both don''t
know about.
:-)
You second approach is easy to implement, and easy to understand.
I did it before, and it works realy easy.
The approach I choosed was a little different from the one you describe,
but
similar:
...
Yes, that''s the basic approach I had in mind, although more on a per-page
basis than part-page. That idea might help in some places.
In my case I had a few lists (top10 like stuff) that appeared on several
pages. So a small piece of HTML in an include made the most sense in my
situation.
Of course your situation might differ, and you need complete pages: but
principle is the same, I expect.
Of course, it is up to you to decide which pieces on your site are
suitable
for this approach.
Did you notice any improvements in speed?
Yes.
Some of the queries I needed took up a lot of time (because of quite complex
calculations needed to produce the top10 lists).
I would like to add that the above solution is really easy to implement.
Instead of writing the html to output, you just put it into the appropriate
file.
Of course the user PHP/WWW-data/nobody/whatever needs writepermission in the
directory where you store these files. That is why I made a special
directory for it, because I didn''t want that that user had writepermission
on all my files, so in case of a securitybreach, the damage would be
limitted to those includefiles.
Hope this helps you a bit.
Regards,
Erwin Moller
--
Stephen Oakes
这篇关于关于效率的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
