Comments 17
А не проще поставить, например, RabbitMQ (или любую другую реализацию очереди) в котором это все уже есть? И работает быстрее? И по стандартному протоколу, который поддерживается кучей решений, библиотек, фреймворков итд итп?
И квотирование организовать опять же стандартным алгоритмом на уровне обработчиков, вообще не трогая базу лишний раз (http://en.wikipedia.org/wiki/Leaky_bucket)?
И квотирование организовать опять же стандартным алгоритмом на уровне обработчиков, вообще не трогая базу лишний раз (http://en.wikipedia.org/wiki/Leaky_bucket)?
RabbitMQ — это новая сущность, которую нужно устанавливать, настраивать и поддерживать. MySQL у нас уже есть, мы умеем его готовить. Как мы писали, миграция фотографий — это одна из частей всей миграции пользователей. То есть в базе хранится много других данных, которые хочется обрабатывать транзакционно. Вынеся часть данных в RabbitMQ мы такую возможность потеряем. Что касается скорости — нас вполне устроили полученные результаты, и если говорить именно о задаче миграции фотографий, то здесь MySQL не являлся узким местом.
А вы вместо него написали свою очередь, и ее тоже нужно устанавливать, настраивать и поддерживать. Тем более что инструмент этот не навсегда, а только для обслуживания переезда. Я взглянул на RabbitMQ, там действительно все очень просто и с подробным туториалом. У вашего подхода я вижу только один плюс — есть о чем рассказать в посте
Не могу не высказаться в поддержку rabbitmq любят у вас там гвозди закручивать отвёртками...
Настраивать там на самом деле нечего (у меня очереди по 2.7млн сообщений обслуживались установленным из стандартного репозитория Ubuntu стандартным же rabbitmq, в конфиг вообще не заглядывал).
Падающие воркеры прекрасно обрабатываются за счёт отложенного ACK (консьюмер забрал сообщение из очереди а потом закрыл коннект (умер) не прислав ACK — сообщение возвращается обратно в очередь).
Можно для каждого фотосервера создать отдельную очередь и следить по длинне очереди за прогрессом. Можно воркеров подключать к нескольким очередям, можно перекидывать между ними.
Насчёт транзакционности не знаю — в посте об этом не было сказано. На мой взгляд проблема надуманная, но вам виднее наверное.
Настраивать там на самом деле нечего (у меня очереди по 2.7млн сообщений обслуживались установленным из стандартного репозитория Ubuntu стандартным же rabbitmq, в конфиг вообще не заглядывал).
Падающие воркеры прекрасно обрабатываются за счёт отложенного ACK (консьюмер забрал сообщение из очереди а потом закрыл коннект (умер) не прислав ACK — сообщение возвращается обратно в очередь).
Можно для каждого фотосервера создать отдельную очередь и следить по длинне очереди за прогрессом. Можно воркеров подключать к нескольким очередям, можно перекидывать между ними.
Насчёт транзакционности не знаю — в посте об этом не было сказано. На мой взгляд проблема надуманная, но вам виднее наверное.
Возможно это прозвучит немного странно, но по опыту работы с высоконагруженными проектами (и серверами в нескольких странах), очень часто свой странный и нелогичный местами костыль работает быстрее и надежнее, чем специализированное ПО, не говоря уже о возможностях контроля и гибкости (при условии если есть понимающий человек конечно же).
Впервые это ощутил при настройке nginx, который дико валился по инструкциям (аля кол-во воркеров от числа ядер или как то так), но уже 2 года отлично работает со странным конфигом и ни разу не оказался узким местом. Самое узкое место на данный момент — готовый фреймворк, которые очень хвалят по всему интернету, а в реальности он тупо жрет ресурсы и оптимизации почти не поддается. Для примера — есть 2 скрипта для проверки авторизации, логика 1 к 1 у обоих, но первый написан с использованием фреймворка и на равном месте иногда до 23 секунд (да да! 23 секунды, почти половина минуты) повисает, другой напрямую без всяких оберток, ООП и т.д. дергает базу и стабильно работает с предсказуемым временем не более 0.01 секунды.
Впервые это ощутил при настройке nginx, который дико валился по инструкциям (аля кол-во воркеров от числа ядер или как то так), но уже 2 года отлично работает со странным конфигом и ни разу не оказался узким местом. Самое узкое место на данный момент — готовый фреймворк, которые очень хвалят по всему интернету, а в реальности он тупо жрет ресурсы и оптимизации почти не поддается. Для примера — есть 2 скрипта для проверки авторизации, логика 1 к 1 у обоих, но первый написан с использованием фреймворка и на равном месте иногда до 23 секунд (да да! 23 секунды, почти половина минуты) повисает, другой напрямую без всяких оберток, ООП и т.д. дергает базу и стабильно работает с предсказуемым временем не более 0.01 секунды.
А что за фреймворк, если не секрет, чтобы не напороться на грабли.
Если на проекте не куча народу постоянно и трафик не 1-2 Гбит/с, то не стоит переживать за название и можно использовать любой.
Как бы меня не заминусовали любители этого чуда… В моем случае CodeInginter (наследие прошлого девелопера) то и дело подсовывает сюрпризы, которые в начале проекта никак себя не проявляли и вообще намека не было на будущие проблемы. В итоге времени на переписывание и оптимизацию уходит больше, чем на новые фичи, но скоро надеюсь полностью отвяжемся от этого ужаса и будет чистый php и python.
зы: не стоит писать что CI фигня, а %framework% лучше, они все хорошие, но начинают тупит при увеличении нагрузки и в итоге то тут, то там приходится этот самый фреймворк допиливать.
Как бы меня не заминусовали любители этого чуда… В моем случае CodeInginter (наследие прошлого девелопера) то и дело подсовывает сюрпризы, которые в начале проекта никак себя не проявляли и вообще намека не было на будущие проблемы. В итоге времени на переписывание и оптимизацию уходит больше, чем на новые фичи, но скоро надеюсь полностью отвяжемся от этого ужаса и будет чистый php и python.
зы: не стоит писать что CI фигня, а %framework% лучше, они все хорошие, но начинают тупит при увеличении нагрузки и в итоге то тут, то там приходится этот самый фреймворк допиливать.
Действительно, очень странно. Там же просто нечему тормозить :-) Обычно php-код не является узким местом и все его проблемы решаются дополнительными серверами. Конечно, так и хочется Вам посоветовать другой, гораздо более производительный фреймворк, который наверно, сможет помочь, но не буду :-) Потому что настоящий high-load лучше действительно писать с нуля.
Мне кажется сложно изначально всё просчитать и сразу же написать идеальный код, в моем случае уже был проект на CI, его надо было доводить до ума (в итоге от старого варианта остались почти только названия таблиц в базе). Пока юзеров и данных было мало, всё шло отлично, теперь то тут, то там переписываю архитектуру, убираю/упрощаю код, но как не крути, отдельные/самостоятельные части, написанные на чистом php почти не сбоют, всё что использует фреймворк — иногда тупит на ровном месте.
Наверное для highload профи это не новость (привет КО), но для себя сделал несколько заметок по мере переписывания старого кода и решения разных проблем:
0) не решать проблему, пока её нет — в частности не заниматься оптимизацией, пока не стало 100% ясно где узкое место
1) под всё что можно — очереди, выполняюся они быстро, но при резком (а это не часто) увеличении нагрузки сервер не загнется
2) кеш на 1-3 секунды в redis (или аналоги) офигенно снимает нагрузку со всего, если конечно система не критична к актуальным данным
3) свою работу с сессиями с учетом нужд и особенностей проекта не связаную никак с дисками (т.е. только в памяти всё)
4) любые сложные участки разбивать на куски (см п.1), и хорошо бы разбивать по серверам
5) куча избыточных данных в таблицах, чтобы как можно меньше джойнить и вообще стараться делать запросы не сложнее SELECT item1, item2 FROM table WHERE key=123;
6) уводить на сторону клиента (JS) всё что можно, в идеале php должен заниматься только проверкой кеша, запросами к базе и отдачей этих данных клиенту
7) использовать консольные утилиты в Linux по максимому
8) не писать больше ничего подобного с использованием фреймворков как на стороне сервера, так и не стороне клиента — да, это сложнее, дольше и геморойнее, но это в итоге дает хороший прирост производительности
Ну и слушать советы и сразу принимать на веру что-то не стоит (к этому сообщению это так же имеет отношение), т.к. всё сильно зависит от проекта. Более того — почти все советы выше вредны обычным сайтам — профита никакого, а гемороя с написанием/поддержкой море.
Наверное для highload профи это не новость (привет КО), но для себя сделал несколько заметок по мере переписывания старого кода и решения разных проблем:
0) не решать проблему, пока её нет — в частности не заниматься оптимизацией, пока не стало 100% ясно где узкое место
1) под всё что можно — очереди, выполняюся они быстро, но при резком (а это не часто) увеличении нагрузки сервер не загнется
2) кеш на 1-3 секунды в redis (или аналоги) офигенно снимает нагрузку со всего, если конечно система не критична к актуальным данным
3) свою работу с сессиями с учетом нужд и особенностей проекта не связаную никак с дисками (т.е. только в памяти всё)
4) любые сложные участки разбивать на куски (см п.1), и хорошо бы разбивать по серверам
5) куча избыточных данных в таблицах, чтобы как можно меньше джойнить и вообще стараться делать запросы не сложнее SELECT item1, item2 FROM table WHERE key=123;
6) уводить на сторону клиента (JS) всё что можно, в идеале php должен заниматься только проверкой кеша, запросами к базе и отдачей этих данных клиенту
7) использовать консольные утилиты в Linux по максимому
8) не писать больше ничего подобного с использованием фреймворков как на стороне сервера, так и не стороне клиента — да, это сложнее, дольше и геморойнее, но это в итоге дает хороший прирост производительности
Ну и слушать советы и сразу принимать на веру что-то не стоит (к этому сообщению это так же имеет отношение), т.к. всё сильно зависит от проекта. Более того — почти все советы выше вредны обычным сайтам — профита никакого, а гемороя с написанием/поддержкой море.
по-моему это прописная истина: хочешь скорость, забудь про фреймворки
Слабо верится. Фреймворк конечно замедляет выполнение процесса, но 23 секунды — это из области фантастики. Скорее всего где-то в фреймворке что-то не так используется, где-то неявные лишние вызовы чего-то, запись в папку с миллионом файлов или sleep(23) от предыдущего недовольного сотрудника
Примерно год назад переносил данные между датацентрами (около 20ТБ) на разных континентах, аналогично сперва перекинул всё что есть, т.к. юзеры много не зальют, заняло правда около месяца, т.к. сервера еще CDN и мелкие php демоны, мучающие файлы, убирающие дубликаты, ресайзеры/превьюшиники и т.д.
Файлы в таблице хранились с индексом сервера, т.е. после переноса всех файлов, запустил rsync*, чтобы постоянно стартовал и копировал и когда убедился что файлы на новом месте, то сделал update поля с индексом сервера, потом дожлася когда закончаться все загрузки со старого сервера и почистил хранилище.
* rsync напрямую работал медленее, чем если примонтировать хранилище через sshfs (самый быстрый вариант оказался от 23 МБайта/с и больше) + rsync, копировал не все сразу, а отдельно файлы до 100мб и отдельно больше 100мб, иначе копирование иногда затыкалось по непонятной причине или просто очень медленно шло.
Файлы в таблице хранились с индексом сервера, т.е. после переноса всех файлов, запустил rsync*, чтобы постоянно стартовал и копировал и когда убедился что файлы на новом месте, то сделал update поля с индексом сервера, потом дожлася когда закончаться все загрузки со старого сервера и почистил хранилище.
* rsync напрямую работал медленее, чем если примонтировать хранилище через sshfs (самый быстрый вариант оказался от 23 МБайта/с и больше) + rsync, копировал не все сразу, а отдельно файлы до 100мб и отдельно больше 100мб, иначе копирование иногда затыкалось по непонятной причине или просто очень медленно шло.
любопытства ради спрошу, а несколько вместительных hdd + самолет не рассматривали? затем догнать изменения по сети уже и переключить балансеры (или что у вас направляет юзера на фотосервер), и сеть бы не нагружалась лишний раз
как же у вас все хорошо и одновременно очень плохо
А у нас очереди постоянных копирований (не разово, а день за днем, за годом год) мигрируют как раз на Redis с транзакционностью через встроенный lua.
Percona не очень себя хорошо повела на очередях из сотен тысяч файлов, когда источников и получателей (машин) сотни.
Percona не очень себя хорошо повела на очередях из сотен тысяч файлов, когда источников и получателей (машин) сотни.
Sign up to leave a comment.
Миграция фотографий или ещё одна очередь на MySQL