видимо не сюда т.к. есть index.php? и вообще после добавления этой строки сервер ругается при перезапуске, а так этой опции в конфиге не было
lighty-enable-mod: command not found
No package lighty-enable-mod available
к тому же в конфиге fastcgi-php раскомментирован...
допустим нужно было иначе активировать, сделал как по ссылке
в результате сервер вроде как запустился (в консоле [ОК]) но на порту ничего нет. в логах появилась
"Дождь", - ответил Штирлиц и забарабанил пальцами по стеклу.
Я в Таллине. Заселился в какой-то хостел, после 2 чашек шарового кофе в Люкс Экспресс страдаю фигней. Кто завтра утром до начала гуляет по центру?
P.S. Местные, где тут недорогое пиво? Мне Риги по ценам между Франкфуртом и Кёльном хватило :)
Я в Талинне всего 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 месяца не сохранилась - так что записей реально меньше чем было. Никогда тормозов не было.
Но мне нужна именно выборка по критериям потому как можно сократить количество этих запросов идей нет.
