Рекомендации по наиболее эффективному способу планирования html / php и многопользовательского проекта Ajax - PullRequest
0 голосов
/ 09 января 2010

Я запускаю экспериментальный проект и искал совета, чтобы выбрать лучший вариант, который у меня есть.

Проект будет рассчитан на 100 - 1000 пользователей .Он собирает свои основные данные, используя данные javascript + json со страницы пользователя flickr , а затем использует их для отображения конкретных фотографий flickr.Переменные, которые необходимо сохранить, включают в себя специфический для пользователя URL-адрес и, возможно, 4 более коротких строковых переменных .Это все нужно будет искать на каждой странице запроса.Эти переменные не изменяются во времени, если пользователь не посещает страницу обновления, и поэтому эти переменные являются статическими 99% времени .

Страница каждого пользователя будет расположена по адресу / user-slug

Я продумал три варианта, хотя я не хочу ограничивать себя этими тремя (пожалуйста, предложите свой), не будучиОпытный программист с большим количеством доступа, я искал самый быстрый, самый статичный и кешируемый способ 1011 * для достижения этого, и я уверен, что вы, ребята, гораздо умнее, чем я в достижении этого,

для N пользователей:

  1. полностью статический подход : создается N статических html-страниц, каждая пользовательская страница обновляется при запросе, htaccessmod-rewrite используется для того, чтобы каждый html-файл напоминал доступ к каталогу.Обновление;Php используется для перезаписи статических страниц, когда пользователь запрашивает их обновление, или полная перезапись N выполняется, когда шаблон требует обновления. Большая часть кода разработки находится в файле JavaScript , поэтому сам шаблон, вероятно, будет редактироваться не так часто.Каждый раз, когда вызывается страница пользователя, отображается статический html-файл, javascript собирает данные с сервера flickr и отображает их.

  2. полустатический подход : Php + modrewrite используется для имитации различных N пользовательских страниц, пользовательского slug, и в базе данных MySQL сохраняется только пользовательский slug, затем пользовательские переменные загружаются через отдельные уникальные статические текстовые файлы, названные в честь пользовательского slug (user-slug.txt) через javascriptклиент браузера (эти данные не являются конфиденциальными).Каждый раз, когда вызывается страница, выполняется 1 вызов MySQL и 1 дополнительный текстовый файл загружается в заголовок через JavaScript.Javascript собирает данные из flickr и отображает их.

  3. полностью динамический подход : Php + mod rewrite используется для имитации различных N страниц (как вышеописанный метод).Все пользовательские переменные хранятся в MySQL.Каждый раз, когда вызывается страница, выполняется около 4 вызовов MySQL, Php создает страницу шаблона, используя эти переменные.Javascript собирает данные из flickr и отображает их.В этом методе, который, я считаю, является более распространенным подходом к многопользовательским веб-сайтам, я также ищу способы сделать эти php / MySQL-запросы кэшируемыми на самом сервере.Я на общем хостинге, кстати, у меня нет низкоуровневого доступа к самой конфигурации.

Большое спасибо за ваш вклад Очень, очень признателен!

Ответы [ 2 ]

1 голос
/ 09 января 2010

Я бы тоже пошел с полной динамикой. Хотя постарайтесь сделать любой javascript / css статичным, чтобы он мог быть связан с внешним файлом и не создавался.

1 голос
/ 09 января 2010

Я бы начал с полного динамического подхода.

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

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

...