| Boss |
|
|---|---|
|
Периодически наблюдаю у себя сильные скачки нагрузки на базу. Вчера даже до 50% дошло. На фоне обычных 2-10% это, конечно, много. В движке, как известно имеется кеш, который впрочем хранит информацию именно в базе. Очевидно, что назначение кэша - это разгрузка процессора. Поэтому все же возвращаюсь к своему предложению... Как насчет того, чтобы хранить подготовленные куски HTML не в базе, а на диске? Теоретически, будет ли от этого заметный эффект?
время % CPU Conn Query upd scan _______________________________________ 23:35:02 7 % 1.18333 min 520 20426 3084 5517 23:20:02 6 % 0.916667 min 480 17987 2842 5102 23:05:01 8 % 1.3 min 602 24316 3561 6596 22:50:02 7 % 1.11667 min 499 19725 2944 5335 22:35:01 8 % 1.33333 min 560 23286 3290 6181 22:20:05 6 % 0.95 min 483 18478 2882 5169 22:05:01 7 % 1.11667 min 569 21566 3353 5987 21:50:02 9 % 1.4 min 608 23926 3604 6504 21:35:01 9 % 1.48333 min 683 27869 4143 7502 21:20:01 7 % 1.11667 min 536 21874 3251 5841 21:05:00 7 % 1.2 min 534 21442 3206 5747 20:50:02 7 % 1.06667 min 493 19427 2904 5259 20:35:03 7 % 1.05 min 476 19942 2832 5204 20:20:01 7 % 1.08333 min 546 21234 3221 5852 20:05:00 7 % 1.13333 min 511 20038 3017 5611 19:50:02 5 % 0.866667 min 455 16475 2721 4842 19:35:01 6 % 1.01667 min 486 17643 2852 5244 19:20:00 5 % 0.833333 min 442 16623 2614 4658 19:05:01 6 % 0.933333 min 416 16649 2461 4387 18:50:03 8 % 1.28333 min 528 21044 3141 5655 18:35:01 8 % 1.26667 min 475 17893 2781 5095 18:20:01 8 % 1.31667 min 570 21175 3325 6013 18:05:00 6 % 0.966667 min 455 17089 2679 4789 17:50:00 7 % 1.05 min 533 19702 3107 5728 17:35:00 7 % 1.11667 min 612 22156 3497 6431 17:20:01 6 % 1.03333 min 540 20805 3241 5848 17:05:01 6 % 0.983333 min 509 19898 3064 5453 16:50:03 9 % 1.48333 min 653 25355 3801 7074 16:35:00 8 % 1.35 min 607 23602 3553 6545 16:20:02 8 % 1.26667 min 546 21388 3276 6072 16:05:01 8 % 1.31667 min 524 20319 3121 5603 15:50:01 6 % 1.01667 min 476 18559 2814 5110 15:35:01 7 % 1.08333 min 507 19728 3027 5484 15:20:01 8 % 1.23333 min 578 22124 3385 6022 15:05:01 8 % 1.33333 min 503 19074 2942 5364 14:50:06 8 % 1.2 min 539 21756 3182 5843 14:35:00 7 % 1.18333 min 562 22289 3448 6022 14:20:01 7 % 1.11667 min 542 21705 3298 5979 14:05:01 5 % 0.816667 min 413 16437 2444 4504 13:50:02 7 % 1.06667 min 577 20602 3332 6185 13:35:00 22 % 3.36667 min 999 51296 5943 11332 13:20:01 23 % 3.56667 min 975 52751 5797 11232 13:05:01 5 % 0.85 min 502 18688 2971 5358 12:50:01 6 % 1 min 492 18477 2922 5241 12:35:00 9 % 1.5 min 642 24673 3723 6912 12:20:01 7 % 1.18333 min 575 22131 3386 6192 12:05:01 8 % 1.28333 min 567 22107 3313 6180 11:50:01 8 % 1.2 min 509 19870 3064 5549 11:35:01 6 % 0.95 min 490 18852 2904 5429 11:20:01 6 % 0.95 min 524 19147 3130 5767 11:05:00 6 % 0.916667 min 441 18052 2643 4868 10:50:01 5 % 0.8 min 391 16077 2375 4350 10:35:01 5 % 0.866667 min 421 16691 2501 4684 10:20:00 19 % 2.9 min 816 44320 4863 9340 10:05:01 50 % 7.63333 min 1753 106896 10460 20465 09:50:01 35 % 5.26667 min 1330 76437 7881 15244 09:35:01 5 % 0.766667 min 380 15023 2259 4040 09:20:01 5 % 0.75 min 357 14604 2137 3828 09:05:00 5 % 0.9 min 465 18693 2810 5040 08:50:00 3 % 0.45 min 334 13575 2026 3554 08:35:01 3 % 0.55 min 310 11916 1826 3313 08:20:00 3 % 0.566667 min 304 11581 1830 3263 08:05:01 5 % 0.883333 min 483 18979 2963 5370 07:50:00 4 % 0.666667 min 420 15134 2520 4658 07:35:01 2 % 0.383333 min 327 11990 2046 3999 07:20:01 2 % 0.316667 min 294 10277 1851 3227 07:05:01 2 % 0.4 min 299 10465 1862 3268 06:50:01 3 % 0.516667 min 385 13268 2373 4093 06:35:00 3 % 0.566667 min 408 14258 2525 4317 06:20:01 2 % 0.433333 min 413 13281 2516 4277 06:05:01 3 % 0.516667 min 392 14444 2363 4128 05:50:01 2 % 0.416667 min 417 14860 2511 4383 05:35:00 2 % 0.366667 min 345 13300 2160 3703 05:20:01 2 % 0.433333 min 454 16296 2805 4853 05:05:00 3 % 0.5 min 476 15431 2914 4883 04:50:01 2 % 0.366667 min 447 14108 2692 4678 04:35:01 2 % 0.416667 min 417 15138 2586 4460 04:20:00 2 % 0.333333 min 275 9328 1611 2911 04:05:00 2 % 0.333333 min 299 10390 1794 3201 03:50:01 4 % 0.633333 min 428 15880 2563 4608 03:35:00 2 % 0.4 min 330 11133 1931 3380 03:20:00 2 % 0.35 min 316 11376 1891 3355 03:05:00 2 % 0.433333 min 391 14743 2336 4167 02:50:01 5 % 0.883333 min 649 23459 3919 7010 02:35:01 5 % 0.833333 min 601 22184 3638 6565 02:20:01 5 % 0.816667 min 630 21577 3717 6543 02:05:01 6 % 0.983333 min 650 23985 3975 6955 01:50:03 5 % 0.8 min 648 23383 3942 6965 01:35:02 7 % 1.08333 min 674 25929 4032 7285 01:20:02 36 % 5.51667 min 1573 85486 9529 18011 01:05:01 6 % 1.05 min 647 24601 3956 7062 00:50:01 6 % 1.01667 min 649 24281 3992 7076 00:35:03 8 % 1.2 min 749 28198 4612 8258 00:20:01 8 % 1.25 min 697 25990 4238 7604 00:05:04 22 % 3.35 min 967 52056 5935 11078 |
| Ratibor |
|
|---|---|
|
Нашел тут скриптик по кэшированию MySQL запросов, кто что скажет ?
Не задавай глупых вопросов, не услышишь вранья.
|
| Boss |
|
|---|---|
|
Время жизни кэша нельзя устанавливать большим. Например - одна минута, много это или мало? Для контонти, пожалуй, много. Ведь в целом сайт на его основе динамический. С другой стороны, даже минуты для того, чтобы почувствовать эффект от кеша - мало. Дело в том, что пиковые нагрузки на базу, - это, я так думаю налеты поисковых роботов. Естественно, что роботы не станут довольствоваться одними и теми же запросами базы.
 Им надо пройтись по многим страницам и веткам форума...Возможно такой бы кеш был бы полезен для каких-то специфичных сайтов, где нагрузка создается именно пользователями, которые тыкаются в одни и те же запросы. Но это точно не мой случай. |
| Ratibor |
|
|---|---|
# Boss : Возможно такой бы кеш был бы полезен для каких-то специфичных сайтов, где нагрузка создается именно пользователями, которые тыкаются в одни и те же запросы.А header и footer - это не одни и теже запросы ? Не задавай глупых вопросов, не услышишь вранья.
|
| Boss |
|
|---|---|
|
Многие тут на форуме кричат про футер и хедер. Но реально, насколько велика доля этих запросов из общей массы? Если посмотреть статистику запросов, то самые тяжелые запросы это другие.
Хотя среди самых тяжелых общие системные запросы, типа: SELECT * FROM sed_bbcode SELECT s.*, n.* FROM sed_forum_sections SELECT online_subloc, COUNT(*) FROM sed_online Может их бы и имело смысл закэшировать. |
| Perceive |
|
|---|---|
# Boss : Как насчет того, чтобы хранить подготовленные куски HTML не в базе, а на диске? Теоретически, будет ли от этого заметный эффект?Стоит рассмотреть следующую концепцию, от которой очень хороший эффект (см. сайт bazarpnz.ru: в коде внизу страницы время генерации. Он не на Cotonti, но пример иллюстративен): Насколько я помню, в одной из версий XTemplate, который шёл в комплекте была предусмотрена функция записи в файл (сейчас о ней ничего не могу сказать). Смысл прост: при первом обращении к странице её полный сгенерированный html пишется в файл. При следующих обращениях движок выполняет всего одну операцию - читает один единственный статичный файл. 0 запросов к БД, 0 процессорных ресурсов. 0,005с на "генерацию". Ждёт только 1 человек, для которого пока отсутствует кэш страницы. Но тут уже, в случае движка с плагинами, по всей видимости, надо вводить функционал event-ов. Если у тебя на главной выводится список комментариев, то при добавлении комментария должен обновляться кэш-файл главной страницы. И т.д., и т.п. Но я думаю, работа того стоит. |
| Sergeich |
|
|---|---|
|
Это навороченный кеш сайта, насколько я помню в будущих версиях котонти запланирована новая система кеширования. А вот и ссылка в трекере: http://trac.cotonti.com/ticket/316
Судя по коментам можно предположить, что у трастмастера уже есть какие-то наброски, возможно он поделится ими с заинтересованными лицами для ускорения процесса |
| Alex300 |
|
|---|---|
|
Относительно многих других CMS, например все той же джумлы, кот гораздо более экономичен в плане нагрузок на сервер и базу. Однако кеш тем не менее необходим. Можно кешировать как страницы, так и результат работа плагинов.
Есть миры, не здесь, там, где небеса горят, и моря засыпают, и реки дремлют; люди сделаны из дыма, а города – из песен. Где-то опасность, где-то несправедливость, даже где-то остыл чай. Идем Эйс, у нас много работы!...
...Sorry for my english... Бесплатные расширения для Cotonti: https://lily-software.com/free-scripts/ |
| Perceive |
|
|---|---|
|
Кеш без сомнения необходим. О нём можно не говорить в случае корпоративных сайтов, но если задумываться о долгоиграющих проектах, то это одно из основных требований.
Sergeich, в случае СMS с многими плагинами и модулями да, возникают сложности. Я смотрел трекер, но не совсем понял, как предполагается осуществление задачи |
| Sergeich |
|
|---|---|
|
Я, признаться, тоже не до конца понял что там предлагается с кешем сделать :). Но мы верим в траста :).
|
| Perceive |
|
|---|---|
|
На бога надейся, а сам не плошай :)))
|
| Trustmaster |
|
|---|---|
|
Я пока притормозил с этим. Очевидные моменты в результате профайлинга перевёл на файловый кеш. Но дальше пошёл эффект обратный. Целиком можно странички замораживать, да, но если контент полностью динамичный, то придётся идти лесом. К примеру, Drupal таким макаром показывает ошеломляющий RPS, но если выходить за рамки статичных узлов, то весь этот страничный кеш никому становится не нужен.
Идея такая: сделать слоёный пирог на подобие того, как кеш работает в ЭВМ. Чем чаще меняются данные, тем более оперативный носитель должен использоваться (xcache, apc, memcached и т.п.), чем объёмнее и статичнее, тем проще их просто поместить на диск. Одновременно работают несколько драйверов кеша, хотя пользователя это особо не должно беспокоить (ну максимум, дать возможность конфигурации остальных моментов). Таймауты - прошлый век. Нужны триггеры обновления кеша, выполняемые по событиям. Это не так уж просто, и это проблема номер раз. Проблема номер два - это декомпозиция самих кешируемых блоков, то есть правильное разделение статического и динамического контента. Можно не заморачиваться, конечно, и кешировать страницы целиком, но опять придёте к статике, хоть и условной. А вот в динамике CMS традиционно плохо оптимизированы, и эту несправедливость хотелось бы исправить. May the Source be with you!
|
