самый дельный комментатор!!! ssi надо использовать там где это действительно дает эффект
пихать микрошаблоны для формирования одной строчки таблицы большой — это тупизм!!!
можно использовать shm для хранения общих объектов
или тот же мемкеш…
у меня, например, строка поиска сделана в обном ssi а вывод контента (по поиску) в другом
все конечно зависит от проекта, но блоки не должны быть взаимосвязаны
блок выдачи перечня товаров и блок топ10 товаров. блок голосования и рекламный блок.
конечно ssi должно быть использовано в меру. По мимо ssi, для формирования контента я использую и первый и второй подходы.
знаешь толк в бэдграундный запусках — это радует
многим пытался втолковать вышеописанные минусы.
как говориться — пока не пощупаешь — не поймешь.
костыль конечно: но я использую это code.google.com/p/php-forker/
разработано специально для запуска долгоиграющих процессов, чтоб не было оверхедов на шел и прочих побочек.
Опять же — одна вставка в БД будет короче, чем инициализация шела, запуск процесса, его форканье и тд.
Да и с PHP есть проблема, что нельзя отдать клиенту весь контент и закрыть соединение а потом уже заносить данные о клике/показе в БД
можно,
если сделать так (не знаю на сколько это оптимально, но если БД тормозит, то как вариант):
— принимаем запрос,
— формируем некую строку
— запускаем в бэдграунде новый процесс, который будет осуществляь логирование в БД
— закрываем соединение.
в первую очередь
главное выбрать правильное архитектурное решение.
ЯП — второе дело. Хотя чем скорость отклика выше — тем лучше
С точки зрения логики — С/С++ решения наиболее оптимальный выбор.
С точки зрения скорости разработки — где-то на 20-30% больше чем РНР
я как-то сделал замер
решение в ввиде ngx-модуля отрабатывало в 80 раз быстрее чем решение в виде РНР-скрипта
думаю, что решение в виде отдельного сервера отработает раз в 20 быстрее
если нагрузка на сервер не критична, то решение в ввиде РНР-скрипта вполне допустимо.
кешируем то что нам нужно с какими нужно ключами
если надо — тянем бэкенд с другого сервера (у меня пока второго сервера нет по этому я про это промолчал)
все исчезло
если url = /code/delete/123 то в моей схеме можно разрулить так:
если бы этого не надо было делать, то Ваше решение вполне подошло бы;
ssi надо использовать там где это действительно дает эффект
пихать микрошаблоны для формирования одной строчки таблицы большой — это тупизм!!!
пол года как исходники валяются на гитхабе
у меня есть еще пара интересного материала.
и там Технические Директора считали ZF образцом кодинга
по этому с ним и сравниваю
можно использовать shm для хранения общих объектов
или тот же мемкеш…
у меня, например, строка поиска сделана в обном ssi а вывод контента (по поиску) в другом
все конечно зависит от проекта, но блоки не должны быть взаимосвязаны
блок выдачи перечня товаров и блок топ10 товаров. блок голосования и рекламный блок.
конечно ssi должно быть использовано в меру. По мимо ssi, для формирования контента я использую и первый и второй подходы.
не задашь параметры и экшены для бэкенда.
Может это возможно, просто у меня не получилось
многим пытался втолковать вышеописанные минусы.
как говориться — пока не пощупаешь — не поймешь.
костыль конечно: но я использую это code.google.com/p/php-forker/
разработано специально для запуска долгоиграющих процессов, чтоб не было оверхедов на шел и прочих побочек.
Опять же — одна вставка в БД будет короче, чем инициализация шела, запуск процесса, его форканье и тд.
можно,
если сделать так (не знаю на сколько это оптимально, но если БД тормозит, то как вариант):
— принимаем запрос,
— формируем некую строку
— запускаем в бэдграунде новый процесс, который будет осуществляь логирование в БД
— закрываем соединение.
главное выбрать правильное архитектурное решение.
ЯП — второе дело. Хотя чем скорость отклика выше — тем лучше
С точки зрения логики — С/С++ решения наиболее оптимальный выбор.
С точки зрения скорости разработки — где-то на 20-30% больше чем РНР
спасибо
решение в ввиде ngx-модуля отрабатывало в 80 раз быстрее чем решение в виде РНР-скрипта
думаю, что решение в виде отдельного сервера отработает раз в 20 быстрее
если нагрузка на сервер не критична, то решение в ввиде РНР-скрипта вполне допустимо.