Я уже некоторое время запускаю небольшой проект Java SpringFramework с MongoDB. Хотя он не работает на самом мощном оборудовании, в последнее время он ведет себя очень медленно с одной конкретной коллекцией.
Конкретная коллекция базы данных содержит около 30 записей со средним размером 1,5 КБ. Большинство других коллекций меньше и намного быстрее.
Я сузил его до базы данных, так как создание пустой коллекции ускоряет ее полностью.
Хотя журналы меня смущают. Когда я запрашиваю свою веб-страницу, это мой журнал (работает на немного более хорошем оборудовании, чем мой сервер, который даже медленнее):
...
2018-07-23 13:34:08.176 DEBUG 12736 --- [nio-8080-exec-8] o.s.web.servlet.DispatcherServlet : DispatcherServlet with name 'dispatcherServlet' processing GET request for [/employees/active]
2018-07-23 13:34:08.177 DEBUG 12736 --- [nio-8080-exec-8] s.w.s.m.m.a.RequestMappingHandlerMapping : Looking up handler method for path /employees/active
2018-07-23 13:34:08.178 DEBUG 12736 --- [nio-8080-exec-8] s.w.s.m.m.a.RequestMappingHandlerMapping : Returning handler method [public java.lang.String be.ccdestrycker.callcentermanager.controller.EmployeeController.showActiveEmployees(org.springframework.ui.ModelMap)]
2018-07-23 13:34:08.178 DEBUG 12736 --- [nio-8080-exec-8] o.s.web.servlet.DispatcherServlet : Last-Modified value for [/employees/active] is: -1
2018-07-23 13:34:09.725 INFO 12736 --- [nio-8080-exec-8] b.c.c.CallCenterManagerApplication : TIMING - controller start
2018-07-23 13:34:09.747 INFO 12736 --- [nio-8080-exec-8] b.c.c.CallCenterManagerApplication : TIMING - controller end
2018-07-23 13:34:09.748 DEBUG 12736 --- [nio-8080-exec-8] o.s.w.s.v.ContentNegotiatingViewResolver : Requested media types are [text/html, application/xhtml+xml, image/webp, image/apng, application/xml;q=0.9, */*;q=0.8] based on Accept header types and producible media types [*/*])
2018-07-23 13:34:09.748 DEBUG 12736 --- [nio-8080-exec-8] o.s.w.s.v.ContentNegotiatingViewResolver : Returning [org.thymeleaf.spring5.view.ThymeleafView@5d0cd3ba] based on requested media type 'text/html'
...
Журнал намного длиннее, но после этого времени замедления нет.
Самый продолжительный период зависания - это непосредственно перед тем, как код моего контроллера (в журнале прямо над моим первым журналом «ТАЙМЕР») выполняет фактический запрос. Или контроллер не выполняется последовательно? Это мой запрос:
@RequestMapping(value = {"/employees/active"})
public String showActiveEmployees(final ModelMap model) {
this.loggerService.info("TIMING - controller start");
model.addAttribute("allEmployees", this.employeeService.findAllActive());
this.loggerService.info("TIMING - controller end");
return "employees-list";
}
Поэтому я не понимаю, где именно происходит замедление и как оно связано с коллекцией MongoDB, даже если запрос даже не выполняется в этот момент. И если есть что-нибудь, я могу это улучшить.
Вот класс Employee, если это необходимо.
public class Employee {
@Id
public String id;
public List<Skill> skills = new ArrayList<>();
public List<EmployeeLanguage> employeeLanguages = new ArrayList<>();
public List<EmployeeAbsence> employeeAbsences = new ArrayList<>();
public List<EmployeeEvaluation> employeeEvaluations = new ArrayList<>();
public List<EmployeeNote> employeeNotes = new ArrayList<>();
public String firstName;
public String lastName;
public String code;
public int peopleOnBehalf;
public String maritalStatus;
public String nationality;
public String address;
public int postalCode;
public String town;
public String phoneNumber;
public String email;
@DateTimeFormat(iso = DateTimeFormat.ISO.DATE)
public LocalDate dateOfBirth;
public String placeOfBirth;
public String landOfBirth;
public String idCardNumber;
public String nationalRegisterNumber;
public String bankAccountNumber;
public String comment;
public boolean active = true;
@DateTimeFormat(iso = DateTimeFormat.ISO.DATE)
public LocalDate startDate;
@DateTimeFormat(iso = DateTimeFormat.ISO.DATE)
public LocalDate endDate;
public String unactiveReason;
public LocalDateTime dateCreation;
public LocalDateTime dateLastEdit;
моя служба:
@Service
public class EmployeeService {
@Autowired
private EmployeeRepository employeeRepository;
...
public List<Employee> findAllActive() {
return this.employeeRepository.findByActive(true);
}
}
мой репозиторий:
public interface EmployeeRepository extends MongoRepository<Employee, String> {
List<Employee> findByActive(boolean active);
}
добавлен сервис и репозиторий к моему посту выше. В моем сервисе также есть множество других методов, но я решил, что они здесь не важны, поэтому пропустил их.
Я предполагаю, что EmployeeLanguage, EmployeeAbsence и т. д. Также являются объектами? Единственное, что я могу вам посоветовать, - это оптимизировать свой entityEmployee. Либо разбейте его на части, либо как следует оптимизируйте. Одна статья, показывающая, что я имею в виду: zeroturnaround.com/rebellabs/…
Если вы имеете в виду объекты, хранящиеся в базе данных в отдельных коллекциях, нет. Они полностью хранятся исключительно в объекте Employee. Поэтому это так медленно, потому что Employee содержит в себе слишком много атрибутов и списков? Я тогда займусь этим! Так что лучше делайте больше запросов для разделения коллекций, чем один для большого. Спасибо
Чтобы дать здесь ответ, я последовал вашему совету разделить его. Все мои дочерние объекты теперь находятся в своих собственных репозиториях и имеют простые идентификаторы. С тех пор скорость не была проблемой.




Вы можете показать свой класс employeeService?