Это плохой алгоритм входа во flash, php и mysql?

Мой сайт находится в режиме flash. Логин также во флеш-памяти. Это процесс входа в систему:

  1. Введите логин и пароль

  2. Отправить на страницу authentication.php

  3. Вот мои сомнения относительно страницы authentication.php:

    (1) Проверьте параметры публикации, то есть имя пользователя и пароль

    (2) Ша / хеш-пароль

    (3) Q1 (запрос 1), выберите имя пользователя и пароль из таблицы пользователей.

    (4) При совпадении выполните другой запрос (Q2), проверьте, находится ли пользователь по-прежнему в статусе блокировки.

    (5) Если пользователь не находится в статусе блокировки, выполните запрос (Q3), чтобы проверить, входит ли пользователь в первый раз за сегодня.

    (6) Если это первый журнал, выполните запрос на обновление (Q4), чтобы вознаградить пользователя некоторыми деньгами.

    (7) Создайте сеанс, идентификатор пользователя, хешированную переменную сеанса с помощью md5. т.е.

    $ _SESSION ['loggin'] = 1;

    $ _SESSION ['хеш'] = md5 (имя пользователя.secret);

    (Я использую $ _SESSION ['hash'] для другой аутентификации на другой странице, просто игнорируйте это)

  4. Вернуть результат на прошивку.

Я знаю, что это очень плохой процесс входа в систему, множество запросов mysql, 2 хеширования (вычисления php). Я все еще думаю / ищу лучший способ для этого. Как комбинирование запроса и т. Д. Есть идеи, как улучшить поток ?? (Я должен выполнить все, что я упомянул выше)

[Текущий вход медленный]


mysql php workflow flash login
person mysqllearner    schedule 09.12.2009    source источник

Ответы (4)


arrow_upward
1
arrow_downward

Чтобы получить более абстрактный взгляд на проблему, помогли бы ответы на следующие вопросы:

  • В какой среде вы развиваетесь? 100% локально (локальный код и Db или локальный код и внешний Db? И т. Д.)?
  • Это все на 100% «свежий» код, разработали ли вы что-нибудь подобное и не сталкивались ли вы с этими проблемами?

Кстати, я использую встроенный монитор ресурсов Chromes, который показывает разбивку размера веб-страниц и времени, затраченного на загрузку. Я считаю это более полезным, чем тот, что есть в FireFox / FireBug.

Проверяли ли вы каждый из своих запросов в чем-то вроде PHPMyAdmin или во время выполнения тестового запроса? Сложите общее время каждого запроса и посмотрите, в чем разница.

Удачи алекс

person Alex    schedule 09.12.2009
comment
Также, когда вы говорите, что он медленный, о скольких секундах вы говорите? Всегда ли это одинаковое количество времени? - person Alex; 09.12.2009
comment
- Я тестирую локальный код и БД и помещаю его на реальный сервер, чтобы увидеть производительность. Это нормально на местном уровне, но в реальном времени он намного медленнее - на самом деле не совсем свежий, но на данный момент у него самые большие записи данных. Ранее было несколько тысяч записей. Это больше, чем это. Ресурсы бюллетеня Chromes? Хорошо, я пойду и попробую использовать это. Иногда я делал запрос на PHPMyAdmin, он всегда возвращал 0,00xx секунды, что, по моему мнению, очень быстро. Но на веб-сайте вход в систему довольно медленный, занимает более 5 секунд. (Может быть, это не проблема mysql) ?? Спасибо - person mysqllearner; 09.12.2009
comment
Гм .. позвольте мне перейти на это. Исходя из текущего потока входа в систему, упомянутого выше, и у моих текущих пользователей базы данных есть записи 50K ++, нормально ли, что вход в систему занимает более 5 секунд? Поскольку предыдущий веб-сайт, который я создал, вход в систему происходит быстро, намного быстрее, чем этот - person mysqllearner; 09.12.2009
comment
Это очень медленно. У вас есть выделенный сервер или кому вы платите за его размещение? Если это действительно дешевая / некачественная хостинговая компания, скорее всего, из-за них. Вы тестируете всю систему локально или только компоненты без флэш-памяти? - person Alex; 10.12.2009

arrow_upward
1
arrow_downward

Привет, я бы предпочел объединить в один запрос.

SELECT u.user_id, u.name, u.password, u.last_last FROM users u 
LEFT JOIN banned b ON u.user_id = b.user_id
WHERE u.name = ? AND u.password = ?;
person opHASnoNAME    schedule 09.12.2009

arrow_upward
0
arrow_downward

Сам процесс не так уж и плох.

Без данных о производительности действительно сложно сказать, почему он такой медленный. Вероятность потери производительности составляет 90% в совершенно другом месте, чем вы думаете. Поместите в код пару строк, которые выводят текущее время (включая миллисекунды), чтобы увидеть, где оно зависает.

Соединение, безусловно, могло бы помочь, но если на это не потратить время, оно только усложнит понимание и поддержку кода. Если вы обнаружите, что доступ к БД занимает много времени, я предлагаю проверить, что у вас есть правильные индексы для ваших запросов. Если индексы в порядке, опубликуйте вопрос с DLL таблиц, если вам нужна помощь в написании соединения. Но сначала измерьте производительность.

person Aaron Digulla    schedule 09.12.2009
comment
Как вы измеряете производительность? Мой метод - через firebug. Включите Интернет и посмотрите время отклика. Как проверить время запросов ?? - person mysqllearner; 09.12.2009
comment
Ну, в основном мои индексы - это первичный ключ, идентификатор пользователя или что-то еще. Потому что это больше всего я ищу. Любая помощь или совет будут очень признательны :) - person mysqllearner; 09.12.2009
comment
Измерьте производительность: поместите вызовы журналирования в код сервера. Что касается запросов, EXPLAIN - ваш друг: dev.mysql.com/ doc / refman / 5.0 / en / manage.html - person Aaron Digulla; 09.12.2009

arrow_upward
0
arrow_downward

Несколько идей относительно производительности и безопасности:

Шаги 3-6: При чтении из базы данных вы должны иметь возможность выбрать имя пользователя, пароль, статус пользователя и дату последнего входа в систему в одном запросе, если ваша база данных спроектирована правильно (и, как кажется, ArneRie только что опубликовал псевдо- Оператор MySQL для этого).

Обновление пользователя (предоставление им вознаграждения) является однократным INSERT / UPDATE и не должно сильно влиять на производительность.

Помимо сокращения количества запросов MySQL (и, при необходимости, использования измененных хешей для пароли) процесс выглядит нормально.

person leepowers    schedule 09.12.2009
comment
Что ж, 1 вещь, которую я не решаюсь объединить, - это то, что если имя пользователя и пароль не совпадают, я могу немедленно вернуть результат, вход в систему не удался. Если я объединю запрос, это означает, что он выбрал больше материалов, и на ответ может потребоваться больше миллисекунд. Но я также знаю, что вероятность того, что имя пользователя и пароль не совпадают, очень мала, если только он не пытается взломать. Возможно, я ошибаюсь. Пожалуйста посоветуй - person mysqllearner; 09.12.2009
comment
Комбинирование, я имею в виду выполнение комбинированного запроса. Печатай слишком быстро, извини за мой плохой английский - person mysqllearner; 09.12.2009
comment
Использование JOIN, как в примере ArneRie, будет очень, очень близко к тому же (с точки зрения производительности), что и выбор только для информации пользователя. Чем меньше операторов MySQL должен выполнять ваш сценарий, тем лучше. - person leepowers; 09.12.2009