RU2691834C1 - Method of managing web site data - Google Patents

Abstract

FIELD: information technology.SUBSTANCE: invention relates to methods of managing website data. At least one static part of the web page and at least one dynamic part of the web page, which are stored in the non-volatile memory, are generated. A request to the website is received from at least one user. Cache file presence in non-volatile memory is checked for each dynamic part of web page obtained earlier, wherein in the presence of a cache file in non-volatile memory, its content is loaded into the dynamic part of the web page. In the absence of a cache file in non-volatile memory, during verification, the dynamic portion of the web page is calculated based on the request to the web server, wherein for calculation data are obtained from core memory, if available, otherwise data is obtained from non-volatile memory.EFFECT: rate of increasing processing and managing website data.10 cl, 5 dwg

Description

TECHNICAL FIELD

[001] This technical solution, in general, relates to the computing field of technology, and in particular to methods for managing website data.

BACKGROUND

[002] Currently, the active development of the Internet in recent decades has led to a rapid growth of technical solutions that simplify the development and creation of websites. Not only new web programming languages began to appear on the market, but also ready-made sets of tools for quickly creating websites. This set of tools is called Content management system (hereinafter - "CMS"). The purpose of such a system is to enable the developer (web programmer) to create a website as quickly and easily as possible, after which it remains only to fill it with content.

[003] The Internet market is developing rapidly and as a result, the needs of website visitors are also growing. Sites have become more complicated not only in functionality, but also in design - adaptive versions of the layout for tablet devices, mobile phones, widescreen monitors have appeared. Increasing the complexity of the sites directly influenced the development of CMS - there was a need to separate systems in areas with different sets of tools.

[004] The availability of detailed technical documentation of the system simplifies the web development process, but the CMS itself without additional tools does not evolve as quickly as the tools connected to it. Any major changes to the main CMS code may affect the performance of all the tools that were installed on the sites before the changes. It turns out that when changing the CMS core (for example, optimization, which slightly reduces the load on the web server or saves memory space), it is necessary to ensure full compatibility of all the existing tools for it, including those written by third-party developers. It is labor-intensive if, for example, changes in the core were related to architecture. Therefore, changing the work of the CMS core is simply not profitable. Therefore, new tools and technologies that appeared after the start of operation of any system were connected to it as toolkits and were not part of the core.

[005] An example of such a tool is Memcached, which provides in-memory caching. The main purpose of this tool is to key data into memory and quickly return it on request. Currently, this tool has found its application in the core of many large projects, for example, Wikipedia, YouTube, Facebook and others.

[006] A similar tool is Redis, which has advanced functionality: supports complex data types (for example, lists), supports high-level operations (for example, sorting), has built-in support for replicating data to other servers in order to protect data and improve write / read speed data under load.

[007] A significant disadvantage of Memcached and Redis is the need to keep track of the relevance of the data and store information about the keys by which data can be obtained. With a significant scaling of the site, this greatly complicates the process of web page development itself.

[008] From the level of technology known US patent No. US 8924411 B2 "System and method for the dynamic provisioning of static content", patentee: Open Text SA, published: 05/31/2005.

[009] The closest analogue may be considered a technical solution, which discloses embodiments of a system and method for dynamically providing static content. In one embodiment, the information provided in the content delivery system may be updated based on information published in the content management system (CMS). One embodiment may interact with a content delivery system and a page level content management system. More specifically, content dependencies on pages that use the same content or part (s) can be tracked in a timely manner. After receiving notification of a change in content or part of it from a content management system, the content generation system can determine, based on dependencies, which pages are affected by the change, and based on this definition, dynamically generate updated data on all affected pages. The updated pages can then be saved and / or transferred to the web tier for delivery to end users.

[0010] In this invention, the basic principle is to maintain the relevance of parts of the pages by tracking data changes and updating previously stored parts of the pages in non-volatile memory. The disadvantage is that the issue of accelerating the primary generation of pages that are not yet cached is not solved.

SUMMARY OF INVENTION

[0011] This technical solution is aimed at eliminating the disadvantages inherent in the solutions known from the prior art.

[0012] A technical problem or problem solved in this technical solution is the processing and management of dynamic and static data of a website.

[0013] The technical result, which manifests itself in solving the above technical problem, is to increase the speed of processing and managing website data.

[0014] An additional technical result is the rational use of RAM due to the lack of storage of redundant data. Dynamic parts of different web pages can use the same cache. Moreover, for each dynamic part conditions can be set, depending on which he changes the result of his calculation (hereinafter - the state of the dynamic part). Caching occurs only when data changes, thus avoiding duplicate data.

[0015] This technical result is achieved due to the implementation of a method for managing website data in which at least one static part of a web page is formed and at least one dynamic part of a web page that is stored in non-volatile memory; then get a request to the website from at least one user; then check the presence of the cache file in the non-volatile memory for each dynamic part of the web page obtained at the previous step of the request, and if there is a cache file in the non-volatile memory, load its contents into the dynamic part of the web page; in the absence of a cache file in the non-volatile memory during the test, the dynamic part of the web page is calculated on the basis of a request to the web server, and the data from the main memory, if available, is first obtained for the calculation; otherwise, get data from non-volatile memory.

[0016] In some embodiments of the invention, the request is of type POST or GET.

[0017] In some embodiments of the invention, the request contains a link to a website with parameters.

[0018] In some embodiments of the invention, in the absence of a cache file in the non-volatile memory, the dynamic part of the web page is calculated during the check based on the request to the web server, and when the data is modified, they are modified first in the non-volatile memory and then in the operational one.

[0019] In some embodiments of the invention, in the absence of a cache file in the non-volatile memory, the dynamic part of the web page is calculated during the check based on the request to the web server, and when the data is modified, they are modified first in the RAM and then in the non-volatile.

[0020] In some embodiments of the invention, a change in data is the creation or update, or deletion.

[0021] In some embodiments of the invention, when the data that was used in the calculation of dynamic parts is changed, the cache files of these dynamic parts are deleted.

BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The features and advantages of this technical solution will become apparent from the following detailed description and the accompanying drawings, in which:

[0023] FIG. 1 shows an example of the implementation of the initial loading of the web site.

[0024] FIG. 2 shows an example implementation of processing a request to a web server on a web site;

[0025] FIG. 3 shows the process of forming a dynamic block cache.

[0026] FIG. 4 shows an example implementation of managing website data in a flowchart.

[0027] FIG. 5 shows an embodiment for calculating a dynamic portion of a web page.

DETAILED DESCRIPTION OF THE INVENTION

[0028] This technical solution can be implemented on a computer or other data processing device in the form of an automated system or computer-readable media containing instructions for performing the above method.

[0029] The technical solution may be implemented as a distributed computer system, the components of which are cloud or local servers.

[0030] In this solution, a system means a computer system or an automated system (AC), a computer (electronic computer), a CNC (numerical control), a PLC (programmable logic controller), a computerized control system, and any other devices capable of a given, well-defined sequence of computational operations (actions, instructions).

[0031] A command processing device is an electronic unit or an integrated circuit (microprocessor) that executes machine instructions (programs).

[0032] The command processing device reads and executes machine instructions (programs) from one or more data storage devices. In the role of storage devices can act, but not limited to, hard drives (HDD), flash memory, ROM (read-only memory), solid-state drives (SSD), optical drives, cloud storage.

[0033] Program - a sequence of instructions intended for execution by a computer control device or command processing device.

[0034] A web page (English Web-page) is a component of a website, a file hosted on the server [GOST R 52872-2012].

[0035] Cache (English (memory) cache - memory) is a memory area that serves as a clipboard, usually has a higher speed than the main memory.

[0036] Content Management System (content management system, abbr. CMS) is an information system for providing and organizing a joint process of creating, editing and managing content.

[0037] Random access memory (also random access memory, RAM, eng. RAM) is a memory, part of the computer memory system, to which the processor can turn for one operation (jump, move, etc.). It is intended for temporary storage of data and commands required by the processor to perform operations. RAM transfers data to the processor directly, or through a cache memory.

[0038] A variant of the implementation of the initial loading of a web page is shown in FIG. 1 in the form of a flowchart.

[0039] A method for managing website data may be implemented by a series of computational steps as shown in the flowchart of FIG. four.

[0040] Step 410: At least one static part of the web page is formed, and at least one dynamic part of the web page is stored in non-volatile memory.

[0041] Pre-receive a request from a user who performs an action on a website.

[0042] In order to maximize the use of non-volatile memory for storing the calculated pages, the static part of the web page, which does not change, is stored separately from the dynamic parts that depend on the loading parameters. Separate storage of dynamic parts from static parts allows reusing them on different pages, saving memory and computational power. The static part of the web page contains static, permanent and unchanging information. You can change it, but for this you need to make appropriate adjustments to the program code of the web page. Usually, the file of the static part of the web page is in HTML format. The web developer writes the HTML markup code, forming the content of the site, after which the file is given a name, and then the page is loaded onto the web server and becomes accessible to Internet users. For example, on a corporate website, the static part of a web page may contain information about the history of the company, its main areas of activity, etc. In some embodiments, the web server, when issuing web pages to the user equipment, checks whether the static portion of the page has changed or not. The fact is that the static parts of the page can also sometimes change. These changes occur much less frequently than in the case of dynamic parts. They are not systematic, but episodic in nature and are usually associated with updating the style of the site by its creators. For example, the site developer decided to replace any image on the page or simply changed the background of the entire site. For a more correct operation of the proposed method and system, it is advisable to monitor these changes to the static part of the pages and make the appropriate amendments. For this purpose, it is customary to use the checksum mechanism, which operates according to the following principle. The checksum of the static part is determined and stored in the memory in the cache overhead. When the user re-enters the page, when its dynamic part is executed, the checksum of the updated page is re-calculated and compared with the old amount. If they do not match, the server concludes that the static part of the page is outdated and the new page is overwritten in the cache. Thus, the system automatically, without human intervention, tracks such changes in the static part.

[0043] In some embodiments of the invention, a microprocessor cache may be used — a super RAM, used by a computer microprocessor to reduce the average access time to computer memory. The cache uses small, very fast memory (usually SRAM type), which stores copies of frequently used data from main memory.

[0044] In some embodiments of the invention, graphics memory (GPU) memory may be used.

[0045] The fundamental difference between the dynamic part of the web page and the static part is that its content is not constant, but may change. Content is formed depending on the wishes of the user, or rather, on the basis of requests created by visitors and sent to the web server. The most typical example of a dynamic part of a website is a page with search results issued by a search engine (for example, www.google.com) based on a search query sent by a user. Another example of the implementation of the dynamic part of a web page is an online store, where a visitor using options indicates which product interests him with what properties, sends a request (the corresponding button is usually intended for this), and after a couple of seconds gets the GUI screen list of goods that meet their criteria.

[0046] The result of calculating the dynamic parts on the web page may vary based on a predetermined set of loading parameters that include the request parameters and the unique text identifier that are listed below.

[0047] In general, the step of detecting the code for the dynamic parts in the HTML code of a web page is performed by the web server by analyzing its HTML code using an appropriate recognition software module. In this case, according to a preferred variant of the invention, the detection of dynamic parts occurs according to special instructions placed in the page code by the developers of the site. For example, a CMS installed on a web server analyzes the code of a web page while saving it to the server. If the CMS-system meets the program instructions set by the developer of the site, the system replaces them with its own labels, by which it subsequently determines the places for replacing outdated data with actual ones. In this case, the steps of detecting dynamic parts and replacing them with a JS script occur most quickly, which gives an additional speed advantage when displaying a web page.

[0048] The web pages stored on the web server can be created using components with CMS system templates or other output modifiers. Alternatively, the code of the pages can be written by a programmer in a low-level language, without using a CMS system and other similar software that manages the content of a web page.

[0049] In this technical solution, a web server is a software and hardware complex that is accessible to the user via the Internet and is capable of receiving HTTP requests from users, usually from web browsers, and issuing HTTP responses to them, usually with HTML -page, image, file, media stream or other data. As specific examples of a web server, you can name HTTP servers Apache, US, Cherokee and Resin based on operating systems Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS, without being limited to. The non-exhaustive list of standard web server features includes the following:

[0050] - Receive requests from web browsers using the HTTP standard protocol using the TCP / IP network protocols;

[0051] - Performs searching and sending hypertext files or any documents to the browser using the HTTP protocol;

[0052] - Service and processing requests, such as: mailto: ..., FTP, Telnet, etc .;

[0053] - Run application programs on a web server with the subsequent transfer and return of processing parameters via the CGI interface standard;

[0054] - Operation and maintenance of navigation image maps (Image map);

[0055] - Download Javascript applications;

[0056] - Authorization of users and their authentication;

[0057] - Maintaining a log of user access to various resources;

[0058] - Automated operation of web pages;

[0059] - Support for pages that are dynamically generated;

[0060] - Support for the operation of the HTTPS protocol for secure connections to clients. Step 420: A request to a website is received from at least one user.

[0061] So, the user's equipment browser, for example, a mobile communication device, sends a client request to a web server with a web page address, for example, buying a product selected by a user for purchase in an online store. The web server, upon receiving a request for a web page, takes steps to assemble the HTML code of this page, during which the following is done:

[0062] - execution of the program code of the dynamic parts related to the calculation of the basket for the user, the output of the phone and the operating time of the delivery point and the price of the goods. This stage can be carried out taking into account the status and access rights of the user, as well as other possible conditions for the formation of a web page, and includes sampling the necessary data from databases related to customers, prices and assortment, filtering and sorting these data and other actions required to form HTML code for dynamic parts. PHP code is usually used as a program code, but it can also be Perl, ASP, JSP, etc. The result of the step of executing the program code of the dynamic parts is to obtain the HTML code corresponding to the specified dynamic parts;

[0063] - the formation of the HTML code of the web page, which includes the HTML code of the static part and the HTML code of the dynamic parts, obtained in the previous step by executing their program code;

[0064] - issuing the generated HTML code of the web page to the user equipment and then displaying the web page by the user's browser.

[0065] For example, this may be a URL request (with all GET and / or POST parameters). The POST request method is designed to transmit and receive data of any size, in contrast to the GET method, where restrictions can be at the level of the web server or at the user's web browser on its device. Therefore, POST can be used to upload a file or view a completed web form. As part of a GET request, some data may be transmitted in the request string of a URI, indicating, for example, search conditions, date ranges, or other information defining the request. As part of a POST request, an arbitrary amount of data of any type can be sent to the web server in the body of the request message. The header fields in the POST request indicate the type of content.

[0066] Also, the type of request (GET or POST) can be specified as a download parameter, for example, in a character or numeric format.

[0067] Or, as a download parameter, Cookies can be specified (for example, if a website stores data on user behavior in cookies and on the web page you need to implement the section "You have looked before" based on this data). A cookie is a small piece of data sent by a web server and stored on a mobile communication device or a user's computer. A web client (usually a web browser) every time it tries to open the page of the corresponding website sends this piece of data to the web server as part of an HTTP request.

[0068] Also, the text identifier of the dynamic portion of the web site may be used as a download parameter, allowing the different dynamic portions of the web site to use the shared cache. If the two different dynamic parts of the website have the same identifier, then the cache will be stored in non-volatile memory with the same loading parameters. This allows you to calculate dynamic blocks once, then use the already calculated cache.

[0069] The non-volatile memory used in the invention is intended for recording and storing data used by the web server, in particular, dynamic and static parts of HTML pages, content necessary for filling HTML pages, auxiliary information, etc. As a non-volatile memory use the web server's hard drive, non-volatile memory of the user's mobile device, or the memory of other computers located on the Internet.

[0070] The dynamic part of the website can be of any allowable size, for example, as a single link word “Login”, which after user authorization is changed to “Logout”, as well as menus, filters, products, and even entire web pages of the website .

[0071] Step 430: check for the presence of the cache file in the non-volatile memory for each dynamic part of the web page obtained in the previous step of the request.

[0072] At the time of loading a web page from a web server, a request for a web browser checks for each dynamic block located on this web page: whether the results of previous calculations for the current download parameters and the identifier that were performed during the previous download are saved. At this step, the cache file is checked for presence in the non-volatile memory of the web server where the results of previous calculations are stored. If the file is present, the dynamic block is not calculated, and the result is loaded from the cache file. Otherwise, the dynamic block is calculated, and the results are written to the new generated cache file.

[0073] In the absence of a cache file in the non-volatile memory of the web server, during the test, the dynamic part of the web page is calculated based on the download parameters, and for the calculation, pre-receive data from the RAM, if present; otherwise, get data from non-volatile memory.

[0074] In this technical solution can use random access memory (RAM) and / or static random access memory (SRAM), and / or graphics device memory (GPU memory).

[0075] In order to obtain a link to the cache file of the dynamic part in the form of a URL, load parameters are converted in such a way that the same link to the file is returned for the same set of download parameters. If the boot parameters do not participate in the calculation of the dynamic part, then they do not participate in the formation of a link to the cache file. The boot parameter may not participate in the calculation of the dynamic part, if it is not explicitly specified, or has a flag in the system that may or may not be used. For example, if the dynamic part for all users does not change during the calculation, then the specified user or not does not affect the cache file address, since the user does not affect the result of the calculation of the dynamic part of the web page.

[0076] The boot parameters also use a unique user identifier, such as login or user ID (login field), which can be either numeric or symbolic. This approach allows you to cache an individual for each user state of the dynamic parts, which is a visitor to the website. In some embodiments, if the user is an unauthorized visitor, then the value of the unique identifier will be “-”. This boot parameter is optional.

[0077] There is also a Properties [i] parameter that represents an array of data, namely, ordered parameters and their URL request values after the "?" and before the character or end of the line (for example, "sort_id = id", "sort_direct = 1 ''), which is also an optional parameter.

[0078] The urlpage parameter is the address of the current user request page (after the first '/' character and before the first of the '?', '.', '#' Characters or the end of the url), which is optional or required parameter, depending on select a web programmer.

[0079] Physically, the dynamic block caching process is the saving of the calculation results to a file at a specific address, which depends on the boot parameters that are involved in the calculation of the dynamic part, for example: /cache/modulename/parametrurl/login/var.txt.

[0080] Since it is necessary to store only the differing results of the dynamic parts as compared to the previously calculated part in order to save space in the non-volatile memory, the unambiguous function of converting the query parameter set to the cache file URL is used. Since not all query parameters can affect the calculation of the dynamic part, only those that affect the result are indicated.

[0081] To do this, divide the boot parameters to those that affect the result of the calculation and no (text identifier, login, URL). POST requests are not cached, because they are intended to exchange the information of the web server and the user's web browser without refreshing the whole page. Therefore, only GET requests are cached.

[0082] Next, a unique link to the cache file is formed, for example, of this type, and the extension can be any, not limited to:

/ {text identifier} / {login} / {parameters} .txt.

[0083] If the user login is not involved in the calculation of the dynamic part of the web page, then the link to the cache file without this download parameter will look like this:

/ {text identifier} / {parameters} .txt

[0084] If the parameters do not participate in the formation (a text identifier necessarily influences the formation of a URL, this allows the same cache to be used by different dynamic parts of a web page), then:

/ {text id} .txt

[0085] As a result, the cache URL can be the following: "cache / modules /" + name + "/" + urlpage + "/" + login + "/" + properties [1] + "/" + ... + "/" + properties [M] + ".txt", which is a text concatenation of parameters.

[0086] Examples of URLs to a cache file are as follows:

- "/cache/modules/header/-.txt" - the dynamic part of the website header for an unauthorized user.

- "/cache/modules/karusel.txt" - the dynamic part of the banner, which does not depend on anything and can take only one value.

- "/cache/modules/control_table/users/admin/sort_id=id/sort_direct=1.txt '' - the dynamic part of the web page with the text identifier control_table in the administrative part that is responsible for displaying data (and in this case, users) which was viewed by the admin user and sorted by id column id in descending order.

[0087] The result of calculating the dynamic part of a web page is the following data set:

[0088] HTML - code of the dynamic part, which must be placed on a web page;

[0089] Javascript is the code of the dynamic part to be placed on the web page;

[0090] Javascript is the code that is triggered by the onload event when the web page is loaded. In order for javascript code to be executed when a web page is loaded, it must be specified in the onload parameter of the body tag in the HTML code of the web page. If there are several dynamic parts on the web page that use onload when loading, then they need to be assembled into a separate javascript code that will be placed in the onload event.

[0091] CSS style;

[0092] POST — answer as a text string;

[0093] An additional result is data in the format of a text line, if there is a need to obtain additional information from the dynamic part. It can be used if, for example, the data must first be converted depending on the results of the calculations of other dynamic parts of the web page. This field allows data to be transmitted in a convenient format for further work.

[0094] For example, consider a product webpage in an online store. Suppose that the web page has the following dynamic parts:

- Field A of the basket indicating the total amount and the possibility of deriving the list of added goods when you hover the mouse,

- Field B of the product, where detailed characteristics are displayed (without the price, the price is displayed separately)

[0095] Suppose a website has a special offer: add item 1 to the basket, and get 50% discount on item 2. Those. in order to understand what price to show to a visitor on product page No. 2, you must first obtain data about the added products, and then calculate the characteristics of the product. In this case, the price without a discount is stored in non-volatile memory in the database in the same place as the other characteristics, so it is more logical to get it together with the other requests in the dynamic part B. But the price should not be embedded into the result of the HTML code, but can be returned as an additional result to make further calculation. Thus, after calculating the dynamic parts A and B, the price is recalculated if there is item 1 in the basket.

[0096] The dynamic part due to the ability to process request parameters of the POST type can send requests to the web server and receive a response in any text format (for example, JSON) without reloading the page (for example, AJAX technology). If the result from the web server is displayed on the page, the page will change, and the dynamic parts will have the same cache, because at the time of the request the page with the dynamic parts was not loaded again. This can be used when the dynamic part can take many values that are quickly calculated and, as a result, they should not be cached. For example, the dynamic part that displays the file structure: on the left is a list of folders, and when you click on a folder, attached files appear in the folder. Obtaining a file structure tree is not a time consuming operation, so it does not make sense to cache the result with each click.

[0097] As a result, if the states of the dynamic parts for certain parameters of the request have already been calculated earlier, the loading speed of the web page will be as fast as possible, since no calculations will be required.

[0098] The whole process of calculating the result of the dynamic part is based on querying data from its storage location (for example, in a database using an SQL query) and further operations with this data. The main objective is to maximize the acceleration of the time of receipt of data from their storage. As operations on the dynamic part can be used the operations of reading, modifying (updating), deleting, creating, known from the prior art.

[0099] If a read operation is performed inside the dynamic part of a web page, a link is stored in RAM that contains data about the URL of the cache of the dynamic part of the web page, the database connection string and a table inside the database to which the query was sent.

[00100] For example, this may be performed as follows:

[00101] "/cache/modules/header/-.txt",

[00102] "Driver = {MySQL ODBC 5.1 Driver}; Server = localhost; Database = Settings; '"

[00103] "Menu".

[00104] If the operation is to create, update, or delete, search for all the connections created earlier when reading from the data in the connection string to the database, a table inside the database. Then, all cache files that have been configured with this data are deleted — these cache files will be irrelevant since they have changed.

[00105] In this technical solution, a system for accelerating data acquisition is implemented. It consists in loading information (which is stored in non-volatile memory) at the time of the first loading of the website into RAM. All further work of the web developer with data is based on a generalized request to the CMS indicating what data he wants to use without specifying the storage location. The system first requests data from the RAM and, if there is no data, requests it from non-volatile memory (for example, in a database).

[00106] This technical solution uses the Entity-Attribute-Value (EAV) data storage model. This model has several advantages:

[00107] 1. Allows you to change attributes and parameters for an entity without changing the database structure.

[00108] 2. Eliminates data redundancy.

[00109] However, in the prior art, when using this data model, the following problems arise:

[00110] 1. The complexity of sampling requests for attributes that take more time due to the inability to use standard indexing methods.

[00111] 2. The need to track duplicate links.

[00112] 3. The need to track links between non-existing table entries.

[00113] The above problems are solved in the framework of this invention. Let's take a closer look at an example of the proposed SQL structure for storing user data.

[00114] This structure has a UUsers table that stores user id as well as a UProperty table that stores data about the attributes themselves. For example, for the attribute "Address" exists:

[00115] the unique identifier "idProperty" is equal to "2",

[00116] the name in Russian,

[00117] the name in Latin,

[00118] the type of values for this attribute,

[00119] parameter display method (this can be either a regular text field or a slider with two sliders),

[00120] Should the address values be unique,

[00121] attribute sorting relative to other user attributes

[00122] The UPropertyValue table stores attribute values.

[00123] The UUsersPropertyValue table stores associations between attributes and users.

[00124] To make data retrieval as fast as possible, perform one complex query using the JOIN operator instead of several simple ones. The INNERJOIN command allows SQL to process tables in a different order than specified in the query. This allows the database to return the result as quickly as possible.

[00125] The query function itself returns entities that satisfy the requirements for attributes and their values, for example:

[00126] Entity requirements for the presence of at least one value of this attribute.

[00127] Check for the presence / absence of NULL among the values.

[00128] The presence of a value in a particular attribute that contains the specified string or completely matches.

[00129] The complexity of such requests is that they must first be automatically generated based on the specified attribute requirements, and then executed. For example, if there is a problem of sampling by two values of different parameters, you must find the data first by one, then by another parameter, and then find the intersection. To do this in one query for any number of parameters, you can automatically build a complex query for any number of parameter requirements.

[00130] In order to build such queries into the database for any number of attributes with any requirements for their values in the EAV model, they use the query builder for all possible conditions.

[00131] To save the results of queries to the database and all their variations does not make sense, since there may be too many subsets of the results. To reduce the number of queries to the database, you can use pre-loaded tables in RAM. Tables are loaded into RAM at the time of launching the website. Then the tables are automatically converted, but the user at the stage of creating the website pre-determines that the USERS table will be stored in RAM.

[00132] The data is stored in RAM as an ordered list of entities to which their ordered attributes and values are already associated.

[00133] Also, a list of all parameters and values is additionally loaded into RAM for accelerated retrieval of a list of all attributes and their values without being bound to entities.

[00134] This technical solution was tested in practice and implemented: the site http://chik-chik.ru/ was developed, which showed, on average, the best results in speed for processing and managing website data in load testing compared to other large sites that have similar technical solutions known from the prior art. For testing, we used the server as close as possible to the physical location of the web site server.

[00135] As noted above, the invention is preferably implemented on at least one data processing device or a web server. Thus, the invention does not require any changes in the usual hardware or software of the client computer. Summarizing, the above described functionality or sequence of steps of a method can be implemented in software executed on a data processing device or a processor, namely in the form of a set of instructions (program code) in a code module that resides in the main memory of a computing device. Until a computing device is needed, a set of instructions can be stored in another type of memory, for example, on a hard disk or in removable memory, such as an optical disk (for possible use on a CD) or a floppy disk (for possible use on a floppy disk). disk) or downloaded via the Internet or another computer network.

[00136] In addition, although the various methods described are conveniently implemented in a general purpose computer, one skilled in the art also recognizes that such methods can be performed on other hardware, in firmware, or on more specialized devices implemented to implement the required method steps.

Claims (13)

1. A method for managing website data that includes the following steps: form at least one static part of the web page and at least one dynamic part of the web page, which are stored in non-volatile memory; receive from at least one user a request to the website; check the presence of the cache file in the non-volatile memory for each dynamic part of the web page received at the previous step of the request, and if there is a cache file in the non-volatile memory, load its contents into the dynamic part of the web page. 2. The method according to claim 1, characterized in that the request is of type POST or GET. 3. The method according to claim 1, characterized in that the request contains a link to the website with the parameters. 4. The method of claim 1, characterized in that in the absence of a cache file in the non-volatile memory, the dynamic part of the web page is calculated during the check based on the request to the web server, and when the data is changed, they are modified first in the non-volatile memory, and then in operational. 5. The method of claim 1, characterized in that in the absence of a cache file in the non-volatile memory, the dynamic part of the web page is calculated during the check based on the request to the web server, and when the data is changed, they are modified first in RAM and then in non-volatile. 6. The method of clause 4, characterized in that the change in data is the creation, or update, or deletion. 7. The method of clause 4, characterized in that when changing the data that was used in the calculation of the dynamic parts, the cache files of these dynamic parts are deleted. 8. A method according to claim 1, characterized in that in order to obtain a link to the cache file of the dynamic part in the form of a URL, the conversion of loading parameters is performed so that the same link to the cache file is returned for the same set of loading parameters . 9. The method according to claim 1, characterized in that if two different dynamic parts of the website have the same identifier, then the cache storage location in the non-volatile memory is the same with the same download parameters. 10. A method according to claim 1, characterized in that if a read operation is performed inside the dynamic part of the web page, a link is stored in the operative memory, which contains data about the cache URL of the dynamic part of the web page, the database connection string and the table inside database to which there was a query.

Images