Проблема с Rails, Webrick или PostgreSQL?Неверно сформированный HTML, сгенерированный после запроса БД - PullRequest
2 голосов
/ 19 июля 2011

Я использую Rails 3 в Ubuntu с PostgreSQL 8.4 и WEBrick.

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

Восьмая строка ниже - это некорректный HTML.Это происходит около 140-го ряда таблицы.Но он продолжает отображать больше строк после приведенных ниже.

<tr class="from_hc"> 
  <td class="date_and_time">Jul 13, 2011 11:00 AM</td> 
  <td class="name">Kim Orange</td> 
  <td>PHYSICAL_ACTIVITY</td> 
  <td>text text</td> 
  <td>ok</td> 
  <td></td> 
  <td><a href="/messag/a></td>
</tr>
<tr class="from_hc"> 
  <td class="date_and_time">Jul 13, 2011 11:00 AM</td> 
  <td class="name">Tom White</td> 
  <td>PHYSICAL_ACTIVITY</td> 
  <td>text text</td> 
  <td>ok</td> 
  <td></td> 
  <td><a href="/messages/260/edit">Edit</a></td> 
</tr>

Это проблема с количеством возвращаемых строк?Есть ли конфиг, который нужно установить в Rails, PostgreSQL или WEBrick?Может ли это быть проблема с SSL?Что может вызвать это?

Тот же код и таблица отлично работают на Heroku, поэтому мне интересно, если это проблема конфигурации WEBrick ...

Я увеличил "shared_memory" для Postgres, ноэто не помогло.

Спасибо !!!

Ответы [ 3 ]

1 голос
/ 13 августа 2011

Вы пытались сменить веб-серверы и использовать mongrel или thin? Вам также следует попробовать изменить версии Ruby и Rails.

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

Попробуйте открыть консоль и запустить @ model.to_param для соответствующей записи. Это выглядит иначе, чем другие записи? У него есть специальные символы?

1 голос
/ 23 июля 2011

Скорее всего, вы превысили время ожидания ответа или ограничения памяти / ресурсов сервера.

Вы никогда не должны возвращать огромные объемы данных ни в одном приложении, не говоря уже о веб-приложении, поскольку данные становятся совершенно бессмысленными.Если это для просмотра, тогда используйте разбиение на страницы, чтобы за один раз обрабатывалось только небольшое количество данных (люди просто не в состоянии разобраться с таким количеством записей)

Если вам это нужно для статистического анализазатем запустите фоновое задание (возможно, грабли?), чтобы собрать данные, проанализировать их и вывести простую единственную запись со всеми вычисленными статистическими данными

Если это какая-то функция подачи или экспорта, то снова фоновое заданиев грабельной задаче, которая создаст окончательный файл документа xml, сохраненный как актив, который может быть обработан вашим приложением в надлежащее время, является лучшим решением

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

Это ДЕЙСТВИТЕЛЬНО плохая практика.Это стоит денег и времени.И вы (пропускная способность и ресурсы сервера), ваши посетители должны ждать дольше (время - деньги), и вы получите больший счет за хостинг, если будете платить за облачные вычисления на мегабайтный хост, поэтому я действительно призываю вас изменить свой подход.

Как правило, делайте то, что делает Google, и обслуживайте до 10 результатов на странице (Сколько серферов когда-либо получали страницу 10 в результатах поиска?)

0 голосов
/ 17 августа 2011

Оказывается, что в нескольких строках базы данных были символы, отличные от UTF-8 (UTF-16?).В частности, эти умные цитаты, апостроф и многоточие, которые создает Microsoft Word.Пользователь вырезал и вставил из Word в веб-форму.

Интересно, есть ли способ заставить UTF-8 в PostgreSQL защитить от этого в будущем ...

...