Elasticsearch is a solution, but it's not needed if the search database queries are updated (see 5 below for the long explanation).
My last pass at optimization was years ago. The things that I wanted to do (in no order) were:
1) stop resizing the images programmatically.
When a sample image is viewed at a size other than 100%, the image is loaded by the script and resized on the fly every time.
With less than 500 images, there is no reason not resize them and store them on the server.
I completed creating the 3 different sizes of the images, but never updated the display code.
2) use unique URLs for the creator bios
The bio page receives the name as a query string and then does a look-up to display the correct info.
This would change
https://bailsprojects.com/bio.aspx?Name=HUGHES%2c+RICHARDto
https://bailsprojects.com/bio/hughes-richard.htmlThe previous URL would redirect to the new URL.
3) create static HTML pages for the creators
This information is not being updated, so there is no reason that an HTML file couldn't be saved to the filesystem when a creator link is clicked.
There would be a single hit to the active page to generate the HTML page, and all subsequent hits would serve that static page.
4) create static HTML pages for the scan pages.
Same as 3
5) update the search to use modern collection paging
The database is one table with columns for name, category, credit, wwindex, and tenure.
The search is a basic wildcard search in 4 columns (name, category, credit, and tenure).
A query looks like this:
Select w.ID from WhosWho w where 1=1 and (w.Name like '%NGUYEN, HOANG%' or w.Category like '%NGUYEN, HOANG%' or w.Credit like '%NGUYEN, HOANG%' or w.Tenure like '%NGUYEN, HOANG%')
However, the result creates and uses temporary tables to determine the display, so the above query becomes:
set nocount on
declare @Results table(ID int)
declare @Within table(ID int)
declare @Paging table(ID int, Seq int identity)
insert @Results(ID) Select w.ID from WhosWho w where 1=1
and (w.Name like '%NGUYEN, HOANG%'
or w.Category like '%NGUYEN, HOANG%'
or w.Credit like '%NGUYEN, HOANG%'
or w.Tenure like '%NGUYEN, HOANG%')
declare @RecCount int
select @RecCount=(select count(distinct ID) from @results)
select @RecCount
if @Reccount>100
begin
insert @Paging(ID)
select w.ID from WhosWho w
inner join (select distinct ID from @results ) r
on w.ID=r.ID
order by Name, WWIndex, Credit, Tenure
select Name, Category, WWIndex, Credit, Tenure, UpdateType, Updated
from WhosWho w
inner join @Paging p
on w.ID=p.ID
where p.Seq>=1
and p.Seq<=100
order by p.Seq
end
else begin
select Name, Category, WWIndex, Credit, Tenure, UpdateType, Updated
from WhosWho w
inner join (select distinct ID from @results ) r
on w.ID=r.ID
order by Name, WWIndex, Credit, Tenure
That is the most basic query.
It's building a temp table to store results so that it can limit the result to the results to be shown.
That's a colossal drain with every search. Especially when data collections have built-in record paging.
That, however, is the base of the site, so stripping it out and replacing it is time-consuming.
The base query should be:
select Name, Category, WWIndex, Credit, Tenure, UpdateType, Updated
from WhosWho w
where 1=1
and (w.Name like '%NGUYEN, HOANG%' or w.Category like '%NGUYEN, HOANG%' or w.Credit like '%NGUYEN, HOANG%' or w.Tenure like '%NGUYEN, HOANG%')
order by Name, WWIndex, Credit, Tenure
with paging handled within the collection