Нагрузка была небольшая: при нагрузке на WEB сервер на 50-100 одновременных тестирующих потоках был возврат 35% ошибок (MySQL server has gone away).
после некоторого архитектурного улучшения (рефакторингом это не назовешь, его нужно еще проводить следующим шагом)
сейчас 320-350 rps, Все работает стабильно и MySQL уже точно не падает.
> у вас вся обработка происходит в череде if-else и switch-case в одной(грубо говоря) процедуре?
да, есть switch в котором есть вызывается соответствующий метод (action)
Каждый метод делает некоторые действия. Как правило, инстанцирует свой класс модели и вызывает её определенный метод. Результат выполнения присваивается переменной $result, из которой формируетя ответ.
преимущество использование демонов:
— инициализация справочниками проходит один раз, во время загрузки
— соединение с БД, кешами и прочими сервисами проходит один раз
возможны проблемы масштабирования, но они просто решаются, да и нагрузок пока таких, чтоб требовалось масштабирование демона — не возникало.
В данном проекте нет, так как там моего кода — кот наплакал, рефакторинг еще предстоит
но в предыдущем проекте архитектура системы была следующая:
— клиент стучится по сокетному соединению, если оно не проходит, то тогда стучится по HTTP
— сервер запущен как демон, которые принимает сокетные соединения
— все HTTP запросы прокидываются через nginx на демон скрипта
— протокол обмена бинарный
статистика показывала, что из 1000 одновременных подключений, где-то только 30-65 идут по HTTP
преимущество бинарного протокола:
— компактность
— защищенность, хотя это сомнительно, но через протокол ни кто не влез, а флеш взламывали
Очевидно у нас разные взгляды на архитектуру и понятия… Это не типовой WEB проект, точка входа одна, парсинга урла нет, один контролер который работает с моделями…
да, еще вспомнил случай реализации одного проекта. Взял свой фреймворк, для реализации социгры, далее решили прикрутить PHP-AMF, прикрутили, оказалось 75% функфиональности в корзину… потом отказались от AMF и заменили на протобуф, ну и вообще 90 процентов кода в никуда…
так что решаем спец задачи
У Вас вроде всё верно — написали на реляционной базе — работает, деньги приносит. А потом, уже когда код работал, дали оптимизировать.
писал код не я, довел до прибыли не я, так что это лавры хозяина проекта…
моя задача — чтобы все это взлетело, когда стало тормозить… и мои изменения были минимальны, просто другой программист стал делать рефакторинг под моим руководством
Меня интересовала производительность самого хранилища, по этому делалось 10К рандомных запросов (GET/SET) по num PK ключу в n потоков( каждый поток 10K / n ) сишными клиентами, писался специальныйтестировочный софт. Что бы по минимуму исклюить сетевое взаимодействие, то все происходило в одном коннекте. Ели на каждый запрос делать свой коннект, то общее время увеличится на 20-30%.
Все тестирование происходило на локалхосте, что не совсем правильно.
Пример тулзы для memcached протокола github.com/akalend/mcstrass
аналогичные тулзы писались и для redis, для HandlerSocket и для mongo…
конечно все зависит от локального железа и настроек, но по моим тестам редис был быстрее чем mysql+hs
тут вообще еще очень многое зависит от методике измерения:
— в одном ли коннекте на поток, или на каждый запрос новый коннект,
— во сколько потоков шли запросы
— делали инсерты или уже изменяли зааллоцированные области.
— первоночальный размер карзины хештейбла или таблицы
— Каким клиентом мерили. Желательно, чтоб это был родной сишный клиент.
Леша, согласен с тобой — полностью.
У каждого программиста, проработавшее определенное кол-во времени над определенным кругом задач появляется свой наработанный инструментарий в широком смысле этого слова, который принципиально можно назвать фреймворком. У меня есть собственный фреймворк, который я использую в большинстве задач. По этому, в тексте статьи и было написано, что это вечно флеймовый вопрос…: Быть или не Быть?
Конечно, было быпросто замечательно, если бы группа интузиастов выпустила фреймворк, заточеный специально под соцсети, нагрузку и бинарным обменом с флешью, а не адаптировало бы ZF или симфони
Расскажите, как мерили разницу по скорости Тарантул/МонгоДБ и каков порядок у «значительно»?
мерил Си клиентом, засылал 100 000 запросов на несколько потоков (от 8- 16)
значительно, это на 30-40%
Запускать такую бд на виртуалке с 1Г памяти это все-равно, что на телефоне.
Это верно, и пытались это вразумить инвестору, что нужен выделенный сервер…
Монга по умолчанию при старте большие файлики создает, но это как бы не проблема,
да там вообще облако, так что настройка монги — это вообще проблема хостера.
>$this->execSQL( «SELECT * FRAO users WHERE uid=$uid»); // Тут SQL Injection
принципиально ты прав, и молодец что заменил… Думаю, другие это оценят.
про псевдокод — мой коммент выше, а что касается $uid — то проверка на SQL Injection осуществлена еще в контроллере, а не в модели.
в данном случае это было приведение к инту и проверка на ноль. Ну и скажи — какой смысл пускать ноль в модель если можно дать отлуп на более высоком уровне?
И кто тебе сказал, что клиент и сервер общаются по HTTP? Может клиент и сервер общаются по AMF, protobuf или иному бинарному протоколу?
кстати, если вы разрабатываете социальные игры — то советую присмотреться к протобуфу
потому-что везде в статье псевдокод, для наглядного понимания, реального кода реально больше (больше проверок, больше методов, больше диапозон выбора данных)
ну а если по логике, то на UPDATE_SPIN_COUNT (=1) формируем один запрос, а на UPDATE_USER_BALANCE (=2) выполняем другой,
а судя вашей логике, на 1 и 2 я выполняю один и тот же запрос
но в данном проекте это совсем не катит, пока что реализовано на switch
после некоторого архитектурного улучшения (рефакторингом это не назовешь, его нужно еще проводить следующим шагом)
сейчас 320-350 rps, Все работает стабильно и MySQL уже точно не падает.
обосрасть всегда легче, чем написать хорошую статью
да, есть switch в котором есть вызывается соответствующий метод (action)
Каждый метод делает некоторые действия. Как правило, инстанцирует свой класс модели и вызывает её определенный метод. Результат выполнения присваивается переменной $result, из которой формируетя ответ.
— инициализация справочниками проходит один раз, во время загрузки
— соединение с БД, кешами и прочими сервисами проходит один раз
возможны проблемы масштабирования, но они просто решаются, да и нагрузок пока таких, чтоб требовалось масштабирование демона — не возникало.
но в предыдущем проекте архитектура системы была следующая:
— клиент стучится по сокетному соединению, если оно не проходит, то тогда стучится по HTTP
— сервер запущен как демон, которые принимает сокетные соединения
— все HTTP запросы прокидываются через nginx на демон скрипта
— протокол обмена бинарный
статистика показывала, что из 1000 одновременных подключений, где-то только 30-65 идут по HTTP
преимущество бинарного протокола:
— компактность
— защищенность, хотя это сомнительно, но через протокол ни кто не влез, а флеш взламывали
преимущество сокетного соединения — скорость
так что решаем спец задачи
писал код не я, довел до прибыли не я, так что это лавры хозяина проекта…
моя задача — чтобы все это взлетело, когда стало тормозить… и мои изменения были минимальны, просто другой программист стал делать рефакторинг под моим руководством
Все тестирование происходило на локалхосте, что не совсем правильно.
Пример тулзы для memcached протокола github.com/akalend/mcstrass
аналогичные тулзы писались и для redis, для HandlerSocket и для mongo…
тут вообще еще очень многое зависит от методике измерения:
— в одном ли коннекте на поток, или на каждый запрос новый коннект,
— во сколько потоков шли запросы
— делали инсерты или уже изменяли зааллоцированные области.
— первоночальный размер карзины хештейбла или таблицы
— Каким клиентом мерили. Желательно, чтоб это был родной сишный клиент.
Но в целом корреляция существует…
У каждого программиста, проработавшее определенное кол-во времени над определенным кругом задач появляется свой наработанный инструментарий в широком смысле этого слова, который принципиально можно назвать фреймворком. У меня есть собственный фреймворк, который я использую в большинстве задач. По этому, в тексте статьи и было написано, что это вечно флеймовый вопрос…: Быть или не Быть?
Конечно, было быпросто замечательно, если бы группа интузиастов выпустила фреймворк, заточеный специально под соцсети, нагрузку и бинарным обменом с флешью, а не адаптировало бы ZF или симфони
мерил Си клиентом, засылал 100 000 запросов на несколько потоков (от 8- 16)
значительно, это на 30-40%
Запускать такую бд на виртуалке с 1Г памяти это все-равно, что на телефоне.
Это верно, и пытались это вразумить инвестору, что нужен выделенный сервер…
Монга по умолчанию при старте большие файлики создает, но это как бы не проблема,
да там вообще облако, так что настройка монги — это вообще проблема хостера.
сейчас магик моменто исправлю
принципиально ты прав, и молодец что заменил… Думаю, другие это оценят.
про псевдокод — мой коммент выше, а что касается $uid — то проверка на SQL Injection осуществлена еще в контроллере, а не в модели.
в данном случае это было приведение к инту и проверка на ноль. Ну и скажи — какой смысл пускать ноль в модель если можно дать отлуп на более высоком уровне?
И кто тебе сказал, что клиент и сервер общаются по HTTP? Может клиент и сервер общаются по AMF, protobuf или иному бинарному протоколу?
кстати, если вы разрабатываете социальные игры — то советую присмотреться к протобуфу
ну а если по логике, то на UPDATE_SPIN_COUNT (=1) формируем один запрос, а на UPDATE_USER_BALANCE (=2) выполняем другой,
а судя вашей логике, на 1 и 2 я выполняю один и тот же запрос