some image

Работа

Все о meta теге управления режимами в Internet Explorer

Работа

Еще не встречал статьи на русском, где все бы было понятно разложено про X-UA-Compatible тег применительно к самому замечательному в мире браузеру.

Cуществует мета тег X-UA-Compatible, который в зависимости от переданного значения content заставляет различные версии IE отображать документ в том или ином режиме.

Это крутейшая фича для IE, поскольку иногда бывает так, что все вылизано до блеска в IE7, работает в IE9 а в восьмерке распадается. И тогда мы можем не тратить время на восьмерку, подсунув ей мета тег, и все будут счастливы.

Итак, встречаем:

<meta http-equiv="X-UA-Compatible" content="IE=5">
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">
<meta http-equiv="X-UA-Compatible" content="IE=7">
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8">
<meta http-equiv="X-UA-Compatible" content="IE=8">
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE9">
<meta http-equiv="X-UA-Compatible" content="IE=9">
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE10">
<meta http-equiv="X-UA-Compatible" content="IE=10">
<meta http-equiv="X-UA-Compatible" content="IE=edge">

Значение IE=5 принудительно переводит браузер в Quirks Mode.

Значения IE=7, IE=8, IE=9, IE10 принудительно переводят браузер в режим стандартов соответствующей версии независимо от DOCTYPE документа.

Значения IE=EmulateIE7, «IE=EmulateIE8″, «IE=EmulateIE9″, «IE=EmulateIE10″ заставляют браузер работать как соответствующая версия браузера. Т.е. если мы используем «IE=EmulateIE8″ в IE9, он будет решать какой режим использовать — quirks, ie7 или ie8 самостоятельно в зависимости от DOCTYPE, и только от него.

Значение IE=edge заставляет браузер переходить в последний доступный стандарт независимо от DOCTYPE.

Пример:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">
</head>
</html>

- будет использован режим IE7 во всех версиях начиная от IE7, но

<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">
</head>
</html>

- будет использован Quirks Mode во всех версиях IE

Internet Explorer 10

В IE10 стало 2 Quirks Mode: ie5 qurks и обычный. Первый включается тегом
<meta http-equiv=»X-UA-Compatible» content=»IE=5″>, а второй — отсутствием DOCTYPE.
Вот и все хитрости.

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

Про типы DOCTYPE можно почитать здесь: http://htmlbook.ru/html/!doctype

Нюансы работы PHP session.gc_maxlifetime

Работа

… или почему на некоторых хостингах сессии долго не живут.

Использование ini_set(‘session.gc_maxlifetime’, value); в коде приложения отнюдь не гарантирует сессиям долгую жизнь. Устанавливая эту директиву, вы лишь обеспечиваете, что garbage collector, запущенный из вашего приложения будет  удалять во временной папке сессии, ориентируясь на это время.

Если же garbage был запущен из другого скрипта со своими или дефолтными настройками, он будет удалять файлы, естественно, не оглядываясь на параметр из первого абзаца.

Пример. Вы установили в своем main приложении время жизни сессии 7 дней. Garbage, инициированный вашим приложением, заходит и удаляет все файл старше семи дней.

Но тут вы запускаете на этом же сервере скрипт rebuildDatabase.php, у которого этих настроек нет и берутся дефолтные из php.ini: 1 день. И срабатывает GC. В лучшем случае он удалит все сессии, которые должны были жить несколько дней. В худшем — повесит весь сервер если файлов на удаление оказалось очень много.

Так что на хостинге, где на одном сервере крутится много сайтов и администраторы не позаботились о разделении папок сессий, не редки ситуации, когда изменение  session.gc_maxlifetime просто не работает, т.к. кто-то другой поставил его меньше и постоянно выкашивает ваши сессии.

Мораль: используя в своем проекте ini_set(‘session.gc_maxlifetime’, value), всегда меняйте дефолтную папку вызовом ini_set(‘session.save_path’, value). Ну и про глюки garbage collector php не забываем.

Не удаляются файлы сессий PHP

Метки: , , , Работа

Частая проблема — tmp папка web сервера вдруг содержит n миллионов файлов. Скорее всего это файлы сессий. И образовались они там не вдруг, а за пару месяцев/лет.

Диагностируем

Во первых, затруднительно посмотреть, что находится в папке, т.к. ни FAR, ни виндовый проводник (серверы с проблемой были на windows) не хотят такую папку открывать (FAR вылетал забрав 1гб оперативной памяти, где-то на чтении трехмиллионного файла). Как зайти в папку, содержащую много файлов? Переходим в папку в консоле через cd (переходит махом не зависимо от количества файлов) и пишем:

dir /p

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

Исправляем

Что же произошло и почему garbage collector (далее GC) PHP забил на вашу tmp папку и сто лет ее не чистил?

1) Возможно, не правильно заданы параметры php.ini  session.gc_probability и session.gc_divisor. Вероятность запуска GC при каждом запуске скрипта - session.gc_probability / session.gc_divisor. По умолчанию — 1/100. Соответственно, если задать session.gc_probability = 0 GC не запустится никогда. Соответсвующие параметры нужно проверить и в коде приложения.

2) Возможно, вы изменили session.save_path в своем приложении, и теперь она отличается от той, которая в php.ini. В этом случае GC чистить в вашей кастомной папке ничего не будет и вам нужно заботиться об этом самим, т.к. он чистит только папку, которая указана в ini. Цитата из конфигурационного файла:

; NOTE: If you are using the subdirectory option for storing session files
; (see session.save_path above), then garbage collection does *not*
; happen automatically. You will need to do your own garbage
; collection through a shell script, cron entry, or some other method.
; For example, the following script would is the equivalent of
; setting session.gc_maxlifetime to 1440 (1440 seconds = 24 minutes):
; cd /path/to/sessions; find -cmin +24 | xargs rm

3) Последнее, самое непонятное. Возможно, вы стали жертвой бага - https://bugs.php.net/bug.php?id=55333 Не знаю, правда это или нет, и баг ли это php или криворукость админов, но у меня на двух серверах, где не была изменена папка сессий по умолчанию, и все сохранялось в «C:/Windows/Temp», GC не работал. И это при абсолютной идентичности других настроек с серверами, где папка была изменена и все было ок. Решил проблему просто — сменил папку с дефолтной на свою, чего и вам желаю.

Удаляем

В tmp папке на момент решения проблемы было 4 миллиона файлов. Удалил их просто:

del sess_*

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

Для Linux серверов есть хорошая статья на хабре: http://habrahabr.ru/post/152193/

Принудительное уменьшение объема файла данных SQL server

Метки: , Работа

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

Read More