Система поиска и букинга артистов

[ab_dev]

Собственно представляю свой проект, Art-Booking
Система для поиска и букинга (заказа) артистов, музыкантов, оборудования, и т. д.
http://art-booking.org

Большое внимание уделено оптимизации: (практически никакого AR, только DAO+SQL), по возможности не используются тяжелые компоненты во вьюхах.

[Халявщик]

А поиск реализован через php?

[ab_dev]

А поиск реализован через php?

Ну да + SQL.

[Халявщик]

Ну да + SQL.

Интересно. Тогда получается, что соединение идет через AJAX, так как с Comet'ом PHP вроде как не умеет работать.
А что если будет к примеру 1200 звукорежиссеров? Поиск будет таким же быстрым? Или придется что-то менять?

[SiZE]

соединение идет через AJAX, так как с Comet'ом PHP вроде как не умеет работать

WAT?


ab_dev, в строке поиска необходимо дождаться пока пользователь введет весь запрос целиком, а не слать запрос на нажатие каждой клавиши.

[ab_dev]

Ну да + SQL.

Интересно. Тогда получается, что соединение идет через AJAX, так как с Comet'ом PHP вроде как не умеет работать.
А что если будет к примеру 1200 звукорежиссеров? Поиск будет таким же быстрым? Или придется что-то менять?

Индексы в бд + на всякий случай горизонтальное масштабирование сервера по метрикам загрузки. Из 2.5млн населенных пунктов текстовый LIKE поиск осуществляется за 20-30мсек.

Запросы более 100 мс логгируются.

Уже начал писать бэкенд на go, который будет более масштабируемым и гибким.

ab_dev, в строке поиска необходимо дождаться пока пользователь введет весь запрос целиком, а не слать запрос на нажатие каждой клавиши.

Стоит таймаут ввода, который динамически изменяется в зависимости от загруженности системы.

[SiZE]

Стоит таймаут ввода, который динамически изменяется в зависимости от загруженности системы.

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

[ab_dev]

Стоит таймаут ввода, который динамически изменяется в зависимости от загруженности системы.

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

Live поиск сейчас в трендах. Минимальная задержка после ввода - 200мс.

[Халявщик]

Live поиск сейчас в трендах.

Ну так не через AJAX же.

[anton44eg]

а через что?

[Халявщик]

На ajax'е свет клином сошелся что ли ?
Есть и другие технологии. Например, сокеты.

[anton44eg]

чем они лучше в данном случае?

[Халявщик]

Более высокая скорость работы, меньший траффик

[ab_dev]

На ajax'е свет клином сошелся что ли ?
Есть и другие технологии. Например, сокеты.

А зачем, если проще кешируемую вьюху аяксом подгрузить?

Более высокая скорость работы, меньший траффик

Основная доля трафика - изображения тянущиеся из S3.

[anton44eg]

так аяксом можно только json гонять, разница в траффике будет мизерная, а работать с сокетами из php - очень сомнительное удовольствие

[Халявщик]

А зачем, если проще кешируемую вьюху аяксом подгрузить?

Каждому свое)

так аяксом можно только json гонять, разница в траффике будет мизерная, а работать с сокетами из php - очень сомнительное удовольствие

По-моему живой поиск и php - вещи несовместимые. Это незаметно сейчас, когда на сайте мало посетителей, а когда их станет много - тогда и всплывет проблема скорости. А насчет траффика - если суммировать все полученные и отправленные HTTP заголовки при печатании какой-нибудь абракадабры, то разница не покажется мизерной по сравнению с постоянным соединением.

[ab_dev]

По-моему живой поиск и php - вещи несовместимые. Это незаметно сейчас, когда на сайте мало посетителей, а когда их станет много - тогда и всплывет проблема скорости.

Вот поэтому бэкенд переписываем на Go. На первых этапах это можно решить горизонтальным масштабированием (увеличением ресурсов сервера и добавлением хостов через балансировщик)

[anton44eg]

А зачем, если проще кешируемую вьюху аяксом подгрузить?

Каждому свое)

так аяксом можно только json гонять, разница в траффике будет мизерная, а работать с сокетами из php - очень сомнительное удовольствие

По-моему живой поиск и php - вещи несовместимые. Это незаметно сейчас, когда на сайте мало посетителей, а когда их станет много - тогда и всплывет проблема скорости. А насчет траффика - если суммировать все полученные и отправленные HTTP заголовки при печатании какой-нибудь абракадабры, то разница не покажется мизерной по сравнению с постоянным соединением.

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

[anton44eg]

По-моему живой поиск и php - вещи несовместимые. Это незаметно сейчас, когда на сайте мало посетителей, а когда их станет много - тогда и всплывет проблема скорости.

Вот поэтому бэкенд переписываем на Go. На первых этапах это можно решить горизонтальным масштабированием (увеличением ресурсов сервера и добавлением хостов через балансировщик)

Почему именно Го? Смотрю в его сторону, но совсем для других задач. Он не выглядит особо подходящим именно для веб-сайта

[Халявщик]

Вот поэтому бэкенд переписываем на Go. На первых этапах это можно решить горизонтальным масштабированием (увеличением ресурсов сервера и добавлением хостов через балансировщик)

Лучше на сях.