Ребят, подскажите, пожалуйста, как удалить найти и удалить строку в текстовом файле? К примеру, есть строка asdasd@has.ru:1234jakfsdg Как ее найти и удалить в .txt?

в вебшторме ctrl+r реплейсишь на пустую строку

Ребят, подскажите, пожалуйста, как удалить найти и удалить строку в текстовом файле? К примеру, есть строка asdasd@has.ru:1234jakfsdg Как ее найти и удалить в .txt?

.replace()

вв это ж node.js чат, сорян )

Привет. Народ, скажите какое вы считаете хорошим время для генерации html перед передачей вебсерверу? Время от поступления серверу запроса, до получения назад html для передачи обратно клиенту

Меня зовут Руслан. Занимаюсь веб разработкой. Основной проект интернет-магазин освещения. Сейчас изучаю активнее js node.js Люди говорят, что node.js это быстро.

http://cs9.pikabu.ru/post_img/2016/09/15/7/147393909915812096.jpg

50-100 мс наверно)

Группу нашел поиском @nodejs Чем могу быть полезен пока не знаю)

50-100 мс наверно)

Node.js так сможет? Php7 + smarty + lightspeed web server + mysql Для самой сложной страницы удалось добиться 150мс, переезд на node.js обдумывается именно из-за манящей скорости

Node.js так сможет? Php7 + smarty + lightspeed web server + mysql Для самой сложной страницы удалось добиться 150мс, переезд на node.js обдумывается именно из-за манящей скорости

Слишком абстрактнй код. Результат зависит от миллиона факторов

Node.js так сможет? Php7 + smarty + lightspeed web server + mysql Для самой сложной страницы удалось добиться 150мс, переезд на node.js обдумывается именно из-за манящей скорости

ну если обсуждать сферического коня в вакууме, node+jade+nginx(статика) + psql, то может

Node.js так сможет? Php7 + smarty + lightspeed web server + mysql Для самой сложной страницы удалось добиться 150мс, переезд на node.js обдумывается именно из-за манящей скорости

Смарти очень старая и тяжёлая фигня

ну если обсуждать сферического коня в вакууме, node+jade+nginx(статика) + psql, то может

Спасибо.

Node.js так сможет? Php7 + smarty + lightspeed web server + mysql Для самой сложной страницы удалось добиться 150мс, переезд на node.js обдумывается именно из-за манящей скорости

Ты так же учитывай что нода лучше всего себя покажет именно при большом количестве одновременных запросов, просто за счет архитектуры.

Смарти очень старая и тяжёлая фигня

тяжёлая в чём?

Node.js так сможет? Php7 + smarty + lightspeed web server + mysql Для самой сложной страницы удалось добиться 150мс, переезд на node.js обдумывается именно из-за манящей скорости

обычно тормозит работа с базой - тем более синхронная - готов поспотрить что чуть ли половина времени генерации из-за последовательных запросов к базе

Ты так же учитывай что нода лучше всего себя покажет именно при большом количестве одновременных запросов, просто за счет архитектуры.

Мне для моей кухни надо, чтобы основа моя работала не хуже. Т.е. Важно чтобы mysql_fetch_array , in_array, array_push, array_merge, hash(md4, '') конкатенация строк работали не хуже php. Еще у меня часто strtr используется, на php она довольно быстрая, на js не нашел аналога.

обычно тормозит работа с базой - тем более синхронная - готов поспотрить что чуть ли половина времени генерации из-за последовательных запросов к базе

Ну в моем случае узким местом стала php часть, базу заставил работать в несколько раз быстрее, так что она теперь не будет слабым местом

сколько у вас идёт запросов к базе в процессе генерации страницы?

сколько у вас идёт запросов к базе в процессе генерации страницы?

Точно не скажу с ходу. Самый сложный случай 2 на дерево категорий, 1 товары из них, 1 опции товаров, 1 значения этих опций у товаров и еще 1 сами товары плюс штук 10 счетчиков товаров. Около 20 получается.

сколько у вас идёт запросов к базе в процессе генерации страницы?

ну есть много довольно быстрых проектов где при открытии главной страницы от 100 до 500 запросов в БД делается)

это ужас но с этим живут и не чахнут

ну вот эти запросы и тормозят - вот ради эксперемента возьмите все эти данные в 1 массив и положите в memcached и будет у вас прирост в 2 раза в скорости генерации

ну есть много довольно быстрых проектов где при открытии главной страницы от 100 до 500 запросов в БД делается)

мы когда только запускали свой сервер отдачи рекламы - у меня в реалтайме было до 2-3к запросов в секунду на базу по первичному ключу и всё тоже работало

на синхронных вещах разницы в скорости меджу пыхой и нодой нету или минимальна.

Будет побыстрее конечно, но я сказал, что сейчас бд довольно шустрая, что из долгих запросов осталось кеширует в файлы, основное время занимает именно php часть.

ну вот эти запросы и тормозят - вот ради эксперемента возьмите все эти данные в 1 массив и положите в memcached и будет у вас прирост в 2 раза в скорости генерации

нода хороша именно в том что хорошо держит большое кол-во коннектов - у меня на 1 физический сервер до 10к RPS может придти и будет всё штатно работать

цветом показывает долгие вещи

красная строка со временем 38мс это еще до запросов, smarty собирается

собирается?

она же должна компилировать шаблон

1 раз

вот уже из шаблонов рожает столько времени

мы когда только запускали свой сервер отдачи рекламы - у меня в реалтайме было до 2-3к запросов в секунду на базу по первичному ключу и всё тоже работало

ну и важно еще что там в БД, потому что в ряде ситуаций запрос в БД быстрее чем в редис

ну и важно еще что там в БД, потому что в ряде ситуаций запрос в БД быстрее чем в редис

это как это?)

Как субд быстрее редиса?

можно узнать в каком это ряде ситуаций?

SELECT 1; ?

Ой

это как это?)

если вся БД помещается в память и она нормально спроектирована и запросы не написаны диверсантами то сходить в базу часто быстрее чем редис

Селект 1 все равно дольше, потому что парсинг и исполнение запроса)

но такое бывает максимум на средних проектах, выше среднего уже нет

если вся БД помещается в память и она нормально спроектирована и запросы не написаны диверсантами то сходить в базу часто быстрее чем редис

нет, я не соглашусь с вами. так не может быть - иначе бы nosql базы не выстрелили бы.

Как это? Запрос быстрее, чем получение значения по точному значению?

нет, я не соглашусь с вами. так не может быть - иначе бы nosql базы не выстрелили бы.

ну я говорю по опыту и измерениям. nosql выстрелили по другим причинам

ну я говорю по опыту и измерениям. nosql выстрелили по другим причинам

а вот моя логика говорит что не может быть такого

Как это? Запрос быстрее, чем получение значения по точному значению?

СУБД (я на самом деле про PG) пишут давно, они настолько заоптимизирвоаны и быстры что порой поражаешься

а вот моя логика говорит что не может быть такого

почему это?

потому что выстрелили nosql?

я работаю с pg memcached redis

я работаю с pg memcached redis

я же говорю, в ряде случаев, а не всегда и везде, в том числе у вас

Да потому что там много промежуточных процессов перед получением данных, а редис это дай мне то, что лежит конкретно там

я же говорю, в ряде случаев, а не всегда и везде, в том числе у вас

вот выше Богдан написал то что я хотел написать

Да потому что там много промежуточных процессов перед получением данных, а редис это дай мне то, что лежит конкретно там

каких именно промежуточных процессов?

Парсинг запроса, оптимизация запроса, исполнение запроса

Это минимум :)

в БД сначало разбираеться запрос, получаеться его хеш и смотреиться еслть ли его результат в озу если нету то идёт выполнение в редисе и мемкешеде идёт запрос сразу в участок памяти

Sql же язык не точный, а редис как раз точный

О, просмотр индексов в этапе исполнения запроса

Парсинг запроса, оптимизация запроса, исполнение запроса

давай тогда начнем с того что у постгреса протокол асинхронный а у редиса синхронный, а потом продолжим про кэш СУБД, отсутствие обращений к диску и прочее

Это сродни принеси мне это, не знаю что и дай мне конкретно это отсюда

Естественно второе быстрое, потому что конкретизируешь что

О, просмотр индексов в этапе исполнения запроса

ты правда вот думаешь что редис оптимальнее ищет по памяти чем СУБД?

Синк/асинк это для клиента

Естественно Потому что нет ничего более оптимального точного чем ключ/значение :)

Синк/асинк это для клиента

это логика протокола, ты редису можешь только последовательно слать запросы, а постгресу все сразу и по частям ловить ответы

Субд не вернет ответ пока не соберет все данные, друг :)

Естественно Потому что нет ничего более оптимального точного чем ключ/значение :)

узковато как-то смотришь. вот у меня был конкретный кейс, когда редис был на 20-30% медленнее нормально приготовленного постгреса

Субд не вернет ответ пока не соберет все данные, друг :)

она в один коннект примет все запросы и отдавать будет чанкамиа не полностью

речь про постгрес конкретно

Более чем уверен, что проблема в редисе в окружении была :)

Более чем уверен, что проблема в редисе в окружении была :)

ну мы все дураки, надо было звать умных, ага

Не фанат редиса и похожего, но факт в том что редис избавляет от кучи промежуточного что есть в пг

Раз так, то прошу прощения, что поддержал тему

Не фанат редиса и похожего, но факт в том что редис избавляет от кучи промежуточного что есть в пг

то что ты описал в постгресе стоит много только от серьезного объема, на БД до 20-30 гигов спроектированной без диверсий это может стоить меньше чем у редиса

Раз так, то прошу прощения, что поддержал тему

ну ты отчего уверен? вот мы 2 месяца исследовали измеряли, отключили редис и на 20-30% быстрее стали, что мы сделали не так?

повторяю это работает на ограниченных случаях

От понимания того как работают запросы в ключ/значение системах и субд

От понимания того как работают запросы в ключ/значение системах и субд

ну а практика показывает иные результаты порой. если копнуть вглубь то тому есть объективные причины