Я в Талинне всего 2 дня, теперь вижу программу докладов и думаю а когда же посмотреть собственно город?
Приезжаю вечером до того, скорее всего как всегда ночью погуляю :)
Я надеюсь там не в 22 все закрывается как иногда бывает?
да, база будет одна а апачи в режиме кипэлайв могут быстро обрабатывать запросы и отправлять клиенту редиректы. Трафф минимальный.
10 в секунду могут уже вызывать проблемы. Я считаю что чем меньше запросов тем лучше и быстрее. Одни только операции чтения разных файлов (таблиц) с диска
будет дублирование всей технической информации о файле, это нельзя.
на этом уже остановились как на факте.
Сервер будет заниматься только тем что по запросу пользователя писать статистику и отдавать ему header(Location: .....) потому там будет десяток апачей с Keep-Alive. А сами сервера с контентом на которые редирект - nginx'ы.
понятия не имею о чем Вы, пошел курить мануалы. Но добавлений там не так много, можно и 2 запроса.
Меня больше волнует 2 запроса при чтении или 3й вариант с 1 запросом + explode + random(0,count($array))
Когда-то мейнстримом было парсить выдачу, потом пошла мода на Яндекс XML.
Завтра Яндекс XML закрывают (по крайней мере для простых смертных) так что парсинг выдачи через прокси станет снова актуальным. Вот они и подготовились, капчу усложнили...
Сейчас нагрузка вдвое выше той что клала сервер, визуально тормоза не заметны. Всем спасибо.
Есть еще медленные запросы но их за 3 дня набралось 25.
Очень у многих auth, authprov и proto одинаковые.
В результате если строка найдена:
# Query_time: 15.097846 Lock_time: 0.000041 Rows_sent: 1 Rows_examined: 15218
если не найдена идет проход по всей таблице
# Query_time: 19.431725 Lock_time: 0.000058 Rows_sent: 0 Rows_examined: 736856
и то и то записано в slow query log (хотя странно, там количество строк в 50 раз больше, но время больше только в 1.3 раза)
Делать индекс по name (VARCHAR) не думаю что есть смысл. Или есть? Говорят что индексы по строкам тормозят.
Ах.. мистика. С 4.9 сек до 0.0005. Поставил индекс на auth+authprov+proto т.к. это вместе характеризует сборку клиента игры.
Хотя вообще я тут чего-то не понимаю.
Всегда индекс использовал id auto_increment для однозначного определения строки и ее редактирования/удаления в CMS и только раз надо было из одинаковых таблиц на нескольких источниках свести данные в одну - ставил unique на id (auto_increment)+id источника чтобы не путались. Больше с индексами работать не приходилось и все сорцы которые ковырял - нигде не видел больше 1 индекса...
Завтра в пике посмотрю на результат и отпишу. Всем спасибо.
Индекс id который основной. Структура
Country и city думал индексами на другую таблицу сделать но потом понял что join дольше работает чем хранить лишние байты
Есть медленные. В таблице под 700тыс записей, когда-то было больше но из за вылета винта стата за последние 2 месяца не сохранилась - так что записей реально меньше чем было. Никогда тормозов не было.
Но мне нужна именно выборка по критериям потому как можно сократить количество этих запросов идей нет.
Теперь я вообще ничего не понимаю. Была свободная память, апачи не размножались, база тормозила.
Все что сделал - перевел таблицу в InnoDB перед этим его включив в конфиге. Теперь запросы SELECT стали заметно медленнее работать (это без пика нагрузки).
В результате в пике проц сожран на 100%, памяти тоже нет и апачей не 10-11 как было а больше 15. Настройки вебсервера не менял. Где эти лишние апачи были при MyISAM?
О, вчера был выходной а сейчас сразу много! Всем спасибо за идеи.
Ну и смысл? Будет nginx всеми потоками ждать пока база ответит и не принимать новые запросы.
посмотрю что можно сделать
ну нет там того что можно кешировать. Запросы в БД все разные.
Это идея хорошая, но тогда возможны сбои в стиле что следующая запись должна ссылаться на предыдущую а та еще не добавлена потому она никуда не ссылается или ссылается не на ту... Тут надо алгоритм полностью менять будет.
Первое что я сегодня сделаю. Я выбирал MyISAM потому что судя по какому-то мануалу или статье он был более оптимален для моих задач. Проверю так ли это. Joinов там нет, основная работа с одной таблицей.
