Я забыл про авторизацию, это наверное самый важный компонент, кто может глянуть? Смотреть здесь: app/library/Component/Auth.php
Я сейчас не могу опознать, хихикаешь ты надо мной или нет, но суть в том, что я об этом много думал, и короче ничего путного не надумал. К сожалению у меня php в основном решает задачу "бери из БД и кидай юзеру в лицо", ну и чуток форматирования. Экспериментировал с HHVM, прирост есть. Но опять же на самом пхп-коде. Учитывая, что при профайлинге он не слишком-то большую нагрузку даёт, и его легко распределять хоть на миллион серверов (в отличии от БД), то проще взять еще пару машин и забить болт. Хотя я довёл на своём компе кажися до 1400 страниц (простейших, без бд) в секунду и забил писюн. Как я это сделал я не помню, сейчас вот из коробки и без тюхнинга 600+ выкакать может. Это с пхп. Если статика то там много больше. Т.е. если у тебя есть на пхп некий долго работающий код, то да, конечно его стоит переписать на чемнить. Может даже расширение на сях сварганить. Но я сомневаюсь, что фалкон создан для тугих расчётов. Больше похоже, что это просто банальный MVC + плюс какие-то плюшки, упрощающие написание сайтиков, авторизаций, и прочего. Т.е. выходит, что если у тебя где-то грузное, то тебе фалкон не панацея. =) Если у тебя бд тугая на чтение, то можно наверное сделать одну на запись + пяток на чтение. Читать из всех рандомно, а писать в одного писателя. И из писателя не читать, чтобы быстро было. Хз. Денормализация тоже ускоряет. Но надо чистить и контролить ручками. Добавлено спустя 2 минуты 38 секунд: 440hz по этому поводу сказал что я сосунок, и что у них в конторе школьники больше с одной машины выжимают. Отож.
ни в коем случае, ты попал в точку! насчет пыха выбрали из БД 20 тысяч позиций, надо у них символ удалить в конце один, ну что казалось бы тут проще, епеним в цикле $str = mb_substr($str, 0, -1); цикл проходим за 7-8 секунд, накуй mb_ $str = substr($str, 0, -1); получаем 0.43 )) и то много, еще на порядок быстрее посчитать перед циклом кол-во элементов массива и вставить символ в конце, нежели его удалить потом )))
не верю! один только mb_substr на 20'000 итерациях не способен создать такую задержку. должно быть порядка сотых долей секунды на весь цикл. Добавлено спустя 1 минуту 37 секунд: конечно есть еще зависимость от длины строки. длинные обрабатываются дольше… Добавлено спустя 4 минуты 17 секунд: в данном случае один MySQL UPDATE был бы оптимальным вариантом ))) сэкономили бы несколько секунд жизни.
Имхо, сама БД и должна заниматься подобными вещами. Набор тригеров, фугкций и процедур на основные важные тех.процессы и у тебя голова не болит.
что это за строки чтобы отрезать по одному символу из нескольких мегабайт? что у тебя там вообще. иди в свой топик и там всё разъясни пожалуйста.
Бывает разные случаи: ну например, база, которая уже давно используется и в процессе использования, ее нужно нормализовать.
ну надо разочек её перетрясти на новую структуру. короче я не понимаю, что за ситуация, где в базе хранится строка по несколько мегабайт, в которой нужно отрезать один символ с конца.
Думаю ты сам заметил, что контроллер слишком толстый. Я не знаком с Phalcon, потому не могу указать на конкретные шаги, но: 1. Логика слишком запутана, надо как-то избавиться от слишком вложенных if`ов 2. Попробуй вынести отдельные куски кода в методы, возможно в отдельный класс-прослойку между контроллером и моделями. Читал? http://refactoring.guru/catalog А вообще, код смотрится гораздо приятнее среднего форумного новичка )
Пока ума не хватает как-то сократить код, но уже потихоньку начинаю. А вообще там много индивидуальных случаев и писать для них свои методы нет смысла) Нет не читал, даже не слышал про такое) Может потом прочитаю. Спасибо за ссылку Я вообще уже два года PHP страдаю, я около года почти не продвигался в изучении языка, но зато насмотрелся много кода, вот почти определился со стилем)) Хотя нет, я всего 2 года сайты делаю, начинал с конструкторов)) Хочется знать больше, на форумах всего не найдешь и не узнаешь, нужно книги читать, а мне они не даются
Не всегда это бывает возможно, смотрите на мир чуть ширшее. Имел геморрой нормализации БД, где основная таблица рабочая была около 80КК записей, сопутствующих записей по справочникам и прочему еще на пару-тройку десятков млн. записей в нескольких таблицах. Останавливать и закрывать от пользователей не вариант, это живая система, кто-то успвал сделать поддержку новой структуры, кто-то нет. Жила в переходном состоянии около полутора лет, пока отстающие подтянулись и все старье вырезали. Такое бывает, и довольно часто, и не всегда бывают варианты, когда денормализация - вызывает жутчайшую боль в заднице, бывают необходимы и такие шаги на какие-то сроки. Понятно, когда ты только начинаешь или маленькая база и ты там повелитель: перебрать мигом - не вопрос, но когда база работает уже десяток-полтора лет, там километр софта чужого, так не делается. З.Ы. повторюсь: никогда не будьте категоричны, всегда есть обстоятельства, которые могут заставлять предпринимать те или иные шаги, и по феншую они или нет, дело десятое.
Ты не прав, это вопрос того, что не всегда следование "лучшим практикам" и прочим парадигмам и перфекционизму - есть хорошо, иногда стоит смирятся с существующим положением дел. Иногда наплевательское отношение к ним делает жизнь проще, а волосы шелковистее. З.Ы. не ты ли часто повторяешь, что следование ООП, ради самого ООП не есть хорошо? Существуют разные ситуации, нельзя считать случайно "перепрыгнутые" пару-тройку граблей за правило.
Не, если работает, то всё прекрасно. Но если время пришло, то ленку надо рубить хвост сразу, а не по частям. Добавлено спустя 1 минуту 46 секунд: Хотя я люблю костыли.