Analitycs

Показаны сообщения с ярлыком memcache. Показать все сообщения
Показаны сообщения с ярлыком memcache. Показать все сообщения

понедельник, 21 мая 2012 г.

Memcache не запоминает данные больше чем на 30 дней (expiration time)

При при попытке сохраненить данных в Memcache на срок больше чем на 30 дней (2 592 000 секунд) - данные не запоминаются ВООБЩЕ.

Кто виноват и что делать?

Сохранять в timestamp + expiration time - на Tornado/Python это выглядит как-то так

from datetime import datetime, timedelta
import tornado.escape

class MyApplication():

    def get_expire_time(self):
        start = datetime.now()
        session_length = self.settings['session_time']
        
        delta = timedelta(seconds=session_length)
        expires = start + delta
        return expires

    def save_session(self, data)
        end_time = time.mktime(self.get_expire_time().timetuple())
            
        self.mc.set(key, tornado.escape.json_encode(data), end_time)

Навеяно StackOverflow

воскресенье, 25 декабря 2011 г.

Как оптимизировать сервер? - реальные данные - теория без практики мертва

Это судьба - вслед за вчерашней заметкой про оптимизацию выделенного сервера на сайте были опубликованы весьма интересные материалы, которые привели к росту просмотров страниц на 54 тысячи - это составляет рост примерно 140%.

Итак, график LI

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


Трафик, прокачанный через firewall - разумеется, вырос, причем - значительно



Процессы и потоки - увеличились



MySQL немного изменился в пределах погрешности; коннекты - не изменились.





Memcache немного подрос, но незначительно


А самое главное - ЦПУ и Load Average практически не изменились

Вывод

nginx с кешом HTML страниц сильно спасает от резких скачков нагрузки от незарегестрированных пользователей.

Рискну предположить, что создатели многих супер-пупер-мега-стартапов, постоянно падающих от пресловутого великого и ужасного Хабраэффекта, об этом не знают ;-)

З.Ы. Люблю, когда теоретические выкладки подтверждаются практическими данными.


суббота, 24 декабря 2011 г.

Как настроить сервер? или оптимизация сайтов на PHP (Nginx, PHP, MySQL, Memcache)

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

Если же вы еще и не профессиональный HighLoad Linux-админ, а, например, разработчик (как я), то в процессе настройки прийдется ловить много-много граблей...  ;-)

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

Ниже рассматривается достаточно часто встречаемая комбинация для сайтов: nginx + php (nginx+apache c php немного отличается - вместо fastcgi_xxx будет proxy_xxx).

Да, и считаем, что сейчас все компоненты вашей системы (nginx, php, mysql, memcache) крутятся на одной машине - как оно обычно и бывает на частных ресурсах.

PHP


  • Пускаем как fastcgi через сокет
  • Pconnect к базе - спорно
  • Не забываем акселератор (моя юзает eAccelerator) - хотя тоже есть спорные моменты

eAccelerator


Только для production машин можно отключить проверку Modified time - это абсолютно не подходит, если на сервере идет отладка скриптов - иначе будете ловить постоянные глюки и проблемы - включать только после того как сайт стал стабилен.

eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="0"
eaccelerator.shm_only="1"

Временые диски

tmpfs для /tmp и сессий PHP - все это сносится в память, если ее достаточно. В /etc/fstab добавляем

tmpfs                   /tmp                    tmpfs   defaults        0 0
tmpfs /var/lib/php tmpfs size=200M,nr_inodes=1m,nosuid 0 0

MySQL

  • Проверяем, включен ли query кэш
  • Также используем сокет
  • Если в вашей CMS используется таблица сессий - ставим для них тип MEMORY (если нет текстовых полей) - это приведет к сбросу всех залогиненных пользователей при перезагрузке сервера, но добавит немного скорости. Ну или если это неприемлемо - то надеюсь, она уже переведена в InnoDB? ;-)
  • Определяем оптимальное количество коннектов - статистика хотя бы за месяц (я юзаю munin). Ставим в 1.5-2 раза больше среднего.
Более подробно про оптимизацию MySQL можно прочитать тут.

Memcache

Если вся солянка крутится на одной машине - то также используем коннект через сокеты (по умолчанию не используется - стоит ip адрес). В таком варианте работы memcache возможны проблемы с некоторыми средствами мониторинга memcache (которые работают также по IP).

Не забываем в PHP использовать сжатие при работе с MEMCACHE.

Nginx

Ограничиваем число коннектов и запросов, особенно на ресурсоемкие скрипты
http {
...
    limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;
    limit_zone three $binary_remote_addr 10m;

Включаем кэширование для неавторизованных гостей

http {
...
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=wholepage:50m inactive=15d max_size=5000m;
        location ~ .*\.php$ {
            limit_conn three 20;
            include         /etc/nginx/fastcgi.conf;
            fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_pass    unix:/var/run/php-fastcgi/php.socket;
            #access_log  /var/log/nginx/domain.access.log  my_combined;
            fastcgi_cache wholepage_guest;
            fastcgi_cache_valid 301 302 304 10m;
            fastcgi_cache_valid 200 360m;
            fastcgi_cache_valid 404 5s;
            fastcgi_cache_key "$request_method|$host|$request_uri";
            fastcgi_pass_header "Set-Cookie";
            fastcgi_ignore_headers "Cache-Control" "Expires";
            fastcgi_cache_bypass $cookie_phpbb_session $arg_nocache $arg_PHPSESSID;
            fastcgi_no_cache $cookie_phpbb_session $arg_nocache $arg_PHPSESSID;
    }
Где phpbb_session - имя куки по которой идет авторизация

Все запросы с ?nocache=1 и PHPSESSID попадают на PHP-бэкенд сразу без кэша не забываем открыть скрипт, по которому идет авторизация (в том числе и всякие капчи - их можно переписать на ?nocache=1) - тут возможно прийдется немного поковыряться и в коде CMS тоже.

        location /register.php {
                limit_conn three 20;
                include         /etc/nginx/fastcgi.conf;
                fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_pass    unix:/var/run/php-fastcgi/php.socket;
        }

Nginx - общие рекомендации

Очень нежелательно использовать location с регекспами - только простые префиксы вида
location /mymodule {}
Если от регекспов никак не избавится - то лучше их обрамлять простым location (Причина - сложноуловимые перехлесты в логике парсинга URL - кто за кем будет следовать)
location /mymodule {
  location ~ \/mymodule\/(.*)\.php$ {
    чего-то
  }

}

Отрубаем access лог для картинок

Разумеется - это только основные моменты оптимизации, на самом деле их гораздо больше. А какие трюки для уменьшения нагрузки на сервер знаете вы? Пишите в комментах.

В этом гаджете обнаружена ошибка