Меню
Что нового?

Быстродействие и разгрузка сервера, базы.

Opik

Новичок
Быстродействие и разгрузка сервера, базы.

Есть очень загруженный сервер. Пытаемся разгрузить, львинная доля нагрузки идет от базы. Проект - онлайн игра.
В ней есть бои :), соотвественно перед боями - заявки.
Как лучше их организовать?
Варианты:
1)
Подаем заявку - данные идет в memcache(далее кеш)
кто то принимает заявку - данные в кеш.
ну и так далее работа с кешем и уже когда данные идут на долгосрочное хранение - из кеша в базу.
(Вроде всё ок, но по словам Тони - не факт, что данные уйдут в кеш, а если уйдут, что не факт, что останутся.)
2) Все действия - пишем в базу, запросы кешируем. Тут всё понятно кроме одного - как и что именно кешировать. т.к при подаче заявки - нужно что бы она отображалась сразу, а не ждать, пока что то то там обновится. и так далее, а обновлять кеш при каждом дейсвии - смысла кеша нет вообще.
Есть ли альтернативные, лучшие варианты?

P.S PHP 5.0.4
 

Necromant

Новичок
1) Пишем , и в кеш и в базу
При выборе смотрим кеш , нету , смотрим базу
 

Opik

Новичок
PHP: 
      function cacheOffer($key)
      {
           global $db, $memcache;
           $query = $db->query("SELECT * FROM `offers` WHERE id = '".$this->battle_id."'");
           $result = $db->fetch_Row($query);
           $memcache->set($key, $result, false, 20);
           return $result;
      }

      function getOffer()
      {
           global $memcache;
           $key = sprintf("offer:%d", $this->battle_id);
           if(($qq = $memcache->get($key)))
           {
                return $qq;
           }
           else
           {
                return $this->cacheOffer($key);
           }
      }
1 из вариантов кеширования.
 

DeFacto

Новичок
3. заявки, как что-то временное можно вообщем в базу не сохранять... а в файлах...
 

Halk_74

Guest
ИМХО в файло сливать - лишний напряг. Только уже не на мускл гапряг будет, а уже на саму платворму. Если 1,2 или 3 юзверя активничать начнут - не вопрос. А если 100-150 или больше? У меня нечто подобное было с первой версией инет-магазина, когда задействовано было чтение файловой системы. При увеличении пользователей начинались тормоза с отработкой скрипта.
 
Falc

Falc

Новичок
Opik
Во-первых стоит помониторить базу, что именно в ней тормозит, если тормозят селекты, которые кешируются значит проблема с кешем, тут стоит написать мониторинг кеш-попаданий.
 

Opik

Новичок
Falc
Спасибо, но как это сделать ? (определить что тормозит?)
 
Falc

Falc

Новичок
Opik
Для начало стоит сказать какая СУБД используется, у разных СУБД разные средства
 
Falc

Falc

Новичок
В MYSQL можно:
Во-первых включить лог медленых запросов: http://dev.mysql.com/doc/mysql/en/slow-query-log.html
Во-вторых можно в онлайне просматривать список процессов и смотреть кто чем занимается, возможно у тебя блокирующие запросы и в результате остальные запросы ожидают их исполнения. тогда есть смысл задуматся о переходе на другой тип таблиц или вообще на другую СУБД.
 

Opik

Новичок
Falc
1) ок, включу.
правда у меня ведется собственный лог.
sec: 0.10266; query:
[sql]
SELECT * FROM equip WHERE owner = '1671'
[/sql]
owner - индекс.
в нем записаны в основном эти запросы.
2) посмотрел, ожидающих не видно.
 
Falc

Falc

Новичок
Opik
SELECT * - -это плохая практика для реальных приложений, т.к. в будуещем в таблицу может добавится большое текстовое или бинарное поле, которое сильно замедлит выборку.

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

>>правда у меня ведется собственный лог.

Если у тебя есть свой лог, то тебе стоит раставить контрольные точки по наиболее выполняемым скриптам и смотреть что именно тормозит.


И еще для мониторинга MYSQL'я неплохо использовать SHOW STATUS, из него видно как часто создаются временые таблицы на диске, насколько эфективно используются кеши, как часто происходят full join'ы и пр...
 
Falc

Falc

Новичок
Opik
>>т.е будет оптимальнее. что я перечислю все поля? нужные (все нужны )

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

Opik

Новичок
Created_tmp_files 7
Created_tmp_tables 293837
Select_full_join 3257

-~{}~ 19.09.05 18:14:

sec: 0.20955; query: UPDATE `participants` SET `takeDamage` = `takeDamage` + 2 where oid = '156127' and mid = 3213
вот ещё проблема.
тут 1 двойной индекс на oid и mid, oid первый. Вроде как операции типа: `takeDamage` = `takeDamage` + 2 должны выполнятся быстрее?
 
Falc

Falc

Новичок
>>Select_full_join 3257
Фулджоин - это плохо возможно где-то не используются индексы.

>>Created_tmp_tables 293837
Гораздо интереснее смотреть на: Created_tmp_disk_tables


Вобщем читай анализируй:
http://dev.mysql.com/doc/mysql/ru/show-status.html
 

Opik

Новичок
Фулджоин - это плохо возможно где-то не используются индексы.
Нажмите для раскрытия...
ок, ща пройдусь по "заторможенным" запросам и проверю индексы.
Гораздо интереснее смотреть на: Created_tmp_disk_tables
Нажмите для раскрытия...
Created_tmp_disk_tables 44929
Вобщем читай анализируй:
http://dev.mysql.com/doc/mysql/ru/show-status.html
Нажмите для раскрытия...
сенк, уже начал читать :)
 
Falc

Falc

Новичок
Opik
>>Вроде как операции типа: `takeDamage` = `takeDamage` + 2 должны выполнятся быстрее?

Данную оперецию блокируют Селекты к таблице participants, поэтуму она ожидает пока не завершатся все выборки, которые были запущены до выполнения UPDATE.
 
Falc

Falc

Новичок
Opik
>>Created_tmp_disk_tables 44929

И это плохо, временые таблицы не умещаютя в отведеное для них место в памяти, надо крутить:
tmp_table_size
max_heap_table_size

-~{}~ 19.09.05 19:27:

Opik
>>понял, есть варианты решения?
1. Ускорять селекты
2. Переходить на другой тип таблиц или другую СУБД
 
Войдите или зарегистрируйтесь для ответа.
Сверху