Вопросы Теги

Преимущества кэша по сравнению с сессией

Внимание: примерный код этого ответа (например, примерный код вопроса) использует расширение PHP mysql, которое устарело в PHP 5.5.0 и полностью удалено в PHP 7.0.0.

Если вы используете последнюю версию PHP, опция mysql_real_escape_string, описанная ниже, больше не будет доступна (хотя mysqli::escape_string является современным эквивалентом). В настоящее время опция mysql_real_escape_string имеет смысл только для устаревшего кода на старой версии PHP.

У вас есть два варианта - экранирование специальных символов в вашем unsafe_variable или использование параметризованный запрос. Оба будут защищать вас от SQL-инъекций. Параметрированный запрос считается лучшей практикой, но для его использования потребуется переходить на более новое расширение mysql в PHP.

Мы рассмотрим нижнюю строку удара, которая будет первой. 

//Connect

$unsafe_variable = $_POST["user-input"];
$safe_variable = mysql_real_escape_string($unsafe_variable);

mysql_query("INSERT INTO table (column) VALUES ('" . $safe_variable . "')");

//Disconnect

См. также информацию о функции mysql_real_escape_string .

Чтобы использовать параметризованный запрос, вам нужно использовать MySQLi , а не функции MySQL . Чтобы переписать ваш пример, нам понадобится что-то вроде следующего. 

prepare("INSERT INTO table (column) VALUES (?)");

    // TODO check that $stmt creation succeeded

    // "s" means the database expects a string
    $stmt->bind_param("s", $unsafe_variable);

    $stmt->execute();

    $stmt->close();

    $mysqli->close();
?>

Ключевая функция, которую вы хотите прочитать, будет mysqli::prepare .

Также, как предложили другие, вы можете сочтет полезным / легче повысить уровень абстракции с помощью чего-то вроде PDO .

Обратите внимание, что случай вы спросили об этом довольно просто, и что более сложные случаи могут потребовать более сложных подходов. В частности:

  • Если вы хотите изменить структуру SQL на основе пользовательского ввода, параметризованные запросы не помогут, и требуемое экранирование не распространяется на mysql_real_escape_string. В этом случае вам лучше было бы пропускать вход пользователя через белый список, чтобы обеспечить доступ только «безопасных» значений.
  • Если вы используете целые числа от пользовательского ввода в состоянии и берете mysql_real_escape_string, вы столкнетесь с проблемой, описанной в Polynomial в комментариях ниже. Этот случай более сложный, поскольку целые числа не будут окружены кавычками, поэтому вы можете справиться, подтвердив, что пользовательский ввод содержит только цифры.
  • Есть, вероятно, другие случаи, о которых я не знаю. Вы можете найти , этот является полезным ресурсом для некоторых более тонких проблем, с которыми вы можете столкнуться.
67
задан Omer K 30 August 2015 в 17:57
поделиться

7 ответов

Одно важное различие, что объекты в кэше могут истечь (будет удален из кэша) после указанного количества времени. Объекты, помещенные в сессию, останутся там, пока сессия не заканчивается.

ASP.NET может также удалить объекты из кэша, когда сумма доступной памяти становится небольшой.

Другое различие: состояние сеанса может быть сохранено внешним (сервер состояния, SQL-сервер) и совместно использовано несколькими экземплярами Вашего веб-приложения (для выравнивания нагрузки). Дело обстоит не так с кэшем.

, Кроме того, этих различий (поскольку другие отметили): сессия на пользователя/сессию, в то время как кэш на приложение.

82
ответ дан M4N 24 November 2019 в 14:35
поделиться

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

, Как отмечено в других ответах можно сохранить на информацию о пользователе в кэше, если Вы обеспечиваете ключ (или сессией или cookie). Тогда Вы имели бы больше контроля, чтобы истечь объекты в кэше и также установить зависимости от них. Таким образом, если рассматриваемый DataTable собирается измениться регулярно, то кэширование является, вероятно, подходящим вариантом. Иначе, если это - статическая сессия, могло бы быть более соответствующим. у Steven Smith есть превосходное видео при кэшировании в dnrtv, который стоит проверить.

Это действительно зависит от того, чего Вы пытаетесь достигнуть, сколько времени Вы имеете. Существуют некоторые другие альтернативы для рассмотрения относительно того, как Вы храните состояние в приложении. В зависимости от того, насколько большой таблица, Вы могли рассмотреть хранение состояния в cookie (зашифрованный, если это - уязвимая информация). С другой стороны, если это - ограниченные по объему данные приложения Вы, холод использует статическое поле на странице или классе. Также существует Объект приложения.

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

Are they going to access the data frequently?

(Нет, не беспокойтесь). 

Is it going to change?

(Нет, используйте статическое поле или Приложение). 

Is it acceptable for user a and user b to see the same results?

(Нет, используйте кэш с включением ключа из имени пользователя и критерия поиска.).
(Да, используйте кэш с помощью ключа критерия поиска).

Честно, хотя, если бы Вы далеко не приезжаете в своей разработке, я рассмотрел бы парковку кэширующей/указанной проблемы на более позднюю дату - Вам даже, возможно, не понадобился бы он.

первые три правила настройки производительности: 1. Мера, 2. Измерьте еще немного. 3. Имейте размеры снова...

28
ответ дан Kiquenet 24 November 2019 в 14:35
поделиться

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

5
ответ дан Greg Ogle 24 November 2019 в 14:35
поделиться

Хорошо это зависит от того, как Вам настроили сессию для ASP.NET. Вы храните сессию в базе данных или в памяти? Если в памяти Вы используете отдельный сервер, или Вы используете текущий веб-сервер для сессии?

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

Также Сессия хранится на пользователя и получена на пользователя посредством их Сеансового билета, который хранится или в Сеансовых куки или на URL, если они не принимают куки, и Вы настроили ASP.NET к cookieless режиму. Что-либо, что Вы кэшируете, будет кэшироваться на прикладном уровне и будет доступно всем сеансам пользователя, которые могут или не могут быть тем, что Вы хотите.

5
ответ дан Andrew Hare 24 November 2019 в 14:35
поделиться

Сессия на пользователя, Кэш для приложения.

Объекты в Кэше могут и удаляться автоматически основанные на времени истечения срока (скольжение, или зафиксировал), и ограничения памяти рабочего процесса IIS.

, Таким образом, в основном объекты в Кэше, как никогда гарантируют, не будут существовать, но Сессия останется там, пока сессия не заканчивается.

объекты Хранения на основе в расчете на пользователя (через Сессию или творческое использование Кэша) могут привести к большому использованию памяти и должны быть рассмотрены тщательно.

вдобавок к все это, если IIS сбрасывает рабочий процесс, можно потерять Кэш и Сессию.

4
ответ дан Greg 24 November 2019 в 14:35
поделиться

См. этот ответ .

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

2
ответ дан Community 24 November 2019 в 14:35
поделиться

Насколько я знаю, все это зависит от Ваших потребностей.

Каждый раз, когда необходимо поддержать состояние для пользователей, затем необходимо быть очень осторожными при использовании сессий. Настройкой по умолчанию является 'InProc', который использует память отдельного сервера, не работает хорошо в Облачных приложениях. Это может быть применимо для тех из Вас, кто размещает Ваше приложение в средах веб-фермы мультиэкземпляра. Подсистема балансировки нагрузки Windows Azure использует циклическое выделение в связанных узлах.

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

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

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

, "Если у Вашего клиента нет облачной поддержки, то Вы не волнуетесь об облачных сценариях"

0
ответ дан 24 November 2019 в 14:35
поделиться
Другие вопросы по тегам:

Похожие вопросы: