В общем у меня используется свой движек БД на базе описания структур в виде массива, который автоматически создает для каждой таблицы БД кэш ячейку и пишут туда MD5 данных сразу скидывая статическую копию таблицы в файл. При любом изменении БД автомтически создается обновленная версия кэш файла статики и конечно же обновляется кэш MD5. Таким образом мне требуется только один запрос к базе данных чтобы отобразить главную страницу, которая обычно тянет 5-7 запросов SELECT. Вопрос: мне даст что-то memcache или игра не стоит свеч? Система обычно потребляет меньше одного мегабайта памяти и выполняется код за 0,05 секунды. Мне кажется, что memcache мне не даст ничего - или я ошибаюсь? вот сорцы движка БД: https://github.com/xShiftx/Revolver_DBX
обвертка дерьмо, для понимающих взглянуть на 399 строку DBX.php логично while использовать, да ? прикольная переменная $hash ? 628 строка на ровном месте обделаться. от перемен мест слагаемых.... Оптимизацию запросов в один совершенный нужно делать
Мышь, во первых Вы дичЪ, во вторых у вас докопы до одной строчки. Возможно это foreach головного мозга? Там везде одна инструкция - один запрос. Остальное косается обработки кэша, который ваш пискуновский моцк гн осилил. Про мем кэш ответ будет, или будете просто говном из-за угла по партизански кидаться?
@xShiftx, 5-7 запросов или 1 чаще всего погоды вообще не делает. Делает разница раз в 100, к примеру. Т.е. было 100 запросов, оптимизировал - стал один, разница есть. А так, один фиг, накладные расходы на чтение файлов кеша примерно такие же, как на обращение к базе (которую неглупые люди писали, она кешит всё, что надо и сама) Обращение к Memcached и аналогам - тоже не бесплатная операция, так что в данном случае выигрыша не будет --- Добавлено --- P.S. написал "чаще всего", потому что если какой-то из 5-7 запросов выполняется, к примеру, 500 мс, а результат считывается из файла/мемкеша за 5 мс, то в кешировании смысл есть.
Ну оно больше как защита от перегруза ресурсов недорогого хостинга задумано. И оправдывает себя в этом плане. Спасибо. --- Добавлено --- p.s.: комит то слабо сделать?
У тебя уже кэшируется таблица, если я правильно понял. В memcache, на мой взгляд, вообще не стоит хранить ничего большего чем данные, которые потребляют большое количество ресурсов при запросе. Я раз в 5 минут считываю количество тем, постов на форуме, сохраняю все это в память и вывожу, а когда нужно - обновляю. (но не чаще, чем раз в пять минут например).
Все, тебе стрела, завтра после уроков за школой, зашкваренный. Во вторых кАсается, тебе даже редактор подсвечивал. Вот такой у тебя и код made in china. Даже и не начинал, ты лишь сам себя закопал дерьмом, оскорбившись критикой. В школе еще не проходили "От перемен мест слагаемых, сумма не меняется" ? У тебя там дыра уязвимости с 628 строки, любой суй не хочу.
поверь ... PHP: public static function escape( $string ) { - совсем не делает то что задумано хотя бы mysqli_real_escape используй а еще не очень понятно - поддержка только простейших запросов? А как же все многообразие SQL? JOIN,UNION, вложенные запросы и прочие прелести? можно использовать?
Она вроде достаточно очищает. real escape у меня на Mac OS почему-то не заработал. Остальные виды запросов в плане есть, но пока до них руки не доходят. > У тебя там дыра уязвимости с 628 строки, любой суй не хочу. А ну ка давай, Вася узкопленочный
ключевое слово - вроде... надо было просто разобраться почему у тебя на Маке чето не работает... а вообще - какие-то тесты делал? ну на производительность ... типа быстрее ли стало итд?
Ему пишут что там говнокод, а школьник язвит, цирк... --- Добавлено --- Есть акуительные инструменты prepare запросов.
Быстрее точно, человек знающий пишет, что она лучше. --- Добавлено --- Но конкретно вы даже не попытались.
PHP: public static function escape( $string ) { return htmlspecialchars(addslashes(preg_replace('/[\x{10000}-\x{10FFFF}]/u', "\xEF\xBF\xBD", $string))); } ага... поэтому: Попов учит как правильно говнокодить... вы не можете воспринять критику и осознать того, что вы создали дерьмовый софт со знающим пришельцем криворуким, ставит конкретный итог, что нет смысла дальше тратить время.
Успокойтесь горячие парни. @xShiftx в твой предыдущий заход на форум ты тоже как-то быстро перешёл на крик. Проанализируй это. Может быть ты не всегда прав, а? По теме: я считаю тебе не стоит переносить файловый кеш на мемкешед. Принципиально это ничего не изменит. Возможно ты выиграешь несколько миллисекунд, возможно нет. Главный вопрос: зачем. Кеш должен быть оправдан. Когда тупо кешировано просто ВСЁ, это выглядит как маскировка проблем, костыль. Когда-то давно ты обнаружил провал в быстродействии и вместо локализации проблемы, потратил N человекодней на тотальное кеширование. Теперь это работает как @ для игнорирования ошибок. Типа, не вижу значит ничего не было! Удачи тебе в твоём безнадежном деле.
Не поверишь, но сам MySQL работает примерно так. Только умнее. Если ты два раза подряд выполнишь один и тот же SELECT, то творой раз он выполнится быстрее, потому что данные закешировались. Но если хотябы одна из участвующих в нём таблиц изменилась, то кеш для этого SELECT сбрасывается. Ну и, конечно, доступный объем ОЗУ и временной области на диске влияют на результативность кеша. Дай больше памяти серверу, он будет работать быстрее — в среднем запрос будет с большей вероятностью выполнен с помощью кеша. Если ты используешь один сервер на PHP, БД и memcached/redis, они будут красть память друг у друга Если есть отдельный сервак под кеш и несколько веб-серверов с балансировщиком нагрузки, тогда общий memcache(d) будет эффективен. Эффективнее чем локальный файловый кеш. Но, мне кажется, это не твой уровень задач.