Lazarus

Programming => Networking and Web Programming => Topic started by: cpalx on November 24, 2018, 04:40:50 pm

Title: fptemplate | Bug
Post by: cpalx on November 24, 2018, 04:40:50 pm
Some weeks before I made a webside using lazarus + CGI + fptemplate, it was perfectly the first days, but when i had 6000 visitors by day i had the problem:

Error: Unable to open file "template/admin.main.list.item.html"

where the file "template/admin.main.list.item.html" was my template file. I suppose it was two(or more) visitors open the websides (The file) simultaneous.

Title: Re: fptemplate | Bug
Post by: Leledumbo on November 27, 2018, 09:07:23 pm
The file was opened using fmOpenRead mode only, I think it should be opened with fmShareDenyWrite as well.
Title: Re: fptemplate | Bug
Post by: Trenatos on November 27, 2018, 11:02:28 pm
If the file doesn't change, consider caching it and only loading it from disk if the modified timestamp has changed, it'll be faster and won't have file-lock issues.
Title: Re: fptemplate | Bug
Post by: cpalx on December 04, 2018, 03:08:50 am
and how i make it that with fptemplate
Title: Re: fptemplate | Bug
Post by: Thaddy on December 04, 2018, 11:14:43 am
This is not a limitation of the template engine, but you are probably hitting a limitation of cgi itself, which starts a new process for every connection.
You can do two things:
1. include the template as a resource in the cgi
2. Change to fastcgi, which keeps the same process for every connection.

There are more ways to solve this, but cgi has its problems if the website itself has no means to distribute its load.

Running 6000 processes at the same time on a single server is asking for trouble.... So consider option 2 if you are on a limited budget. Or try to limit the liveliness of a single connection to the cgi part of your web app..

In other words: cgi does not scale well on a single server. Fastcgi or e.g. an apache module scales better. Also note fastcgi is not necessarily fast, but at least it is likely to be more responsive for clients under single servers with high load.
Title: Re: fptemplate | Bug
Post by: cpalx on December 04, 2018, 01:16:06 pm
Thanks.

It's clear now.
Title: Re: fptemplate | Bug
Post by: Trenatos on December 04, 2018, 04:19:13 pm
fptemplate parses content and gives you a resulting string.

Create a dictionary with the path to the requested file as key, and values for file timestamp, raw content, and parsed content.

For each request, check the file ending and see if it's a template file, then check if it exists in the cache, if it does then you check the timestamp and compare to the files current timestamp.

If the timestamps don't match, or there is no record in your cache, you load the file, parse it if that makes sense, store the result in the cache and serve the content (And free the file handler).

On the next request, you'll load it from the cache instead, and either the raw content if you need to fill dynamic data (like username, current time, etc.), or the parsed one if the data is fairly static (Like blogposts).

And there you have a very simple in-memory cache.

Combine that with fastcgi and you should be good.

Note, that's not an industrial-strength caching solution but it's plenty good for starters.
Title: Re: fptemplate | Bug
Post by: Thaddy on December 04, 2018, 05:40:13 pm
@trenatos
You missed the point.

That's why I explain things.....
Title: Re: fptemplate | Bug
Post by: Trenatos on December 04, 2018, 05:50:39 pm
@thaddy, no I got it, I was just adding a piece about caching, which is easy to do and adds performance in addition to switching to fastcgi.
Title: Re: fptemplate | Bug
Post by: Renat.Su on December 18, 2018, 05:33:41 pm
The same things was with me.  :D This is not a bug, but a feature.

If you have a fastcgi application running in multithreaded mode, this can happen too. Therefore, add synchronization while load template file or load the template at the start of app and assign template string at the start of the connection in a new thread (which is also essentially synchronization)
TinyPortal © 2005-2018