Форум → Программирование → PHP для идиотов → php-скриптинг в условиях высокой нагрузки
php-скриптинг в условиях высокой нагрузки
Страницы: ← Предыдущая страница • Следующая страница →
-
-
30 января 2011 г. 19:24, спустя 1 минуту 57 секунд
AlexB, ну с тем то что думать нужно я согласен )не всё полезно, что в swap полезло -
30 января 2011 г. 19:28, спустя 3 минуты 11 секунд
Да нет я про то, что если архитектура приложения такова, что запрос гарантированно не вызовется повторно до сброса кеша, то догма про плохое now не работает ))))) -
30 января 2011 г. 19:29, спустя 1 минуту 12 секунд
AlexB, а кто даст такую гарантию?не всё полезно, что в swap полезло -
-
30 января 2011 г. 19:31, спустя 1 минуту 40 секунд
AlexB, да в зависимости от ситуации многие догмы не работают. На то они и догмы ) -
30 января 2011 г. 19:40, спустя 8 минут 56 секунд
я жжже писал в первом потсе про кеширование запросов оперативойСпустя 18 сек.причем оперативой первого сервера а не второго -
30 января 2011 г. 19:41, спустя 51 секунду
разработчик …
какой из?не всё полезно, что в swap полезло -
12 марта 2011 г. 18:02, спустя 40 дней 22 часа 20 минут
fgets, во ты дурень))) в высоконагруженных проектах вообще не удаляют, чтобы не создавать фрагментацию на дисках)
Извиняюсь, что встрял) А если удалять и регулярно делать OPTIMIZE TABLE это исключит фрагментацию? Соблюдение целостности данных в проекте при этом эээ… соблюдается. -
12 марта 2011 г. 18:30, спустя 28 минут 38 секунд
А если удалять и регулярно делать OPTIMIZE TABLE это исключит фрагментацию?
Исключит, но
- если нужно прибегать к оптимизациии, значит всё совсем плохо - железо и т.д. не справляются
- регулярно делать оптимизацию на нагруженном проекте - значит терять посетителей и вообще не всегда возможноне всё полезно, что в swap полезло -
15 марта 2011 г. 15:57, спустя 2 дня 21 час 26 минут
Понятно. Я конечно, не профи, но кажется что если не удалять неактуальную инфу (к примеру, старый флуд на стенах и т.п.) заботясь о том чтобы фрагметации не было, то через n лет будет такой пул БД-серверов, что любая соц-сеть разориться.
Впрочем это уже демагогия -
15 марта 2011 г. 16:30, спустя 33 минуты 30 секунд
заводите на сайте изначально строгие правила по отношению к флуду и всякому хламу для юзверей, если хотите чистый опрятный сайт,
как на lookatme, например -
24 марта 2011 г. 16:49, спустя 9 дней 18 минут
НИкаких PDO
Чем PDO не угодил? Грузится как so-шка при старте апача, по скорости ничуть не хуже стандартных mysql_ функций
Кстати, какими бенчмарками пользуетесь для теста производительности php-кода? -
24 марта 2011 г. 16:56, спустя 6 минут 59 секунд
Hamp, PDO немного уступает mysqli по скорости, но зато у mysqli есть недостаток
http://community.livejournal.com/ru_php/1519463.html
В mysqli можно сделать так$link = new mysqli(…);
$result = $link->query("SELECT …");
$row = $result->fetch_assoc();
а можно так$link = new mysqli(…);
$stmt = $link->prepare("SELECT col1, col2 …");
$stmt->bind_param(…);
$stmt->execute();
$stmt->bind_result($var1, $var2);
$stmt->fetch();
мне бы хотелось
1. получить в результате массив, а не отдельные переменные
2. получить результат в виде mysqli_result
3. при этом использовать препареды
иными словами, как сделать$link = new mysqli(…);
$stmt = $link->prepare("SELECT * FROM …"); // именно *, это важно
$stmt->bind_param(…);
$stmt->execute();
[ … blabla …]
$row = $result->fetch_assoc();не всё полезно, что в swap полезло -
24 марта 2011 г. 17:00, спустя 3 минуты 43 секунды
а еще нет именованных плейсхолдеровСпустя 35 сек.но зато, мне нравится, что result & stmt - 2 разных класса а не 1, как в пдо
Страницы: ← Предыдущая страница • Следующая страница →
Пожалуйста, авторизуйтесь, чтобы написать комментарий!