Чего следует избегать в php / mysql / ajax при использовании тяжелых операций чтения / записи - PullRequest
2 голосов
/ 27 ноября 2009

Мне было интересно, что нужно было избегать при создании веб-приложения, основанного на интенсивном чтении и записи каждую секунду.

Подумайте об онлайн-играх, в которые вовлечены деньги.

Например, у вас есть javascript, который постоянно обновляет браузер (1), есть cronjob, который обновляет db (2), есть пользовательский ввод, отправленный через ajax или POST (3), и у вас есть несколько пользователей, выполняющих все эти действия каждую секунду (4).

Сюда также входят деньги, поэтому все данные должны быть прочитаны и записаны правильно (5). И в случае сбоев эти данные должны быть восстановлены правильно, поэтому резервные копии (6) важны.

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

Хотелось бы узнать ваше мнение по этому поводу, спасибо!

Ответы [ 4 ]

1 голос
/ 27 ноября 2009

Кэш: используйте Memcached и попытайтесь поразить базу данных как можно меньше.

Используйте быстрый веб-сервер или веб-сервисы, разные серверы или скрипты, работающие на разных портах, для выполнения разных задач без особых проблем.

0 голосов
/ 27 ноября 2009

Это очень мало для чтения и записи. Вы (надеюсь) присоединяетесь только к двум или трем столам.

Кроме того, вы можете делать все для самой игры в памяти, просто сохраняя все в пользовательском сеансе или глобальном кэше. Затем вы захотите записывать финансовые данные в базу данных каждый раз, когда они меняются, но обновление банкролла для одного игрока должно быть одним или двумя столами, топы. Возможно, вам также понадобится таблица регистрации / транзакций, чтобы увидеть, в какое время какая сумма была переведена на чей-либо счет.

В любом случае, я бы не сильно беспокоился о производительности при коротких запросах; базы данных на удивление хороши в этом.

0 голосов
/ 27 ноября 2009

Если пропускная способность является проблемой, рассмотрите возможность распаковки выходных данных в браузеры. Или, если питание ЦП является проблемой, и gzip включен, отключите его, но рискуете увеличить использование полосы пропускания.

Установите ваши статические файлы, такие как CSS, изображения, Javascript и т. Д., Чтобы они кэшировались в браузере, а срок их действия истекает через долгое время. Это означает, что повторные пользователи не будут использовать вашу пропускную способность и т. Д. Для запроса той же версии файла, который у них уже есть.

Запуск эталонных тестов по используемым вами запросам. Оптимизируйте, где это возможно. Возможно, разделение длинных запросов на более мелкие может повысить производительность. Используйте профилировщик, такой как xdebug, чтобы определить узкие места.

Использование постоянных sql-соединений для экономии ресурсов при новых соединениях при каждой загрузке.

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

Следующая вещь ... действительно ли ajax необходим в вашем приложении? Будет ли это работать без него? Не добавляйте лишний раздуватель на свой сайт с дополнительными запросами в ajax.

Я не могу написать больше, так как не знаю особенностей вашего сайта / приложения.

0 голосов
/ 27 ноября 2009

Я не уверен, отвечаю ли я на этот вопрос «чего следует избегать», а скорее «о чем думать» ...

  • Посмотрите на кэширование - кэширование кода операции для страниц php и кэширование памяти (APC, memcache) для справочных данных и других «статических» (или близких к статическим данным).
  • Изучите проблемы параллелизма - убедитесь, что вы рассмотрели случаи, когда два человека обновляются в одно и то же время, и способы их возврата.
  • Просмотр MySQL репликации .
  • Старайтесь избегать слишком много AJAX. Иногда мы увлекаемся количеством обновления данных на экране, потому что ajax очень прост. то есть иногда вы можете немного изменить бизнес-логику / требования (если это возможно), чтобы сделать технические аспекты намного проще.
  • Иметь хорошие варианты использования со сложной системой, подобной этой, и часто тестировать.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...