Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Это бага squeez видимо, в lenny интерфейсы вроде как дефолтно выставлялись в auto (хотя я обычно ручками копирую заготовку для /etc/network/interfaces времен sarge). То есть дефолтную настройку для интерфейса поменяли, а rc скрипт забыли поправить.
потестил
на ненагруженном тест стенде pconnect выигрывает на 100к INSERT'ах в среднем 0.8-1.1 секунды относительно connect.
Использование mysqli->prepare, bind_param, execute (в цикле только execute, понятно) — дает еще экономиии 1.0-1.8 секунды
Вот почему у меня они не глючат то?
Никакой винды, БД уже лет 10 как на отдельных серверах, так что речи о unix sockets вообще не идет.
В принципе я говорил не совсем о high load в истинном понимании. Просто сталкивался с задачей по быстрому впихиванию в бд простых и мелких данных, генерящихся «на лету» типа логов. Выигрыш от использования «пконнекта» был заметен, а использование mysqli->prepare, bind_param, execute добавило еще скорости вставки в разы.
В ступор может и не вгоняет — но к чему верстальщику php-логика с лишними для него тегами в шаблоне? Визуальный мусор, который можно править только в текстовом редакторе. А часто приходится гнать наблоны из готовой верстки чуть ли не прямо из DW. В идеале он должен выдать чистый html с названиями переменных на нужных местах. Не касаясь холиваров по поводу шаблонизаторов — с точки зрения верстальщика такой удобный способ был реализован в пресловутом и далеко не идеальном vBulletin (особенно в старых версиях до 3.x)
на большом количестве запросов в секунду (к бд конечно же) — пконнект выгоднее, ибо tcp коннект (а ведь там происходит много всего включая аутентификацию) может быть медленнее, чем простой запрос и быстрый ответ. попробуйте простые «прекомпиленные» запросы через mysqli (ну или Perl DBD) использовать — на большых rps особенно заметно
У меня так то есть GPS антенна встроенная (подключена я японской родной балалайке), и ест ьнавигатор автомобильный, но хочется что-то 7", на дроиде хотя бы 2.2, с тачем, 3g, gps и музыкой. И быстросъемное. И не дороже 10к
Моим первым был Palm Vx, хоть и на аккумуляторе, но зато с железным корпусов обсолютно неубиваемый девайсик, еще в комплекте была складная клавиатура для него. Брался аж за 1500 рублей (это уже когда вышли Tungsten T). Потом был Tungsten T|3 — впрочем он до сих пор жив, дома пользую в качестве часов настольных
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
Я никогда не буду делать /etc/init.d/networking на удаленном сервере.
картинта с Бартом у доски (с)
на ненагруженном тест стенде pconnect выигрывает на 100к INSERT'ах в среднем 0.8-1.1 секунды относительно connect.
Использование mysqli->prepare, bind_param, execute (в цикле только execute, понятно) — дает еще экономиии 1.0-1.8 секунды
Никакой винды, БД уже лет 10 как на отдельных серверах, так что речи о unix sockets вообще не идет.
В принципе я говорил не совсем о high load в истинном понимании. Просто сталкивался с задачей по быстрому впихиванию в бд простых и мелких данных, генерящихся «на лету» типа логов. Выигрыш от использования «пконнекта» был заметен, а использование mysqli->prepare, bind_param, execute добавило еще скорости вставки в разы.
P.S. пойду сделаю тестик :-)
Решил потестить насколько preg vs ereg в числах.
Получилось следующее (проводилось 100к иттераций в цикле).
Искалась строка в 3 статичных символа.
К примеру, большая строка (18200 байт), искаемого в ней нет:
preg 4.599s
ereg 6.959s
Такая же большая строка, искаемое есть в начале строки:
preg 0m5.045s
ereg 2m22.052s — тут конечнослив по полной.
Такая же большая строка, искаемое есть в конце строки:
preg 0m6.612s
ereg 3m10.676s — снова слив, вполне ожидаемый.
Урезаем строку до 64 байт. Искомое отсутствует:
preg 0m0.113s — 0m0.121s
ereg 0m0.123s — 0m0.123s
Видим не такой уж большой разрыв.
Снова строка 64 байт. Искомое присутствет в начале строки:
preg 0m0.131s — 0m0.140s
ereg 0m0.179s — 0m0.183s
Снова строка 64 байт. Искомое присутствет в конце строки:
preg 0m0.203s — 0m0.218s
ereg 0m0.494s — 0m0.503s
Регексп с патерном в 11 символов (в центре) по строке в 64 символа
preg 0m0.143s — 0m0.146s
ereg 0m0.647s — 0m0.664s