Самая здравая идея, кстати. Минус ровно один - времени на отладку многопоточного самодельного демона уйдет - вагон.
Совсем нет. И в этом его преимущество.
Ну так просто нагенерите в табличку сотню миллионов рандомных записей, и проверьте.
Я смутно представляю себе, как работает постгис, но что-то мне подсказывает, что это плевая задача - учитывая всякие openstreetmaps.org.
Вылез, стукнтитесь еще раз, если не сложно.
nginx естественно.
Координаты в виде дробных градусов? ID записи имеется?
Но вобщем, в любом случае - время выполнения - копеечное.
Ну, во-первых, у вас данные жестко структурированые, и незначительного объема - я бы на вашем месте сначала на кошках потренировался, есть неплохая вероятность, что пару-тройку млрд. строк база переварит, и не чихнет.
Во-вторых, вам действительно жизненно необходимо хранить сырые необработанные данные? Это может быть нелучшим вариантом.
Outsourcenow добавил 03.12.2009 в 19:51
Идея скрещивать веб-сервер с sql - порочна в принципе.
Но вцелом, если так уж хочется - проще дописать плагин к nginx, как, собственно, многие и делают. Только от sql в качестве хранилища надо будет отказаться совершенно точно.
Открыть файл, и нажать "Сохранить в режиме UNIX" в вашем любимом текстовом редакторе.
Из консоли-то работает?
Код: #!/bin/sh
Поди, файлик в windows открывали/сохраняли? И \n\r в конце так кривые и остались.
Первым делом нужно выкинуть апач вообще.
Вторым делом нужно корректно спроектировать прием данных - очевидно, что узким местом системы будет именно бесконтрольно плодящиеся потоки php-процессов. Сделовательно, первый шаг оптимизации - сокращение времени на прием и сохранение данных. Минимум обработки, и максимально быстрое засовывание в хранилище - причем, не обязательно БД, вполне может быть и memcachedb, в котором организована очередь.
Впрочем, 60к в минуту - это всего 1к в сек., mysql вполне сносно умеет порядка 6-8 тыс. инсертов в секунду.
Выборки по таблице в 200 млн строк при грамотно написаных индексах у меня на десктопе занимают порядка 2-3 сек.
Но если вы напрягаетесь по этому поводу - откройте для себя шардинг.
И не должны пропасть. Так и задумано.
FIN_WAIT от TIME_WAIT немножко так отличаются :-)
Кроме того, в линуксовом ip-стеке по-дефолту работает nolocaltimewait, если мне не изменяет память.
ps/2: Во фре вообще говоря есть net.inet.tcp.msl :-) А REUSE у сокетов работает во всех операционных системах, достаточно, чтобы у инициатора tcp-сессии в опциях сокета этот флаг стоял.
1. Погуглите про TIME_WAIT
2. В обычной ситуации - не надо, в данном конкретном случае - стоит озаботится.
3. Если отказаться от уродской манеры проксировать запросы на внешний адрес, и перевесить апач на 127.0.0.1 - проблема скорее всего решится.
Вы как-то совсем не хотите понять, что вам Химик пытается донести - а он совершенно прав.
Принимать решение порезать трафик на основе подсчета пакетиков-сессий - ума большого не надо. Давайте, чтобы было понятно, на конкретных примерах - с вашего сервера дергают /index.php 400 раз в секунду. Постоянно с разных ip-адресов. Корреляции между временем запроса и ip-адресом нет, распределение - строго равномерное.
За минуту это будет 24000 хитов. Известно, что из них - 200 хитов валидные, все остальные - ддос.
И - да, 200 хитов - это, скажем, транзакции платежной системы, соответственно, продолбленные 200 запросов - стоят, условно, $10к.
Ваши действия?
