Обновить
85
0
Art Shendrik@samally

Staff Software Engineer

Отправить сообщение
Совсем нет.
Например у нас идет несколько выборок из БД. Мы можем отправить их все сразу и обрабатывать по мере поступления результатов. После завершения последнего строим страницу. Просто это непривычно для PHP и нет действительно хороших фреймворков под такую архитектуру, где такое было бы удобно применять.
Это уже будет эффективнее, чем последовательное выполнение каждого запроса отдельно. mysqli причем поддерживают такую возможность из коробки для native driver реализации.
Кстати phpDaemon как раз умеет обрабатывать в одном процессе несколько запросов. Один чего-то ждет — обрабатывается другой.
Но для того чтобы это поддерживалось все приложение должно быть спроектировано с учетом таких фич.
Ну это можно организовать. Другой вопрос, что пока что такого готового решения нет.
С нормально спроектированным и написанным приложением все будет нормально даже не на типичной задаче. Я не говорю конечно про отдельные случаи, когда на странице особо тяжелые вычисления, дергается несколько апи на бэкенде и т.п.
Большинство операций в PHP — блокирующие. Для использования неблокирующих операций либо есть специальные фичи (например в mysqli), либо это все можно сделать самому.
В Node.JS же как бы наоборот — все строится на неблокирующей архитектуре, но можно глупо применить какую нибудь блокирующую операцию и сломать этим весь профит.
Может быть PHP и слабее Node.JS в этом сравнении, но 500 запросов в секунду это вообще смешно. Видно плохо тюнили. На виртуалке безо всякого тюнинга тысячу запросов в секунду спокойно выдает, не напрягаясь особо.
PHP + libevent = отличная неблокирующая архитектура.
Остается проблема с сильным потреблением памяти, но утечек опять же нет если не допускать самому, так что терпимо. А если этого все же не хватает, то тут уже и node вряд ли кардинально изменит картину.
Они просто нужны далеко не на каждом шагу
Нужен модуль ngx_headers_more. Если он установлен, то можно поменять просто в конфиге. Если нет, то все равно придется пересобирать. Но это не сложно на самом деле.
Я не говорю об HTTPS. Обычный функционал веб сервиса нормально защищенный от XSS/CSRF может с большой долей вероятности проверять реферер в качестве дополнительной проверки на равне с секретным токеном.
Реферер — стандартный функционал обеспечиваемый браузером. Без реферера запросто могут не работать критичные к безопасности вещи.
Собственно реферер наравне с секретным токеном это один из пунктов проверки для многих защит от CSRF.
Либо просто три подхода на отжимания перед сном и вырубает на отлично ))
Просто стоит так и писать, а то сразу 777 для всех :)
Ясно, большое спасибо )
И вообще за SxGeo огромное спасибо — очень полезная библиотека.
В том то и дело, что работает он не как два отдельных индекса, а эффективнее. Вот и интересно, изменит ли график и на сколько именно такой вариант.
Нормальная структура для использования индекса и запрос должны быть примерно такими:

CREATE TABLE `worldip` (
  `start` int(10) UNSIGNED NOT NULL default '0',
  `end` int(10) UNSIGNED NOT NULL default '0',
  `code` varchar(2) NOT NULL default '',
  PRIMARY KEY (`start`,`end`)
) ENGINE=MyISAM;

SELECT code FROM `worldip` WHERE `start` <= INET_ATON('IP') AND `end` >= INET_ATON('IP') LIMIT 1


Индекс должен быть сдвоенным в общем.
Добавьте пожалуйста в обзор эту базу:
www.wipmania.com/ru/base/

Там как раз нормально с индексом используется mysql
Зачем выкладывать на хабр такие вот, сделанные только под «себя», неконфигурируемые, недопиленные для общего использования вещи?
Какой вообще в этом смысл?
В том-то и дело, что сейчас они объединяют все в единую систему. Убирают понятие пользователя отдельного сервиса. Теперь ты либо юзаешь гугл, либо нет )

Информация

В рейтинге
Не участвует
Откуда
Lisbon, Lisboa, Португалия
Дата рождения
Зарегистрирован
Активность

Специализация

Разработчик мобильных приложений, Архитектор программного обеспечения
Ведущий
От 15 000 €
Kotlin
Kotlin Multiplatform
Разработка под Android
Java
TypeScript
JavaScript