- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый день. Интересует организация SaaS сервисов на php, в связи с чем возникло несколько вопросов по поводу разгрузки\масштабирования приложения.
Есть сайт-самопис, база на n млн записей, нагрузка скажем в 200 запросов страниц/с.
Масштабирование базы в общих чертах представляю, делается репликация базы, пул соединений и запросы поочередно разбрасываются в разные базы. Беспокоюсь за дисковую систему, что её банально не хватит. В связи с этим хочу всю статику на сайте вынести на отдельный сервер с поддоменами вида cdn1.site.ru, cdn2... Вопрос в следующем - впринципе в фоне можно организовать загрузку статического контента по фтп на цдн, но в отношении тех же фотографий - их часто приходится ресайзить. Ставить туда php и обрабатывать запросы\ресайзить на лету можно, но не хотелось бы.
Вообще был бы рад любой информации по организации хайлоад\их масштабировании\современных применяемых технологиях.
Пока для себя сделал вывод что подойдет стандартная связка php+mysql+memcache запросов. Может я что-то интересное упускаю? Есть ли тематические ресурсы, посвященные данной теме?
Очень узкая ниша, потому и литературы минимум :)
В принципе база+язык могут быть любыми, на чём угодно можно написать масштабируемое приложение.
По сообщению трудно понять, какая структура будет у системы, кроме того, что много серверов :)
Отсюда посмотреть бы http://www.highload.ru/
У меня, в частности, есть опыт написания системы, где картинки ресайзятся на лету на серверах, которые недостающее скачивают с главного сервера и ресайзят 1 раз, потом выдают статику. Вопрос - сколько всего картинок, стоит ли хранить на 1 сервере, или распределять. Информация из базы берётся с главного, кешируется в каждом подключенном сервере. Статистику делает отдельный сервер, который собирает обработанные данные со всех серверах с некоторым интервалом. Для каждого приложения надо отдельно весь этот механизм разрабатывать, тут не всё так универсально :)
Краткую характеристику привёл как пример, уверен, у вас будет по-другому :)
Вообще был бы рад любой информации по организации хайлоад\их масштабировании\современных применяемых технологиях.
Для начала, настоятельно рекомендую послушать мастер-клас Олега Бунина http://iforum.ua/topic/33
Цитата для интриги: "За этот час я попробую дать вам набор ИНСТРУМЕНТОВ для построения высоконагруженных систем. Я не расскажу о том, как правильно, но расскажу о том, как ВОЗМОЖНО. Раскрою пару десятков инструментов, которые применяются архитекторами крупных проектов. Какие из них использовать в своей работе - уже решать вам."
Масштабирование базы в общих чертах представляю, делается репликация базы, пул соединений и запросы поочередно разбрасываются в разные базы.
К сожалению, в реальной жизни, не все так просто: поскольку репликация асинхронна, реплики отстают от машин, куда сделан инсерт/апдейт. То есть, если следующий после инсерт/апдейт запрос уйдет на реплику до того, как они синхронизирутся, можно получить устаревшие или некорректные данные.
Поэтому и появляются проекты типа django-replicated, который использует Яндекс и http://community.invisionpower.com/files/file/3841-high-performance-mysql-driver/ для IPS.
Если Ваш интерес к теме перейдет в плоскость практических решений, обращайтесь, контакты в профиле, люблю строить не стандартные системы :).
---
Виктор
Для начала, настоятельно рекомендую послушать мастер-клас Олега Бунина http://iforum.ua/topic/33
Цитата для интриги: "За этот час я попробую дать вам набор ИНСТРУМЕНТОВ для построения высоконагруженных систем. Я не расскажу о том, как правильно, но расскажу о том, как ВОЗМОЖНО. Раскрою пару десятков инструментов, которые применяются архитекторами крупных проектов. Какие из них использовать в своей работе - уже решать вам."
К сожалению, в реальной жизни, не все так просто: поскольку репликация асинхронна, реплики отстают от машин, куда сделан инсерт/апдейт. То есть, если следующий после инсерт/апдейт запрос уйдет на реплику до того, как они синхронизирутся, можно получить устаревшие или некорректные данные.
Поэтому и появляются проекты типа django-replicated, который использует Яндекс и http://community.invisionpower.com/files/file/3841-high-performance-mysql-driver/ для IPS.
Если Ваш интерес к теме перейдет в плоскость практических решений, обращайтесь, контакты в профиле, люблю строить не стандартные системы :).
---
Виктор
Спасибо, заинтриговали :)
но в отношении тех же фотографий - их часто приходится ресайзить.
http://habrahabr.ru/post/77873/
http://nginx.org/ru/docs/http/ngx_http_image_filter_module.html
Есть ли тематические ресурсы, посвященные данной теме?
highload.ru, материалы конференций (фото в комментах, презентации-тезисы на сайте, если поискать - наверняка есть и видео, что посвежее - платное.. Но, если очень хорошо поискать...)