PHP + Memcache

[Sergey2020]

Работаю над одним проектом. И хочу учесть уже на этапе его создания возможность большой нагрузки. Каждая страница проекта создается из кучи разных блочков-шаблонов. И решил посмотреть что будет работать быстрее.
Написал один скрипт, который просто выводит 5 блоков-шаблонов посредством include
второй скрипт посредством implode загружает каждый блок-шаблон из файла в переменную.
третий загружает также как во втором случае в переменную. Но также загружает в memcache. И при последующих обращениях проверяет наличие в memcache и если там есть - выводит из memcache.

Замеры делал на обыкновенном домашнем компьютере с денвером.
Получилось, что страница в первом варианте создавалась за 0.0006-0.0008 сек. и грузила процессор до 18%
Во втором варианте - строго около 0.0006сек. т.е. быстрее, чем первый вариант. с той же загрузкой процессора.
Но третий вариант меня очень удивил: процессор грузился до 42% даже тогда, когда переменная бралась из кэша. страница генерировалась гораздо дольше, чем первые два варианта. не быстрее 0.001 сек. иногда и за 0.5сек.

Так вот теперь суть вопроса: Почему так получается? Я много читал про memcache. Но примитивное тестирование показывает обратное. Может быть на серверах это всё иначе будет работать? Я рассчитывал, что третий вариант окажется самым быстрым и будет минимум грузить сервер... А оказалось, что быстрее прочесть из файла, чем в кэше копаться. Дайте, пожалуйста, совет...

 

[c0dex]

Sergey2020
пиши пока без "высокой нагрузки", иначе никогда ее не будет у тебя.

 

[Sergey2020]

почему?
просто есть некоторые элементарные приемы, которые кругом обсуждаются и не сложны в реализации. почему бы их сразу не реализовать. Согласен, что практическое решение проблемы - более результативное, чем попытка учесть решение проблемы, которая ещё не наступила и не факт что наступит...

"никогда её не будет" - это абстрактная примета?... или реальное основанный на каких-то земных вещах вывод?

 

[c0dex]

прими как должное, пиши без твоих синтетических замеров, если ты пришел сюда за советом - ты его получил. Преждевременная оптимизация - корень всех зол, про это тебе скажет тут кто угодно, а не только я.

В твоем случае, у тебя тратится время на соединение с демоном memcached, который параллельно веб-серверу висит в памяти, будь то сокет-соединение или на порт. Отсюда у тебя и лаг появился.

Потому в кеш надо выносить данные, на получение которых тратится значительное время, как правило это запросы к mysql, парсинг каких-то данных, ну или те данные, которые "горячие" и просто часто используются. Не надо делать статическое кеширование на мемкеше. С этим прекрасно справляется APC/eaccelerator/xcache

 

[AmdY]

посмотри картинку, по оси x у тебя количество просомотров, по y - нагрузка. синяя полоска - это нагрузка без кеширования, она примерно одинакова и в конце концов убивает сервер. зелёная - это с кешем, сразу у тебя есть оверхед за счёт генерации кеша и обращений за ним к СЕРВЕРУ мемкэша, который вовсе может быть на отдельной машине. на затем кэш позволяет получать логарифмическую зависимость от просмотров, т.к. у мемкэша скорость не сильно изменяется под нагрузкой.

p.s. не воспринимай графики как чистую монету, они идеализированы, в реальной жизни всё сложнее и нужно мониторить и профайлить, но следует помнить, что поведение при параллельных запросах будет сильно отличаться от картины на девелоперской машине.

 

[Sergey2020]

Спасибо большое за ответы.
Почитав ответ c0dex я было сначала подумал, что может быть в этом месте memcache будет действительно излишним.
Но прочитав ответ AmdY снова об этом задумался.

Ведь можно написать примитивный сайт, а потом его каждый день оптимизировать, а можно сразу учесть часто встречающиеся моменты и их оптимизировать уже на начальном этапе.

 

[Sergey2020]

прими как должное, пиши без твоих синтетических замеров, если ты пришел сюда за советом - ты его получил. Преждевременная оптимизация - корень всех зол, про это тебе скажет тут кто угодно, а не только я.

В твоем случае, у тебя тратится время на соединение с демоном memcached, который параллельно веб-серверу висит в памяти, будь то сокет-соединение или на порт. Отсюда у тебя и лаг появился.

Потому в кеш надо выносить данные, на получение которых тратится значительное время, как правило это запросы к mysql, парсинг каких-то данных, ну или те данные, которые "горячие" и просто часто используются. Не надо делать статическое кеширование на мемкеше. С этим прекрасно справляется APC/eaccelerator/xcache

соединение с демоном memcached происходит единожды при параллельных сессиях (если обращаются сразу, например 100 пользователей)? или для каждого параллельного запроса - отдельная нагрузка?
т.е. при одновременных запросах скорость на один запрос будет меняться в сторону уменьшения?

Нельзя назвать мой вариант статическим кешированием. Каждый блок, после того как берется из memcache изменяется. В шаблоне есть переменные, которые нужно заменить на значение переменной.

Вы пишете, что в кеш нужно выносить данные, которые часто используются. Так ведь это как раз тот вариант. блоки шаблона используются очень часто!

Я очень уважаю Ваше мнение, и оно очень важно для меня. Я не спорю, я просто хочу разобраться. спасибо.

 

[Sergey2020]

посмотри картинку, по оси x у тебя количество просомотров, по y - нагрузка. синяя полоска - это нагрузка без кеширования, она примерно одинакова и в конце концов убивает сервер. зелёная - это с кешем, сразу у тебя есть оверхед за счёт генерации кеша и обращений за ним к СЕРВЕРУ мемкэша, который вовсе может быть на отдельной машине. на затем кэш позволяет получать логарифмическую зависимость от просмотров, т.к. у мемкэша скорость не сильно изменяется под нагрузкой.

p.s. не воспринимай графики как чистую монету, они идеализированы, в реальной жизни всё сложнее и нужно мониторить и профайлить, но следует помнить, что поведение при параллельных запросах будет сильно отличаться от картины на девелоперской машине.

я написал скрипт, в котором при первом обращении происходит чтение из файла, запись в мемкеш и вывод на экран. А при последующих - чтение из мемкеша и вывод на экран. Я думал, что первое обращение будет долгим из-за записи в мемкеш. Но все последующие выполнения тоже долгие. Это наверное из-за того, что чтение из мемкеш тоже требует много времени?
Так как лучше делать, если я всё же рассчитываю в будущем получить высокую нагрузку? Могу ли я хоть частично это учесть на этапе начальной разработки? или же лучше пока не делать? А если пока не делать, то из каких расчетов? Вдруг чтение с диска окажется быстрее, чем чтение с ОЗУ? сомневаюсь...

 

[fixxxer]

С такой кашей в голове забудь про нагрузки, и изучи как работают современные многозадачные ОС.

 

[Sergey2020]

С такой кашей в голове забудь про нагрузки, и изучи как работают современные многозадачные ОС.

Я обязательно изучу... но забывать про нагрузки не собираюсь... не вижу проблемы в том, чтобы изучить неизученное... понять непонятое...

А пишу здесь как раз-таки, чтобы побыстрее разобраться со своей "кашей"... и прошу помощи... мне не нужны конкретные решения.. мне нужно понять, в каком направлении правильно двигаться... где я что не так понимаю... и нужны ответы, на некоторые для Вас уже "примитивные вопросы".... над которыми, возможно, через недельку и я смеяться буду... когда разберусь...

 

[fixxxer]

Разбираться надо не на форумах, а иными двумя способами.

1. Читать маны и руководства.
2. Ставить эксперименты и измерять.

И да, если у тебя венда, выкинь сразу.

 

[Sergey2020]

Разбираться надо не на форумах, а иными двумя способами.

1. Читать маны и руководства.
2. Ставить эксперименты и измерять.

И да, если у тебя венда, выкинь сразу.

Я очень много читаю... я всё это делаю... поверь...
но от этого каша сразу не исчезнет.... иногда нужно получить ответ на пару простых вопросов, чтобы понять каких знаний не хватает... и пополнить... для этого я и на форуме...

"венда" - ты имел ввиду "винда"?

 

[fixxxer]

А вообще для начала разберись, что происходит в деталях, когда

1) ты читаешь файл с файловой системы
2) ты читаешь данные из мемкеша

На уровне представлений "с диска и из памяти" ничего не получится

 

[Sergey2020]

Всё оказалось очень просто... Логика и интуиция меня не подводила... Просто я не правильно подошел к тестированию.

Мораль какую я учел: Не нужно никого слушать, если тебя остерегают от использования современных технологий...
Будет проект в Hiload или нет зависит совсем от других вещей. И высказывание "пиши пока без "высокой нагрузки", иначе никогда ее не будет у тебя" - не верно...
Зачем строить спортивный автомобиль по чертежам трактора, а потом его постоянно переделывать????? чтобы он наконец-таки стал спортивным! Ерунда это...

А вот что конкретно было не так.... я тестировал облегченные шаблоны без наполнения данными... и конечно же кэширование блоков шаблона через memcache тянуло скорость вниз...
И конечно же так делать не нужно....
На деле сайт будет работать по другому. Будут доставаться различные данные из memcache. И соответственно, memcache и так будет запущен... И в этом случае мне уже ничего не стоит из мемкеш выдернуть дополнительно и блоки шаблонов.
Результат: страница с динамическими данными (из memcache), берущая блоки шаблонов тоже из memcache работает в 2 раза быстрее, чем такая же страница, но берущая блоки шаблонов из файла!!!

 

[Sergey2020]

В любом случае, конечно, всем спасибо... и извините, если что не так сказал... обидел кого...
Я ошибся в подходе к тестированию - поэтому и возник этот вопрос....
Наверное, действительно в моей голове каша...

 

[Adelf]

Sergey2020
пример как раз для тебя: Lamborghini когда была тракторной компанией. И такой вот успех.
А некоторые.. сразу пытались строить спортивные машины. И их ждал провал.

Сразу строят спортивные машины(сайты под хайлоад) уже сформировавшиеся команды, которые на 90% уверены, что нагрузки будут, причем сразу(различные проекты яндекса и т.д.).
Большинство других пришло к хайлоаду постепенно. В первую очередь они развивали функционал.. а на "хайлоад" тратили время только когда текущий вариант не справлялся с нагрузками.
У тебя же.. без опыта особого выбор вообще простейший - пиши пока функционал. Забей на нагрузки. Я понимаю.. игрушка(хайлоад) конечно интересная, но тут уж сам выбирай - играть или работать.

 

[MiksIr]

Зачем строить спортивный автомобиль по чертежам трактора

Почти в корень. Вот вы и пытаетесь, взяв чертежи и опыт построения тракторов, сразу туда напихать элементы спортивной машины. А если инженер по проектированию тракторов придет с заявлением, что он, мол, собирается как раз спортивный автомобиль и построить, по-этому ему трактор минимум с двумя турбинами... ему вежливо (или не очень) посоветуют для начала хотя-бы ладу калину спроектировать.

Когда пишется проект, который потенциально может стать хайлодом - это не значит, что туда пихают все кеширования, обвешивают noSQL и так далее. Это значит, что руководствуясь опытом проектируется такая структура, в которую все это можно будет потом быстро и эффективно засунуть. Когда понадобится.