Ну не веришь - посмотри)

Но если рассмотреть стандартные условия - mysql и memcache - то конечно же мемкэш сделает mysql

Даже более того, memcache сделает cache mysql

ну мы не рассматриваем handler socket и xprotocol

ун вот memcache может только handler socket проиграть...

ну и xprotocol...

Я даже больше скажу. Если организовать кеш в redis даже, это будет быстрее, чем mysql)

При том опять таки существенно

При прочих равных условиях(предположим, что мы разместим mysql и redis на одном сервере)

ну... тут я думаю что любое key-value хранилище mysql при прочих равных сделает...

вопрос в персистентности :)

Ну мы же кеш не для persistance юзаем)

хитрый повар.jpg!

вы как то много факторов откинули. какое кол-во запросов на 1 конкретный ресурс прилетает (кол-во данных в кэше, не будет ли он свопить или вытеснять). Сбросы кэша при изменении (нагрузка на кэш) и т.п. всё это легко сделает наш кэш бессполезным

Мы как экономисты исходим из рациональсти обсуждающих

своп кэша?

Базу тоже в таком случае можно сделать плохой и отдавать один запрос по id > 30 секунд)

Сейчас опять начнут урановые ломы во ртути топить...

ну miss еще я понимаю, но своп???

Сейчас опять начнут урановые ломы во ртути топить...

?

кароч - сходить напрямую в память - что как бы является кэшем - это быстрее чем сходить в БД

как бы вот про это

своп кэша?

редис свопит если ты не в курсе

редис свопит если ты не в курсе

Я конечно могу предствить того дебила, кто поставить редис с сохранением на диск в качестве кэша

редис свопит если ты не в курсе

А может и не свопить, если ты не в курсе, но речь шла не об этом и не о редисе

но мы же не ебанутых админов обсуждаем...

но мы же не ебанутых админов обсуждаем...

вы абсолютно все запросы кэшите?

мы где?

ну кешируй все, кто мешает? ttl и горячесть запросов сама все разрулит

для веба стараемся все, исключения составляют оооочень малая часть запросов...

от момента что "надо бы начать кешировать все" до "надо бы понять как кеш грамотно греть" обычно пропасть ресурсов находится которых хватает для большинства

Быстрее конечно

если все в кеше быстре почему изначально все в кеше не держать?

если все в кеше быстре почему изначально все в кеше не держать?

персистентности нет потому что, очевидно же

персистентности нет потому что, очевидно же

сомнительно что выборка по id из базы, будет как то существенно медленнее чем чтение из файла. Возможно даже медленнее

сомнительно что выборка по id из базы, будет как то существенно медленнее чем чтение из файла. Возможно даже медленнее

Из какого файла? Ты о чем вообще?)

Из какого файла? Ты о чем вообще?)

о кеше

Кеш не в файле, лол, он у тебя в ram крутится

Если мы про memcache

Кеш не в файле, лол, он у тебя в ram крутится

это ты с чего вззял? как он у меня там оседает? :)

Если мы про memcache

ааа

наверное я про это пропустил

Если мы про memcache

но тут тоже сомнительно, ram то не бесконечный

Умываю руки. Кеш фигня, не используйте его.

Кеш это бабки , хорошо иметь много кеша

Умываю руки. Кеш фигня, не используйте его.

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

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

Не только там. Почитай выше, уже всё обсудили

от момента что "надо бы начать кешировать все" до "надо бы понять как кеш грамотно греть" обычно пропасть ресурсов находится которых хватает для большинства

Икзактли!

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

Чаще всего сложные выборки нет смысла кэшировать - их запрос разовый...

Как раз кэшируются простые выборки - которые чаще всего делаются...

Не только там. Почитай выше, уже всё обсудили

ну чет как то все абстракно, про сферического коня в вакууме.

Чаще всего сложные выборки нет смысла кэшировать - их запрос разовый...

не обязательно, бываю сложные выборки которы приходится делать на каждый запрос

Ничего абстрактного небыло как раз вроде. Мое утверждение - кеширование простого запроса по id имеет смысл

ниже дискуссия почему

Несколько аргументов за, ни одного весомого аргумента против. Где тут абстрактные кони?

Да даже запрос по ид кэшироваться может.

Ничего абстрактного небыло как раз вроде. Мое утверждение - кеширование простого запроса по id имеет смысл

я с Максом согласен тут, слишком много всего откинуто. Даже нагрузка не указана. При паре 10к запросов в день, нет вообще смысла это кешировать

я с Максом согласен тут, слишком много всего откинуто. Даже нагрузка не указана. При паре 10к запросов в день, нет вообще смысла это кешировать

есть. скорость выполнения запроса

ждать 5мс и 250мс - очень существенная разница

есть. скорость выполнения запроса

0.0001 или 0.00005 ?

ждать 5мс и 250мс - очень существенная разница

?

по id такая разница?

тогда у меня для тебя плохие новости

тогда у меня для тебя плохие новости

себе их оставь. В нормальном проекте, где у тебя БД и приложения на разных серваках разница еще больше может быть

ERROR: S client not available

А если они в разных ДЦ еще, уууу

А если они в разных ДЦ еще, уууу

вот я и говорю что разговор про сферического коня в вакууме. Нет вообще никаких данных, что бы понять целесообразность данного вида кеширования. А на требованиях так сказать "по умолчанию" такое кеширование нафиг не надо

Честно, доказывать людям, которые не понимают, что из RAM взять ВСЕГДА быстрее, чем взять с диска, да еще и по TCP подключению нет никакого желания. Ладно бы какой-то предметный спор был. Про целесообразность ты только что заговорил. Вот прям 1 сообщением выше от моего всего. До это речь была о скорости

И опять таки, это целесообразно, если для тебя важна скорость. Более того, если у тебя приложение настолько маленькое, то ты просто можешь закешировать ВСЕ запросы\ответы и не трахать мозги о целесообразности

Предвосхищая вопросы про небесконечность RAM - давай поговорим об этом после того, как ты прочитаешь о том что такое data eviction policy, какие ее виды бывают и с чем это едят

Little tip: LRU, LFU, LIFO, FIFO, TLRU, MRU и так далее

Не дружу с front. Что нужно сделать, что бы vue компилил сопмоненты? Как настроить?

Не дружу с front. Что нужно сделать, что бы vue компилил сопмоненты? Как настроить?

Раздел mix доки прочти. В нем все описано.

Раздел mix доки прочти. В нем все описано.

Читал

не обязательно, бываю сложные выборки которы приходится делать на каждый запрос

Если у тебя есть сложные выборки на каждый запрос - то что-то не то с БД - сделай денормализацию или что еще... Кароче не должно быть сложных запросов на каждый запрос

Если у тебя есть сложные выборки на каждый запрос - то что-то не то с БД - сделай денормализацию или что еще... Кароче не должно быть сложных запросов на каждый запрос

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

я бы сделал отдельную таблицу и туда бы эти значения складывал

и тут ты кэшируешь для 1 человека!!!

кэш для 1 человека это как бы ну на мой взгляд - не очень...

и тут ты кэшируешь для 1 человека!!!

Ага, для сессии

чуваки, а как композером поставить 5.4 лару?

https://laravel.com/docs/5.4/installation

composer create-project —prefer-dist laravel/laravel blog "5.4.*"

спасибо

чёт тупанул под вечер уже посмотреть доку :)

Приффке, есть ли здесь те, кто ZCE сдал?

Приффке, есть ли здесь те, кто ZCE сдал?

Я не сдавал, но я знаю человека который сдавал )

А почему не сдавал, мне кажется с твоим левелом вообще на изи.

А почему не сдавал, мне кажется с твоим левелом вообще на изи.

Откладываю )

Прокрастинация мать ее )

ZCE стоит того?

(Ссыкую провалиться и побегу плакати просто)

ZCE стоит того?

Если оплачивает компания, то почему нет , а за свои деньги хз

Готовился, но не сдавал, какой в этом смысл непонятно. Как сертификат какого-нибудь oracle. Походит на линейку для письки

Готовился, но не сдавал, какой в этом смысл непонятно. Как сертификат какого-нибудь oracle. Походит на линейку для письки

Не сдал проста?)

Ну в СНГ эти линейки могут помочь думаю, типа иди на хрен, я ИНЖЫНЕР!