Я автоматически связываю профили, существующие на моем сайте, в текстах блогов, которые содержат названия профилей. Для этого я …
1) … извлекать ~ 500 строк (только?) Из 4 разных таблиц MySQL, содержащих разные типы профилей, в одну базу данных, используя 4 отдельных запроса.
2) … str_replace () каждое имя профиля индивидуально со ссылкой в тексте блога, если это имя профиля существует (пытался поместить их в массивы поиска-замены ранее и также выполнить одну функцию str_replace ()).
Хотя он делает то, что должен, он значительно замедляет обзорную страницу Blogpost. Загрузка 10 сообщений на странице обзора, в которой каждый контент проверяется на соответствие именам профилей, занимает более 30 секунд для загрузки. Без всей этой процедуры автосвязи страница обзора Blogpost загружается быстро.
Я считаю, что виновником является шаг 2). Что я могу сделать, чтобы ускорить процесс поиска и замены большого количества строк (поступающих из базы данных) в одной текстовой строке?
Следуя рекомендациям @ Devon и @ tadman, теперь пользователи обязаны позаботиться о связывании профилей. Однако мне нужна была возможность ссылки на профили, которые не существуют на момент написания статьи, но могут быть созданы позже. Пользователи теперь отмечают любой существующий или будущий профиль при написании сообщения, включив их имя в фигурные скобки. Они найдены путем выполнения preg_replace_callback и искать в базе данных имя профиля внутри фигурных скобок.
private function link_profile($name) {
// Put your database search(es) here
// Create link to profile
return $link_to_profile;
}
$text = preg_replace_callback("/\{(.*)\}/Usi", "link_profile", $text);
В моем предыдущем ресурсоемком анзаце было до 5N str_replace призывает к N профилям в базе данных, так как вариации имени профиля, где рассматриваются. Теперь существует не более N и 4N вызовов базы данных для N профилей, отмеченных в тексте сообщения, поскольку может потребоваться поиск 4 различных типов профилей, находящихся в отдельных таблицах БД. Новая процедура сокращает время загрузки блога до ~ 3 с, отмечая улучшение более чем в 10 раз по сравнению с предыдущим методом.
Других решений пока нет …