1 / 115

Запуск и эксплуатация веб-проектов

Запуск и эксплуатация веб-проектов. Александр Демидов Руководитель направления арендных решений «1С-Битрикс». «На старт…». Каким будет новый проект?. Разные классы сайтов и веб-сервисов: Домашние странички, личные блоги и т.п. «Продающие» сайты (интернет-магазины)

philip-clements
Download Presentation

Запуск и эксплуатация веб-проектов

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Запуск и эксплуатация веб-проектов Александр Демидов Руководитель направления арендных решений «1С-Битрикс»

  2. «На старт…»

  3. Каким будет новый проект? Разные классы сайтов и веб-сервисов: Домашние странички, личные блоги и т.п. «Продающие» сайты (интернет-магазины) Имиджевые сайты (в том числе и корпоративные) «Businesscriticalapplication» - веб-сервисы, использующиеся в работе (CRM, учет, таск-менеджмент, почта и т.п.)

  4. На старте проекта заказчик и разработчик могут не знать, каким он станет, но должны заранее определить «ТЗ на эксплуатацию».

  5. Новый проект – какой он? Определяют требования заказчика Если сам заказчик не сумеет определиться с требованиями, помогите ему. Количество хитов в сутки Скорость загрузки главной страницы при указанном количестве хитов Скорость загрузки критичных разделов Среднее время загрузки всех страниц в сутки Процент страниц с временем загрузки более n сек. Допустимый процент ошибок Допустимое время простоя ...

  6. Почему сайт должен быть всегда доступен? Клиенты и их лояльность (сайт недоступен – потеряны заказы). Индексация сайта поисковыми роботами Финансовые потери во время рекламных компаний Стоимость контекстной рекламы

  7. Не бывает «почти круглосуточно» Технические работы должны проходить незаметно для клиентов: Сервисные работы Замена оборудования Обновления системного ПО Обновления приложений

  8. Почему сайт должен быть быстрым? Замедление загрузки страницы на 1 секунду снижает конверсию на 7%, а количество просмотров - на 11%.

  9. «Внимание…»

  10. Виды хостинга • Виртуальный (shared) • VPS • Dedicated/Colocation • «Облако»

  11. Эксплуатация: выбор инфраструктуры Риски: Взять слишком много и переплатить (не можем заранее спрогнозировать потребление ресурсов) Взять слишком мало и «просесть» по производительности Безопасность (если в штате нет толкового системного администратора) Надежность (как резервировать доступность на уровне датацентра?) Сетевая доступность

  12. Виртуальный (shared) хостинг Это – всегда «общежитие». • Самый простой вариант • Хороший хостинг снимает практически всю головную боль (бэкапы, резервирование и т.п.) • Мало настроек • Мало ресурсов • Мало «путей отступления»

  13. «Железо» VS. «Облако»

  14. Экономия? Самый частый посыл к переходу на «облака» вообще(и IaaS – в частности) – уменьшение затрат, экономия.

  15. Не дешевле? • В прямом сравнении железа и аналогичного по конфигурации облака – облако почти всегда проигрывает • Почти всегда отдельно рассчитывается стоимость траффика • Сложность расчетов при оплате «по потреблению» • При оплате «по потреблению» при резком росте нагрузки (DDoS, «хабраэффект», ошибки в разработке) возможны значительные расходы (в разы больше запланированных)

  16. Где реальная экономия? • Нет инсталляционных платежей (для больших проектов – если речь идет о покупке собственного оборудования) • Минимальные финансовые риски на старте нового проекта • Обслуживание системы • Экономия времени

  17. Масштабирование в облаке? • Без готовности приложения к масштабированию – не имеет практического смысла

  18. Масштабирование

  19. Надежность? • Виртуальные машины ребутятся чаще физического «железа». • Amazon AWS – как минимум: • апрель 2011, август 2011, июнь 2012, декабрь 2012… • «Лежали» Foursquare, Instagram, Netflix, Pinterest… • Облако само по себе не дает надежность. Облако дает возможность построить надежную инфраструктуру.

  20. Можно побольше ресурсов? • Есть выделенные ресурсы – RAM, CPU, HDD: попросил-выделил-заплатил; • Есть разделяемые ресурсы – кэш процессора, IOPS,... Ни у одного облака нельзя попросить обеспечить N IOPS в течение K минут. Можно только понадеяться.

  21. Инфраструктура: «Железо» vs. «Облако» • Затраты (время) на обучение сотрудников специфике конкретного сервиса • Ограничения инфраструктуры (аппаратная часть, специфичное ПО) • Сложность расчетов «по потреблению» • Экономия за счет возможности планирования ресурсов • Экономия и отсутствие рисков, связанные с вложениями в инфраструктуру • Моментальное вертикальное и горизонтальное масштабирование • Удобство администрирования • Экономия времени

  22. Инфраструктура: «Железо» vs. «Облако» • CPU и RAM – по требованию • Возможность построить масштабируемую инфраструктуру • Возможность построить отказоустойчивую инфраструктуру • Дополнительные сервисы • Медленные диски • Нельзя гарантированно получить некоторые ресурсы • Ложное ощущение гарантий безопасности и отказоустойчивости

  23. Безопасность и надежность Дополнительные сервисы (например, Amazon S3) • Доступность – 99.99% • Надежность – 99.999999999% • ACL • Версионность • Шифрование (server-side, client-side)

  24. Зачем нам нужен cloudstorage? • Снижаем стоимость эксплуатации • Можем использовать совместно с CDN • Снижаем нагрузку на web-узлы • «Легкий» сайт – легко переезжать и бэкапить • Синхронизация контента между множественными web-узлами • Ускоряем рендеринг страниц в браузере

  25. …и другие сервисы: • Автомасштабирование • Мониторинг • Балансировщики • Облачные базы данных • Облачные NoSQL • Облачный кэш • …

  26. Немного нюансов настройки веб-сервера

  27. Настройки «по умолчанию» – это далеко не всегда хорошо Типовые ошибки/проблемы/недостатки конфигурации: PHP как CGI (не путать с FastCGI) open_basedir Не установлен прекомпилятор PHP Недостаточно памяти прекомпилятору Медленная файловая системаи/или мало дискового кэша Отсутствует FrontEnd (nginx) ngnix есть, но всю статику запрашивает у Apache Не отрегулировано значение MaxClients в Apache И т.д.

  28. Традиционное устройство веб-приложения Веб-приложение Кэширование на диск База данных

  29. Одноуровневая схема Каждый запрос – обычно отдельный процесс Любой процесс может обработать любой запрос (статика, скрипт) Каждый процесс – десятки и сотни Мб Пока не закончен запрос, процесс не принимает новый

  30. Узкие места Отдача контента – медленные каналы Производительность PHP (в том числе – запросы к внешним ресурсам и т.п.) Обмен с БД (пропускная способность канала, latency, объем данных в приложении; использовать ли persistent connection?) Скорость работы БД Отдача статики – много памяти на простую задачу

  31. Если оставить все «по умолчанию»? По умолчанию MaxClientsв Apache 2.x – 256 Если PHP может занять 64 Мб (на самом деле – см. memory_limit в php.ini) – весь веб-свервер может занять 16 Гб RAM 256 потенциальных коннектов к MySQL Память для одного коннекта: read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + join_buffer_size swap, OOM, деградация производительности всей системы

  32. Двухуровневая схема Frontend – чаще всего nginx Backend – Apache, PHP-FPM

  33. Некоторые ключевые моменты настройки Backend 192.168.1.1:8888 +Можно обращаться снаружи мимо фронтенда - Могут возникнуть лишние редиректы 127.0.0.2:80 - Нельзя обращаться снаружи мимо фронтенда + Нет проблем с неправильным портом

  34. Backend Сбалансированность по памяти StartServers10 MinSpareServers 10 MaxSpareServers 20 MaxClients 20 MaxRequestsPerChild500 Обрабатывать только «свое» (проверить лог – убедиться, что нет попаданий статики).

  35. Frontend # cat /proc/cpuinfo | grep "processor" | wc -l worker_processes 8; # max_clients = worker_processes * worker_connections events { use epoll; worker_connections 10240; } http { # поумолчанию - 1m client_max_body_size 1024m;

  36. Frontend # больше - больше памяти, меньше - чаще пишем на диск client_body_buffer_size4m; # максимально быстро получаем ответ от бэкенда proxy_bufferingon; gzip on; gzip_proxied any; gzip_static on; gzip_types application/x-javascripttext/css; gzip_min_length1100;

  37. А без Apache? PHP-FPM http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html Найти все .htaccessи перенести логику в конфигnginx upstream backend { server unix:/opt/php/var/run/php1.sock; server unix:/opt/php/var/run/php2.sock; server unix:/opt/php/var/run/php3.sock; }

  38. А без Apache? PHP-FPM location ~ \.php$ { root /var/www/chroot/var/www/html; fastcgi_intercept_errorson; fastcgi_passbackend; fastcgi_indexindex.php; include fastcgi_params; fastcgi_param DOCUMENT_ROOT /var/www/html; fastcgi_param SCRIPT_FILENAME /var/www/html/$fastcgi_script_name; fastcgi_paramSERVER_NAME $host; fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_param PATH_INFO $fastcgi_path_info; }

  39. php-fpm.conf ;рестартовать при ошибках emergency_restart_threshold= 1 emergency_restart_interval = 10 [www1] listen=/opt/php/var/run/php1.sock # echo 10240 > /proc/sys/net/core/somaxconn listen.backlog= 10240 pm = static pm.max_children= 5 pm.start_servers = 5 pm.min_spare_servers = 5 pm.max_spare_servers = 5

  40. php-fpm.conf request_slowlog_timeout = 5 slowlog= /opt/php/var/log/www.slow_access.log ; не open_basedirв php.ini !!! chroot = /var/www/chroot php_admin_value[memory_limit] = 256M security.limit_extensions= .php [www2] ; ---------- // ---------------- ; разные chrootдля виртхостов ; разные лимиты

  41. Прекомпиляторы Zend Optimizer+ (Zend Server) – самый быстрый… и самый «непрозрачный» eAccelerator APC extension=apc.so apc.enabled=1 apc.max_file_size=5M apc.shm_size=256M apc.ttl=7200 apc.num_files_hint=55000

  42. apc.php

  43. Итог Система стабилизирована по памяти Нет деградации системы при возрастающей нагрузке – обслуживаем максимум запросов, остальные ожидают в очереди Можем попробовать persistent connections для базы – у нас фиксированное число процессов Не тратим память на отдачу статики Не занимаем backend медленными запросами клиентов Используем сжатие – быстрее отдаем на медленных каналах Разгружаем процессор за счет прекомпиляцииPHP

  44. Немного нюансов настройки базы данных

  45. Приоритет Производительность? Надежность? Вместе – не получается…

  46. Что может оказаться «узким местом»? CPU? RAM? Диск? Всё!

  47. Как определить конфигурацию RAID для базы? Любое решение выбирается, исходя из конкретной поставленной задачи. Для работы MySQL используем InnoDB. Следовательно, необходимо эффективно работать с операциями random read/write на больших файлах (ibdata). Тесты sysbench Работы с одиночным файлом 16 Гб в режиме random read/write. При увеличении количества потоков единичный диск почти сразу достигает «потолка», производительность RAID растет.

  48. Диагностика top free iostat –x 2 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-szavgqu-sz await svctm %util xvde0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 xvdj 0.00 0.00 0.00 13.00 0.00 464.00 35.69 0.07 5.50 1.42 1.85 xvdi 0.00 0.00 0.00 13.00 0.00 464.00 35.69 0.09 7.27 1.50 1.95 xvdh 0.00 0.00 0.00 39.50 0.00 1436.00 36.35 0.17 4.39 0.76 3.00 xvdg 0.00 0.00 0.00 39.50 0.00 1436.00 36.35 0.21 5.32 0.84 3.30 xvda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 xvdo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 xvdn 0.00 0.00 0.00 16.50 0.00 468.00 28.36 0.16 9.64 0.97 1.60 xvdm 0.00 0.00 0.00 16.50 0.00 468.00 28.36 0.15 8.88 0.88 1.45 xvdl 0.00 0.00 0.00 12.50 0.00 328.00 26.24 0.16 12.68 1.72 2.15 xvdk 0.00 0.00 0.00 12.50 0.00 328.00 26.24 0.10 7.64 1.16 1.45 md0 0.00 0.00 0.00 73.50 0.00 2680.00 36.46 0.00 0.00 0.00 0.00

  49. Диски и tmpfs # cat /etc/fstab # <file system> <mount point> <type> <options> <dump> <pass> tmpfs /dev/shmtmpfs defaults 0 0 /dev/md0 /mnt/ext4_raid10_8 ext4 defaults,noatime,nodiratime,data=writeback,barrier=0 0 0

More Related