Ответы пользователя по тегу PHP
  • MongoDB для дейтинг сайта

    Wott
    @Wott
    Воспринимайте монгу как кеширование или ускоритель, то есть найдите то что тормозит, является бутылочным горлышком и переделайте с монго. Понятно что на вскидку можно что-то предложить, но правильнее будет залить тестовые данные и подергать, а то и бету запустить. В общем в оптимизации рулят обьективные данные а не мнения «на вскидку»
    Ответ написан
    Комментировать
  • Быстрый lamp сервер под windows

    Wott
    @Wott
    Любая сборка. если оптимизируется, то под конфигурацию, которую имел в виду ее автор. Наверняка она отличается от вашей машины.
    На серверах хостингов, как правило. настройка более адекватна.

    Если нужна скорость, то разберитесь в настройках — это не сложно.
    Ответ написан
    Комментировать
  • Как заставить preg_match_all возвращать действительно все вхождения?

    Wott
    @Wott
    попробуйте позитивный просмотр вперед сразу после первой цифры
    Ответ написан
    Комментировать
  • Готовы ли вы участвовать в проектах бесплатно?

    Wott
    @Wott
    Вот на такой общий вопрос сразу ответил — нет.
    но потом вспомнил что я дофига что делал бесплатно и open source и не очень ровно по той же причине — было время и было интересно, а деньги меня либо не интересовали в таком обьеме либо я видел что у людей проблемы с ними, а все равно интересно :)
    Ответ написан
    Комментировать
  • Основные мероприятия по переводу на HighLoad?

    Wott
    @Wott
    HL это на самом деле задача по оптимизации. В первую очередь надо уменьшить времена формирования ответа, времена загрузки на клиенте, что достигается оптимизацией самого приложения (профилирование, склеивания запросов и разнесения контента) и и потом уже кеширования, которое бывает разное — тупое (ставим nginx ) или структурное ( разбиваем на блоки, которые формируем и кладем например в memcached ), управляемое ( содержимое меняется при необходимости ) и нет ( по таймауту ). Для кеширования может понадобиться изменять приложение ( обновления в данных ) или адаптировать кеширование ( сброс кеша или его игнорирование по кукам например )
    Дальше, если сервер уже не справляется в одиночку или надо HA, переходим к горизонтальному масштабированию. И начинать надо с того что запросы должны быть атомарными — любые состояния, типа сессий, усложнят масштабирование ( придется расшаривать сессии на кластер или привязывать пользователя к серверу по ip например, что легко если шардинг, но HA страдает ). Какая база ( SQL или NoSQL. не говоря уже об названии ) или кластер — зависит в первую очередь от приложения, а не от моды или комментов на хабре. Лучше жить на MySQL, тем более что Percona+Galera очень даже неплохи, если вы его хорошо знаете, чем окунаться в проблемы незнакомого сервера на production. Опять же конкретная технология должна решать конкретные проблемы, которые определяются, исходя из архитектуры приложения в первую очередь. Ну и пробовать, экспериментировать.
    Ответ написан
    8 комментариев
  • php_curl_multi: Пара вопросов

    Wott
    @Wott
    Есть хорошая обертка — MultiCurl от Vadym Timofeyev <tvad@mail333.com>
    Ответ написан
    Комментировать
  • Bug или Feature Autocomplete на сайте?

    Wott
    @Wott
    Это зависит от. Например сейчас у нас UI для asteriska для своих и там % и _ вовсю пользуются, а вот для публичного сервиса лучше не стоит, иначе непонятной квалификации пользователь получит непонятную для него ситуацию если вдруг тот же % всплывет в данных.
    Ответ написан
    Комментировать
  • Написание документации по API

    Wott
    @Wott
    По опыту с другой стороны вся эта документация по классам не особенно и нужна — если надо, всегда можно в исходниках глянуть что к чему, но зачастую, для подстановки в IDE, декларации более чем достаточно.
    Нужнее другая информация — зависимости вызовов через параметры, use cases, в крайнем случае примеры. Как правило это пара страничек текста, если без воды, но очень ценных страничек.

    По опыту — делайте в wiki. Единственно что *doc надо скриптом в вики разметку перекидать, но потом с созданием ссылок и сопровождением проблем нет. Полностью готового не видел — все так или иначе либо тупо накидывают результаты выдачи php|javadoc, либо рисуют сами
    Ответ написан
    1 комментарий
  • Система сбора статистики с учетом динамических IP?

    Wott
    @Wott
    Клиент всегда может зачистить все данные, а браузеры ему в этом помогают, поэтому при динамическом IP надежных вариантов нет.
    Но можно покапать в сторону flesh
    Ответ написан
    Комментировать
  • Как защитить сайт от SQL-инъекций? Атакуют, заливают шеллы и всякую гадость. Нужен сканер

    Wott
    @Wott
    Открываем редактор и ищем $_REQUEST или $_GET или $_POST — где нашли там и уязвимость
    Ответ написан
    Комментировать
  • Как реализовать хранение друзей в БД?

    Wott
    @Wott
    теоретически вам надо два множества — друзья юзера, и обратное — те кто позвал в друзья вашего юзера.
    1. select f1.friend from friends f1 where f1.user=:user_id
    2. select f1.user from friends f1 where f1.friend=:user_id
    

    пересечение будет давать взаимных френдов, вычитания — невзимных с одной и с другой стороны.
    синтаксис SQL говорит что это легко можно сделать полным join, который обычно не имплементируется но эмулируется обьединением left и right. То бишь:
    select * from friends f1 LEFT join friends f2 on f1.user=f2.friend and f2.user=f1.friend where f1.user=:user_id
    UNION
    select * from friends f1 RIGHT join friends f2 on f1.user=f2.friend and f2.user=f1.friend where f2.friend=:user_id
    

    и будет 3 варианта — обе f1 и f2 не null — взаимные друзья или один из них null

    Но это не самый эффективный способ, я бы согласился с serso и посоветовал иметь доп колонку с типом ( заодно можно их иметь несколько — друзья, супруги/любовники, коллеги ) и при добавлении проверять обратное отношение и сразу заполнять колонку. На нагруженной системе это можно делать в отложенном режиме.



    Ответ написан
    Комментировать
  • Необъяснимое линейное увеличение времени SELECT к базе MySQL при одинаковых запросах в цикле?

    Wott
    @Wott
    Вы неэффективно используете базу. Каждый раз вы делаете запрос мимо кэша да еще через кучу прокладок. Если для кэша установлено достаточно большое значение то он будет расти, пока не упрется в лимит.

    По хорошему запрос должен быть один — «взять всех пользователей вместе с именем».
    Хотя мне сложно представить зачем вдруг вам понадобились сразу все пользователи.

    Надеюсь с индексами в базе все нормально.
    Ответ написан
    3 комментария
  • Имеет ли смысл писать свою обертку над PDO?

    Wott
    @Wott
    на этом уровне это исключительно школьная задача и практической ценности у нее нет — стоит только копнуть чуть глубже простого селекта и выясняется что движки сильно отличаются и банальное id последней вставки может вызвать головную боль при портировании.

    абстрагироваться надо выше — на уровне обьектов и операций работы с ними. собственно оптимизация делается уже под движек и может вызвать изменения на уровне порядка, вида запросов или отдельных операций. Тут обойтись оберткой над вызовами к базе не обойтись.

    А вообще задачи доступа к разным движкам достаточно характерны для интеграции ( срастить документы в разных системах оборота, сопрячь VCS, треккер, тест менеджер и системы бизнес процессов ), для разного рода разделения по уровням ( sq-nosql, внешняя и локальная, серверная и клиентская )
    Ответ написан
    Комментировать
  • Как запускать скрипт на PHP ежедневно?

    Wott
    @Wott
    Про крон тут написали уже
    А еще WP умеет сам запускать внутренние задания по расписанию — раз в час, раз или два раза в день.
    Ответ написан
  • Что использовать при кешировании запросов MySQL в PHP

    Wott
    @Wott
    Надо думать о корректной схеме кеширования.
    У вас не меняются данные, но вы хотите заново строить ответ сервера со старым данными? может лучше кешировать сам запрос?

    Далее надо думать сколько живет кеш и как его инвалидировать. Есть простые схемы типа короткого внешнего кеша ( например nginx ), которые разгружают движек и базу. Есть более сложные — движек сам создает файловый кеш и удалает/пересоздает его по изменению контента ( самый простой — скидывать результаты запросов в файлы, которые лежат в соответвии с запрошенным урлом и сделать правила для apache, которые будут отдавать файлы вместо запуска движка, если они есть. )

    Использовать еще базу типа memcached для кеширования запросов в безу или даже в движек — это явный фейл архитектуры :) Только с целью кеширования лучше отдать память в кеш io. Разумное использование начинается с хранения отдельных данных, типа сессий пользователя, которые подмешиваются в закешированную страницу включениями — типа разделение долгоживущих данных и короткоживущие сессии.
    Ответ написан
    1 комментарий
  • Использование инлайн JavaScript во view

    Wott
    @Wott
    По моему вы путаете мягкое с теплым
    Хорошо когда код, относящийся к одной функциональности находиться рядом. И наоборот логически разные куски кода разделены. Поэтому бизнес логику надо отделять от представления. Но и поэтому же код который отвечает за представление хорошо бы не разделять.

    Лично я небольшие вставки делаю прямо в коде. Особенно если это всякие плагины :) Небольшим вставкам в большом файле плохо — они теряются на фоне других и их зачастую труднее поддерживать.

    Еще одно преимущество в том что код сразу доступен и нет определенных проблем с дозагрузкой файла. Правда это больше относиться к стилям, ну да ладно.

    Единственно когда стоит выносить JS вставки в отдельный файл, так это когда несколько кусков взаимодействуют друг с другом.
    Ответ написан
    1 комментарий
  • Ещё раз про асинхронный вызов фунции на php?

    Wott
    @Wott
    В общем случае вам надо запустить эту функцию в отдельном процессе/нити, только тогда она будет выполнятся независимо ( с обычными оговорками, но все же )
    Как именно это делать — это вопрос. Выше предлагают держать отдельные процессы, которые подхватят задание из очереди. Есть еще стандартный расширение pcntl, которое реализует стандартный unix механизм fork для создания дочернего процесса, но он не работает на виндах, например, в силу того что там это организовано по-другому.
    Дополнительно есть особенности с работой php в веб-сервере с set_time_limit().

    Когда мне надо было сделать какие-то долгие задачи, я делал фактически демон в bg и работал с ним через разные интерфейсы — то очередь через базу, то REST, что прикольней.
    Ответ написан
    Комментировать
  • Какой вариант логики запросов правилен?

    Wott
    @Wott
    правильно, с точки зрения нормализации вариант №1, когда нет дублирующей и зависимой информации. Если это не критичное для производительности место, то лучше не создавать лишних сущностей.

    Но если запрос такого рода часто используется или выполняется медленно, то стоит ввести дополнительное поле. Имхо лучше делать триггер на изменения в таблице с комментариями и в нем апдейтить поле в таблице с постами, сделать для него дефолт в 0 и вообще забыть о его модификации в приложении.
    Ответ написан
    Комментировать
  • Дайте советов по поводу переноса блога

    Wott
    @Wott
    По-моему опыту дешёвый хостинг ничем не отличается от бесплатного — разве что бесплатный хостинг может однажды просто перестать работать, но дешёвый может просто потерять данные — так что оба приходиться регулярно бекапить с оглядкой на полное восстановление. Отличия проявляются где-то после 5$/месяц.

    Советую регистрировать имя отдельно — хостинги меняются просто, если не надо переносить домен, а дешёвый хостинг менять скорее всего придется. Доменное имя на год можно зарегистрировать в районе 1$ по скидке — надо просто прошвырнуться по регистраторам и пошукать текущие скидки.
    Ответ написан