ololsh

Традиционно кеш системы хранился в базе данных. Если бы все так идеально было с базой как нам рассказывают, то незачем было создавать "худший метод" хранения в файловую систему. Обычно делается наоборот - добавляют способы улучшающие существующие методы. Файловая система не так уж плоха как ее пытаются тут выставить. Да, у нее есть свои минусы, но не надо идеализировать mysql и забывать, что и там своих минусов хватает. Mysql это сервер, ему нужно время обработать запрос, требуется время на обмен данных, может быть перегружен, может быть большая очередь. И не надо уповать на тупой примере с подключением 1000 файлов, думаю что в mysql все данные получите одним запросом и он его так быстро обработает что даже моргнуть не успеете. По умолчанию загружаются только предустановленные кеши, для всех остальных происходит отдельные запросы. Если что-то написано криво, то вы вместо 1000 подключений получите в худшем случае несколько сотен запросов. Вот бенчмерки с одного и того же форума. Обычный среднестатистический форум версии 4.4x Количество гостей онлайн - 100 Количество пользователей онлайн - 5 Параметры сервера - неизвестно, Загруженность - "низкая" Файловая система IPS\Data\Store\FileSystem Array ( [settings] => 0.000362 [themes] => 0.000232 [groups] => 0.000225 [storageConfigurations] => 0.000087 [languages] => 0.000082 [javascript_map] => 0.000079 [applications] => 0.000336 [cms_databases] => 0.000168 [cms_fieldids_1] => 0.000077 [cms_fieldids_2] => 0.000067 [cms_fieldids_3] => 0.000069 [cms_fieldids_4] => 0.000069 [cms_fieldids_5] => 0.000068 [cms_fieldids_6] => 0.000077 [moderators] => 0.000075 [furl_configuration] => 0.000297 [modules] => 0.000308 [rssFeeds] => 0.000071 [bannedIpAddresses] => 0.000067 [profileSteps] => 0.000089 [profileFields] => 0.000144 [administrators] => 0.000070 [template_2_58e6e78f757be24525684f41df8d1698_tables] => 0.000655 [template_2_ad9ae6e9ced8695954ac11f917afdfac_global] => 0.000278 [template_2_1bb0e8f6d56f81d6c7163246c7be5ae2_forums] => 0.001061 [forumsSavedActions] => 0.000074 [template_2_c8c276c9a99811c050a8036df5d2db06_forms] => 0.001834 [template_2_46b82e53682bf97617c36aa125473bea_global] => 0.000992 [template_2_94a9d7649fb9cdbfc784d3516e61a717_global] => 0.003183 [widgets] => 0.000148 [metaTags] => 0.000107 [announcements] => 0.000172 [acpNotificationIds] => 0.000073 [acpNotifications] => 0.000071 [template_2_05babf262d9c3036d4373dfb8d233fa3_store] => 0.001114 [promoters] => 0.000079 [frontNavigation] => 0.000081 [defaultStreamData] => 0.000077 [license_data] => 0.000092 ) TOTAL: 0,01321 База данных (Mysql). Отдельный массив это отдельный запрос. IPS\Data\Store\Database Array ( [0] => Array ( [keys] => Array ( [0] => cacheKeys [1] => settings [2] => storageConfigurations [3] => themes [4] => languages [5] => groups [6] => applications [7] => modules [8] => widgets [9] => furl [10] => javascript_map [11] => metaTags [12] => bannedIpAddresses [13] => license_data [14] => furl_configuration [15] => rssFeeds [16] => frontNavigation [17] => globalStreamIds [18] => profileSteps [19] => nexusPackagesWithReviews [20] => cms_menu [21] => cms_databases [22] => pages_page_urls [23] => announcements [24] => loginMethods [25] => widgets [26] => defaultStreamData [27] => acpNotifications [28] => emoticons [29] => administrators [30] => moderators [31] => group_promotions [32] => promoters ) [TOTAL] => 0.01130486 ) [1] => Array ( [keys] => Array ( [0] => template_1_05babf262d9c3036d4373dfb8d233fa3_store [1] => template_1_f5e47eab634595f1012d63f22062082b_global [2] => template_1_46b82e53682bf97617c36aa125473bea_global [3] => template_1_c8c276c9a99811c050a8036df5d2db06_forms [4] => template_1_6b57f516a06e7a9b9d17e2f40f0ce290_forms ) [TOTAL] => 0.00442791 ) ) TOTAL: 0,01573277 Корреляции могут быть как в большее так и меньшее значение для обоих методов. Особого прироста или ухудшение производительности я не наблюдаю по ним. Из всего вышесказанное можно сделать заключение, что у каждого способа есть свои плюсы и минусы. В определенных обстоятельствах может выигрывать mysql, например если у вас много кешей и загружаются они все одним - двум запросами и mysql сервер не нагружен. В других производительнее может оказаться ФС, если форум стандартный или нужно снизить нагрузку на mysql сервер. ПС Я не агитирую за тот или иной метод, эти способы плюс минус одинаковы в стандартных условиях, особой разницы в производительности между ними нету. Просто утверждение что ФС самый худший вариант без разбора не считаю корректным в этом случае.

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

Ну конечно, без быдловатых ответов в духе "даже не хочу спорить, если не очевидно" ну никак не обойтись тут. Тоже, сравнили хранилище типа ключ-значение в оперативной памятью с диском. Сессии как раз и хранятся в базе данных если не настроен метод кеширования редис. Речь о том, чем же файловая система для хранения datastore хуже чем mysql хранилище? Mysql база разве не на диске находится и оттуда данные не нужно получать? А как же накладные расходы на подключение и передачи данных? На диске хранится датасторе, это системные настройки и кеши приложений. Я бы не сказал что файловая система в данном случае самый худший вариант из всех. Понятно, что если есть пару лишних сотен мегабайт оперативной памяти быстрее их всех типов будет Redis как хранилище key-value, но по отношению к mysql не все так однозначно хуже.

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

Чем же? Он вроде по умолчанию используется.

В шаблоне {{$xml = new SimpleXMLElement('https://rating.kinopoisk.ru/958442.xml', null, true);}} {{if $xml}} Kinopoisk rating: {$xml->kp_rating} {{endif}} В сообщение наверное придется по другому, через плагин или через ббкод, вариантов тут множество на любой выбор. Только надо помнить что серверная реализация создаст запрос для каждого пользователя к этому файлу при каждом запросе странице. Тут придется любо кешировать на время результат, либо вывести на фронтэнде запрос к xml.

Был не прав, как не парадоксально но ид пользователя действительно типа int (видимо все же работает ORM). Значит точное сравнение должно работать и в доках написано правильно. Можно css и в шаблоне, можно указать стиль непосредственно элементу... Если css будет кешироваться, то использование такой конструкции бессмысленно, ибо файл закешируется от текущего пользователя и все условия будут применены для остальных пользователей. Хотя возможно php исполняется в нем при каждой загрузке страницы, не знаю, но на мой взгляд это не оптимально. По моему хороший вариант это который предложил @вантед или задать стиль непосредственно элементу style="{{if member.member_group_id == 7}}font-color: black;{{else}}font-color: white;{{endif}}"

Ничего странно, все данные из бд возвращаются в виде string-а, а в коде сравнивается типа integer и конечно они не будут равны. Какой-то новомодный стиль в php пихать направо и налево сравнение по типу. Как я устал от этого уже, приходится спорить часами - если значение не может быть иметь разные типы данных которые приводятся к другому формату при сравнения тогда не имеет смысла использовать сравнение по типу. 2ТС @WaNtedвам подсказал правильный вариант. Файла CSS кешируются на диске, использовать там php переменные не имеет смысла.