|
|
|
Оптимизация базы для сайта знакомств
|
|||
|---|---|---|---|
|
#18+
Есть база пользователей и поиск по ней, база: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. делалось так чтобы избежать join таблиц, при нагрузке 15000 хостов, 100 000 страниц в день система находится в вечно загруженном состоянии :( Порядок стандартных действий на сайте логин пользователем на сайт Код: plaintext 1. стандартное условие, пользователь active, пол =F, есть фото Код: plaintext Выборка пользователей происходит в два действия получение количества пользователей подпадающих под запрос Код: plaintext 1. получение списка пользователей Код: plaintext В итоге эти 3 действия обычно блокируют друг друга и растет кол-во коннектов, через n-time люди просто уходят с сайта, и все нормализуется. Вопрос как можно обойти эти пики активности ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 17:28:04 |
|
||
|
Оптимизация базы для сайта знакомств
|
|||
|---|---|---|---|
|
#18+
как я понимаю основным вариантом является разбивка таблицы на части такие как Код: plaintext 1. 2. 3. 4. 5. 6. Код: plaintext 1. 2. 3. 4. 5. все остальные поля в таблицу users . Главный вопрос в чем, 1. Разбить таблицу по полям причем каждое поле только в 1 таблице, и при желании допустим получить пол при логине join дополнительные талицы 2. Сделаем зеркальные копии нужных таблиц и затем при обновлении вставлять во все таблицы записи, получается вроде view, при этом имеем проблемы с целостностью и непротиворечивостью данных. Зато не имеем геммороя с вытаскиванием нужного поля из кучи таблиц Гуру подскажите, будьте добры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 17:42:18 |
|
||
|
Оптимизация базы для сайта знакомств
|
|||
|---|---|---|---|
|
#18+
На вскидку сделайте KEY(active, gender, photoHave) потому что по этим трем полям вы ищете. И еще вы пользуете РНР? ---------------------------------------- Артисты не приехали, приехали цыгане ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 17:48:04 |
|
||
|
Оптимизация базы для сайта знакомств
|
|||
|---|---|---|---|
|
#18+
4m@t!cНа вскидку сделайте KEY(active, gender, photoHave) потому что по этим трем полям вы ищете. И еще вы пользуете РНР? ---------------------------------------- у хостера стоит PHP 4.3.4 на машине класса P4 3Ghz 1 Gb SCSI винты, и как не странно MYSQL 3.23 на машине класса P2 600 Mhz (в разное время собиралась площадка для хостинга :) сайт активен только этот, остальные ~1000 запросов в день, индекс по полям (active, gender, photo) время выборки одной записи не превышает 0.08, вопрос в том что потом он эту запись fetch в PHP, что занимает уже гораздо дольше, в итоге в процессах, стандартный набор Код: plaintext 1. :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 17:57:47 |
|
||
|
Оптимизация базы для сайта знакомств
|
|||
|---|---|---|---|
|
#18+
>вопрос в том что потом он эту запись fetch в PHP а причем зедсь "LOCKED UPDATE USERS SENDING DATA SELECT" - я не понимаю. ---------------------------------------- Артисты не приехали, приехали цыгане ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 18:07:28 |
|
||
|
Оптимизация базы для сайта знакомств
|
|||
|---|---|---|---|
|
#18+
сорри наверное криво объясняю, смысл такой если выполнить SHOW PROCESSLIST; в mysql то видим, что большинство времени занимает Код: plaintext и накапливается большое количество Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 18:13:34 |
|
||
|
Оптимизация базы для сайта знакомств
|
|||
|---|---|---|---|
|
#18+
1. Включите логирование долгих запросов. 2. Проанализируйте их. Весьма вероятно, что будет достаточно построить соответствующие индексы, или проверить и восстановить имеющиеся. 3. Если у вас структура запросов к базе смешанная, и параллельно с селектами регулярно идут апдейты -- подумайте о переводе таблиц на движок InnoDB, он имеет построчную блокировку вместо табличной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2005, 19:23:44 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=33450185&tid=1853265]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
203ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 222ms |
| total: | 490ms |

| 0 / 0 |
